Slopsquatting detector drops three safe-verdict rules an attacker could satisfy

A tool that tracks package names invented by language models has removed three of its own safety rules after a reader's comment showed that each one could mark an attacker's package as low-risk. The maintainer, writing on dev.to as jj1423, frames the cleanup as a broader lesson about automated risk scoring: the branches that clear a package are where the reasoning goes soft.

What the detector watches

Slopsquatting works like this: ask a language model which package to use and it occasionally names one that does not exist. If someone registers that name first, the next developer — or the next coding agent — who follows the same suggestion installs whatever was placed there.

The detector collects these hallucinated names and scores them. A name that still returns a 404 is straightforwardly a target. For names that do resolve, the baseline is age: under 14 days counts as high risk, under 60 as medium, anything older as low. That ladder survived the audit. The exceptions layered on top of it did not.

Signed builds proved the wrong thing

The first exception relied on npm provenance statements and PyPI's PEP 740 attestations, which the registry issues at publish time to bind an artifact to a named repository and workflow. The maintainer initially treated a valid attestation as strong evidence of legitimacy.

As the reader pointed out, the statement binds an artifact to a repository — not to a trustworthy one. Anyone can create a GitHub repository, configure a Trusted Publisher flow and publish a squatted name with a perfectly valid attestation in a few minutes of CI work. The rule did not reduce attack risk; it pre-cleared exactly the package an attacker would publish. The reader generalised from a separate system they work on, cited in the post: of 31 signing keys in a log they scan, the 23 with no accepted work and no deliveries produced 91% of all capability declarations. Credentials that cost nothing accumulate where producing them is cheapest.

Provenance is still recorded and shown next to each finding for readers to weigh, but it is no longer an input to the classifier at all — deliberately removed from the signature so it cannot be wired back in by accident.

Registration dates measured the collector, not the name

The second exception came from a genuine false positive: cdx-rs, a cd replacement published on 30 August, which a model suggested on 4 September as a library for parsing CycloneDX SBOMs. Since the package predated the sighting, the rule marked any name registered before its first recorded hallucination as low risk.

The flaw is that a first sighting is not a first suggestion. Sampling only catches names models were already producing, so near the start of collection the rule effectively read "registered before we started looking" — and an attacker who registered a name early and waited would have sailed through it. The branch also handled missing data incoherently: with no sighting date the package fell through to the age ladder and could score high, while an early sighting date produced an immediate low. Two kinds of not-knowing, opposite verdicts, and no branch that said "unknown".

The only independent date the maintainer found — model training cutoffs, set by vendors — predates the detector's own 60-day window, making the rule redundant with age. It was removed, and cdx-rs is flagged again. The stated trade-off: a list of attack targets should default to suspicion, because a coincidence cannot be distinguished from a squat by registration date alone.

Go modules were never dated at all

The third exception emerged from the reader's framing rather than a direct complaint. A package with no creation date returned "low" — and the Go module proxy answers only whether a module exists. Every Go module a model recommended, including one pushed the day before, was cleared without any date being checked.

Undated packages now score medium, with Go dates sourced from deps.dev. The maintainer notes a caveat: Go timestamps reflect commit times, which authors control, so a backdated module still looks old. npm and PyPI record when the registry actually received an upload, which publishers cannot choose. Weaker evidence, but better than none.

The audit that could not run

The reader suggested a cheap check: plot the registration dates of everything rule two had cleared against the day collection began, and look for clustering at the boundary. That was impossible, because low verdicts were simply dropped rather than stored. Every low verdict is now logged with the rule that produced it, the registration date and the first sighting — kept internal for future audits. Previously withdrawn findings were re-scored, and two returned to the list.

Why it matters

Slopsquatting is an emerging supply-chain threat that hits human developers and autonomous coding agents alike, since both act on model suggestions. The dev.to post's wider warning applies to any risk score: exceptions written to silence individual false positives are drafted while looking at the false positive, not at an attacker — and the branches that declare a package fine are precisely the ones an attacker will study. The maintainer's three questions for any safe verdict: can an attacker cheaply produce this input, does it describe the world or only the collector, and what happens when it is missing. If "unknown" can resolve to "safe", it eventually will, at scale, across a whole ecosystem.