The concrete problem
A package is reported compromised. Your security channel immediately fills with one question: did we ship it?
Looking at the repository’s current dependency tree is not enough. The vulnerable version may have existed for only a short time. Renovate may already have replaced it. A lockfile may have changed after the release. A Docker layer or CI cache may have reused something that no longer appears on the default branch. Even a clean scan today can say very little about the artifact built yesterday.
This makes supply-chain response a reconstruction problem. The useful unit is not the repository as it exists now; it is a particular artifact, produced by a particular build, from a particular set of resolved packages.
The current signal
On August 4, Aikido disclosed that a maintainer account behind Keyv-related packages had been compromised and that malicious releases used install-time code to steal credentials and propagate. In RayTally’s bounded Hacker News snapshot at August 5, 00:33 UTC, the discussion had 227 points and 120 comments and ranked sixth. Those figures describe that observation only; they are not market demand or proof that a new product would succeed.
The operational lesson is more durable than the snapshot: a fast-moving package incident can be over before a team finishes asking whether any released artifact ever contained the bad version.
A product direction: artifact-centered incident reconstruction
Imagine a tool that accepts a lockfile, build timestamp, artifact digest, and the relevant CI evidence. It reconstructs what that build actually resolved, then produces a report organized around images, services, and customer-delivered versions.
Each conclusion should carry an evidence label. A lockfile entry with resolved and integrity fields is direct evidence. A registry publication window combined with a semver range is an inference. Missing build logs are a gap, not a green checkmark.
That distinction matters because the output may drive expensive or irreversible decisions: isolating a service, rotating credentials, rebuilding releases, or notifying customers. A useful report must show the dependency path and the evidence behind every claimed hit.
The product should also resist the temptation to become an automated incident commander. It can identify affected artifacts and propose the smallest upgrade-and-rebuild set. It should not rotate keys, disable production, or send notifications without human review.
The full RayTally product brief and its four-source evidence trail cover the source boundaries, competitor gap, and business model in more detail.
A minimal entry point
Start with npm projects built in GitHub Actions. Accept package-lock.json or npm-shrinkwrap.json, the build time, an artifact digest, and a saved build log. Keep every result keyed to the artifact digest so a later scan of the current branch cannot overwrite history.
The first report only needs four states:
- Confirmed present: the locked version and integrity match the artifact’s build evidence.
- Confirmed absent: complete evidence shows another resolved version.
- Possible exposure: the version range and registry timeline overlap, but resolution evidence is incomplete.
- Unknown: required logs, caches, or lockfiles are missing.
An open-source CLI could produce a reviewable JSON report locally. A hosted layer could later map digests to deployed services and customer versions, retain evidence, and coordinate isolation status. That is a narrower and more defensible first product than another always-on vulnerability dashboard.
The strongest case against
The hard part is not parsing npm metadata. It is making a trustworthy claim from evidence that organizations routinely fail to retain. Build logs expire. Private registries rewrite metadata. Multi-stage images hide intermediate dependency trees. CI caches cross build boundaries. Teams may not have a reliable mapping from an artifact digest to the release a customer received.
A product that converts those gaps into confident red or green badges would be dangerous. False positives can trigger unnecessary outages and incident disclosures; false negatives can delay credential rotation after a real compromise. The required evidence model may be so conservative that many early reports end in “unknown,” which is honest but commercially frustrating.
There is also a platform question. Existing SCA vendors already retain project snapshots for customers who enabled monitoring before an incident. The wedge only exists where artifact-level historical reconstruction is materially better than those snapshots—and where teams value a forensic report enough to maintain the extra build evidence.
Question for readers
What evidence does your build system retain today that would let you prove which exact dependency tarballs entered an artifact six weeks ago—and which missing piece would make that proof impossible?
Top comments (0)