Description
A reviewer reads forty lines of new logic carefully. She questions it, tests it and stands behind it. The forty lines were probably fine. The risk was in the one line above them that she has been trained by twenty years of habit to read as plumbing: an import.
That habit made sense when a person chose every dependency. Somebody weighed the licence, the maintenance, whether the project was still alive. The choosing has quietly moved. It is now done by a model working from a snapshot of the world frozen well before today, which prefers what appeared most often in its training rather than what is current, and which will confidently name a package that does not exist.
That last failure is the one worth understanding. When researchers measured how often generated code imports packages that are not real, they found the invented names repeat rather than scatter. A hallucination that reproduces is not noise, it is a target: somebody can register the name in advance and wait for a build to reach for it. The window between a malicious package being published and it landing in a pipeline is now measured in the time it takes an update to merge.
Underneath sits the ordinary problem, which is slower and just as real. Even when a fix exists, the delay is on the client side: studies across the major registries find months between a patch being published and projects actually running it. So this dimension scores the moment of entry. Not whether you scan afterwards, which most organisations do, but whether anything examines a dependency before it lands, and whether a person is still accountable for the decision.
The five levels
One question decides which rung you are on: does the system itself act on this, or does a human have to choose to? Each rung carries a tell: the thing that would settle it, so the score is something you checked rather than something you agreed with.
- 1
Blind
There is no inventory of what the system depends on. Nothing lists direct and transitive dependencies, nothing checks their age or their licences, and a package arriving in the build is indistinguishable from one that was chosen deliberately three years ago.
The tellOpen the lockfile of your most important service and count the packages in it, then find who accepted the last one added. If the count surprises you and nobody signed for it, you are here.
- 2
Tacit
Some engineers check what they pull in: how alive the project is, who maintains it, what it drags along behind it. Others accept whatever the tooling proposes, and both kinds of change land in the same build with nothing marking the difference.
The tellLook at the last ten dependency additions and ask each author what made them pick that package. If some can answer in detail and others cannot recall deciding, the vetting is personal.
- 3
Visible but inert
Scanning exists and works. There is a vulnerability report, perhaps an inventory, and a backlog of upgrades that never quite reaches the top of the list. Nothing gates the moment of entry, so a package can be introduced today, sit unexamined, and appear in next quarter's report as an old problem.
The tellFind a dependency added in the last month and check what examined it before it merged. If the answer is a scan that ran afterwards, the gate is downstream of the decision.
- 4
Acted on
The decision is gated where it happens. A new dependency is checked against the live registry for existence and provenance, held for a cooldown rather than adopted the hour it was published, and a named person accepts it. The import line stops being the least examined line in the change.
The tellFind the last new dependency that entered your codebase. Something blocked it until the checks passed and a person accepted it, rather than it arriving inside a change about something else.
- 5
Durable
The practice covers the estate and keeps up. New repositories inherit the same gate, automated update proposals go through it rather than around it, and the time between a fix being published and running in production is short enough that the inventory describes the present.
The tellCompare the repositories with the gate enabled against the total, then check how long your last critical upgrade took to reach production. Broad coverage and a short lag is durable.
What this dimension rests on
The five levels are observed, from client engagements, and no paper produced them. What the research below establishes is why this dimension is worth scoring at all. No links: the citations carry enough to find them, and they stay findable after a link would have rotted.
Spracklen, Wijewickrama, Sakib, Maiti, Viswanath and Jadliwala, We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs (USENIX Security Symposium, 2025)
Measured how often generated code imports packages that do not exist, and found the invented names repeat rather than scatter. A repeatable hallucination is something an attacker can register in advance and wait for.
Rahman, Paramitha, Enck and Williams, How Quickly Do Development Teams Update Their Vulnerable Dependencies? (2024)
Measured the delay between a fix being published and projects adopting it across major registries, and found the client side is where the time goes. Having a fix available and running it are separated by months.
Where this came from
This dimension has a published article behind it, written from client engagements rather than from a greenfield repository.
Read the article on Dependency hygiene →
How to climb this dimension is not written yet. It is the next thing this page grows, and saying so is more useful than a paragraph of generic advice.