Why did signature checks and vulnerability scanners both pass on the SUNBURST and ua-parser-js releases?

## Three checks, three different questions Most pipelines run three checks that people casually describe as "we'd have caught that": signature verification, dependency scanning, and lockfile integrity hashes. Each answers a precise and narrow question, and the value of these two incidents is that they show exactly where each question stops. **A signature answers: who vouches for these bytes?** It binds an identity to a specific blob of content. It does not say the content is safe, was reviewed, or was produced from a particular source tree. In the build-system compromise, the malicious code was inserted *before* the artifact was signed, so the vendor's genuine key signed a genuinely malicious artifact. Verification passing was not a bug in signing; the signature was true. The consumer's mistake was reading "signature valid" as "contents trustworthy". The gap between those two statements is exactly what build provenance exists to narrow, because provenance describes *how the artifact came to be* — which builder, from which source and revision — rather than merely who put their name on it afterwards. **A scanner answers: does any component version here match a known advisory?** That is a lookup. It requires (a) that somebody discovered the problem, (b) that it was published as an advisory against a specific package and version range, and (c) that your scan runs after that. A newly published malicious version satisfies none of these on day zero. This is not a tuning failure or a coverage gap in the database; it is the model. Scanners are built for *accidental flaws in known components*, and both of these were *deliberate code in trusted components*. Even once an advisory lands, the scanner tells you about the version you scan today — which is often already the patched one — and says nothing about what you built and deployed during the window when the bad version was live. **A lockfile integrity hash answers: did I receive the bytes the registry published?** It is a transport-and-tamper check between the registry and you. When the publishing account itself is compromised, the registry publishes the attacker's bytes, computes their hash, and your client verifies it happily. Everything downstream of the publish step is consistent. Candidates very often reach for this one and it is the clearest demonstration that integrity is not the same property as authenticity of intent. ## What each incident actually needed For the build-system case, the control with a real chance is one that ties the released artifact to the source that was reviewed and to the builder that produced it — provenance generated by the build platform rather than asserted by the publisher, plus a build environment an attacker cannot sit inside and modify. Note the counterfactual: adding a *second* signature would not have helped, because signing was never the failure. Neither would scanning the vendor's dependencies, because the malicious code was not a dependency. For the account-takeover case, the controls that bite are about publishing identity and adoption timing: strong authentication and multi-party approval on the publisher side, and, on the consumer side, not adopting brand-new versions instantly, restricting what install-time scripts may do, and pinning so that a fresh malicious release does not flow into a build automatically. Again the counterfactual matters: a bill of materials would have told you, afterwards, that you had the component — an extremely useful thing during the response — but it would not have told you the component was hostile, because an SBOM describes *what is inside* an artifact, not how any of it behaves. ## The direction of the claims It is worth stating the three directions plainly, because mixing them up is the canonical wrong answer in this domain: - A **signature** says who vouches for an artifact. - **Provenance** says how the artifact came to be — which builder, from which source. - An **SBOM** says what is inside the artifact. None of the three says the artifact is safe. Malicious code that is signed, built by the real pipeline and correctly listed in a bill of materials passes all three. That is not an argument against any of them; it is an argument for knowing which question each one answers, so that you can say honestly which door is still open. ## The practical consequence When a headline compromise lands, the first instinct in many teams is "run the scanners". These two incidents explain why that instinct produces a false clean. Detection of malicious-code events comes from behaviour, anomaly and community disclosure — not from advisory matching — and the tooling that already runs is far more useful for the *inventory* question (where do we have this?) than for the *detection* question (is this hostile?).