For a while, teams treated “we verify provenance, so we’re covered” as a complete safety guarantee, an SBOM, a SLSA provenance attestation and a Sigstore signature bundled into one claim. In 2026, every poisoned ChainDrop version carried valid SLSA provenance because it rode a legitimate signed pipeline.
Provenance answers “where did this come from and how was it built”. It has never answered the question you need answered: is this package safe? Here’s what each signal proves and what none of them can, starting with how ChainDrop rode a legitimate signed pipeline. It’s one thread in the broader picture of software supply chain security in 2026, but it’s the thread where the usual trust assumptions stop holding.
SBOM vs SLSA provenance vs Sigstore: what does each actually prove?
An SBOM is an electronic packing slip: a machine-readable list of every component and dependency that went into the software. It tells you what is in the box, not whether the contents are safe.
SLSA provenance is a signed, verifiable record of build process and origin, expressed as an in-toto attestation. It answers “how and where was this built”, and says nothing about whether the result is safe.
Sigstore makes the “who signed it” part checkable: cosign signs and verifies, Fulcio issues short-lived keyless certificates tied to an OIDC identity, and Rekor records each signature in a public transparency log.
Three tools, three questions. None evaluates whether the code is malicious, and all three held up on every poisoned artefact. They’re evidence layers in the wider trust problem, not safety guarantees.
Why is valid SLSA provenance no longer proof that a package is safe?
Because provenance certifies a process, not an outcome. It binds an artefact to a builder, a source repository and a commit, and the higher SLSA levels harden that binding. That’s the scope, and a legitimate pipeline can still emit poison.
In May 2026, attackers compromised 84 npm artefacts across 42 @tanstack packages and spread to 170-plus packages, every malicious version carrying a valid SLSA Build Level 3 attestation. In June, Red Hat shipped valid, verifiable provenance and a credential-stealing worm together: 96 malicious versions across 32 packages, about 117,000 downloads.
The SLSA maintainers drew the boundary themselves: provenance “records evidence. It answers ‘what happened?’ Policy and verification answer ‘was that good enough?'” Provenance is now necessary but insufficient. Signed no longer means safe.
Provenance attestation vs a package signature: which should you trust?
The two answer different questions, and you need both. A package signature binds a digest to a signer’s key. It proves the artefact has not changed since signing and that the signer held that key: integrity plus identity. It says nothing about intent. A provenance attestation is a signed statement about process, “built by this builder, from this commit, this way”, with richer claims in an in-toto predicate.
Both were valid on ChainDrop’s malicious tarballs. As Unit 42 put it, “this is not forged provenance. The attestation says the tarball was built in that repository by that workflow, and that is true.”
Validate the signature before you install, but the narrower question is: is the signer the legitimate maintainer, and was that maintainer’s pipeline trustworthy?
What is the difference between provenance and authorisation?
Provenance records what happened. Authorisation decides whether it was permitted. One can never stand in for the other.
Provenance answers exactly one question: was this artefact built by the pipeline I expect, from the source I expect? Authorisation asks whether the identity behind that evidence was entitled to act. A package can be provably built by the legitimate maintainer’s own pipeline and still be malicious, because that pipeline emitted poison or was compromised.
OIDC trusted publishing strengthens the identity claim. It binds publication to a repository and workflow identity through short-lived tokens, but it does not make the act authorised. Scope the trust policy to an entire repository rather than one protected workflow, and a rogue commit mints a genuine publish token. The Red Hat compromise walked through that gap: a too-broad policy and no human gate. The fix was a one-line change, scoping the OIDC token to the single publish job.
Attackers increasingly target CI secrets and build environments, because the pipeline is the trust root. Least-privilege OIDC scoping, protected environments and build isolation close the gap between provenance and authorisation: the software supply chain is the new perimeter.
What should you look for when a package presents valid provenance?
When provenance is valid, audit whose pipeline produced the artefact: is the builder the legitimate maintainer, and does the signing identity map to the expected repository and tag?
slsa-verifier (or the gh CLI’s attestation verification) confirms an attestation is genuine by checking Rekor and Fulcio and that it points at the source you expect. It answers “is this attestation genuine”, never “is this artefact safe”. It can’t tell you whether the source is benign, the pipeline compromised, or the dependencies malicious.
Then compensate with deterministic installs: pin exact versions and install from the committed lockfile (npm, Yarn or pnpm) with a clean, reproducible install, so the same tree is rebuilt every time. Lockfiles lock versions, not safety, and are bypassed by uncommitted lockfiles, script omissions and transitive drift. For judging vendor pipeline claims, Chainguard’s hardened images are a useful reference.
If the legitimate pipeline itself is compromised, you inherit poisoned artefacts with genuine provenance: the credential blast radius behind a poison package.
Domain blocklists vs behavioural detection: which actually contains a worm?
Behavioural detection is the answer.
A trustworthy pipeline cannot make you safe after install, so the question becomes what actually stops a worm once it ships. Domain blocklists fail structurally against EtherHiding-style on-chain C2: C2 addresses live inside a smart contract on a public blockchain, so infected machines read instructions from infrastructure nobody can seize. Attackers rotate that infrastructure with a single transaction, keeping blocklists a step behind, and blocking the traffic breaks every legitimate blockchain application.
Behavioural detection watches actions instead of badges: anomalous install scripts, unexpected network egress, unusual publish behaviour. Socket’s scanner flagged the poisoned TanStack artefacts within minutes on behaviour, while provenance flagged zero. CrowdStrike: behavioural security “can identify a supply chain attack even when software appears legitimate and has a valid signature.”
GHSA and OSV feeds complement this as the known-vulnerability layer, but advisories lag and can’t stop a novel worm in motion. Some samples read their payload with a stealthy read-only call, so monitoring the resolver contract is the early-warning tripwire. That’s the containment argument in full.
Where that leaves you
State what each signal proves, then ask two questions: who was authorised, and what did it actually do. That is the honest answer to “is this package safe?” — and one strand of the wider account of how supply chain trust collapsed in 2026.
Frequently Asked Questions
What is an in-toto attestation, in plain terms?
An in-toto attestation is a signed, machine-readable statement about how software was produced. It pairs a claim (for example, “this artefact was built by this builder from this commit”) with cryptographic proof of who issued it. SLSA provenance is one widely used type of in-toto attestation, which is why provenance claims arrive in this format. It describes process, never safety.
What is the difference between integrity and safety in the software supply chain?
Integrity means an artefact has not changed since it was signed. Safety means it will not harm you when you run it. A package can have perfect integrity and still be malicious, because a legitimate signer can sign a poisoned artefact. Signatures and digests protect integrity; only authorisation and behavioural detection ever get near safety.
How does keyless signing work, and why do Fulcio and Rekor matter?
Keyless signing lets a developer sign an artefact without managing a long-lived private key. Fulcio issues a short-lived certificate bound to an OIDC identity, the artefact is signed, and Rekor records the signature in a tamper-evident public transparency log. Together they prove who signed and when, not whether the artefact is safe or the intent behind it was legitimate.
What is the difference between SLSA Level 1, Level 2 and Level 3?
SLSA levels grade how much you can trust the build process. Level 1 means provenance exists but is unsigned and unverified. Level 2 means the build runs on a hosted service that signs provenance. Level 3 means the build is isolated with strong guarantees against tampering. Higher levels make provenance harder to forge, but none of them certifies that the resulting artefact is safe.
What should I do when a dependency ships no provenance attestation at all?
Treat the absence as a signal, not a formality. Ask the maintainer why, pin the exact version, and install from a committed lockfile with npm ci so the resolution cannot drift. Then watch behaviour: monitor install scripts and network egress. No attestation means you are trusting the package blindly, so compensate with tighter controls and closer monitoring.
What happens if the legitimate maintainer’s own build pipeline is compromised?
You inherit a poisoned artefact carrying genuine provenance, because the attestation is minted by the same compromised pipeline. This is the credential blast radius: a stolen token or a rogue commit inside a trusted workflow can publish malicious versions that verify perfectly. Containment then depends on least-privilege OIDC scoping, protected environments and behavioural detection, not on provenance checks.
Why do attackers target build pipelines rather than package registries?
Because a build pipeline already holds the trust and credentials needed to publish. Compromise it and every artefact it produces carries valid signatures and valid provenance automatically, which is exactly what defenders check first. Attacking the pipeline gives an attacker scale and credibility in one move, whereas impersonating a maintainer or a registry is slower and more visible.
Does an SBOM make my software more secure?
Not by itself. An SBOM is a visibility tool: it tells you which components are present so you can correlate them against vulnerability feeds like GHSA or OSV and respond quickly when something is disclosed. It does not assess whether those components are malicious, and a flawless SBOM can describe a fully poisoned artefact. Use it for inventory and triage, not as a security guarantee.
What is EtherHiding, and why can’t domain blocklists keep up with it?
EtherHiding hides command-and-control addresses inside blockchain smart contracts, so a malware sample reads its next server from a public chain rather than a fixed domain. Attackers can rotate those addresses constantly, which means blocklists are always a step behind and takedowns rarely touch the source. That structural speed advantage is why behavioural detection, not domain blocking, is what actually contains a worm.
What is the difference between a lockfile and an SBOM?
A lockfile records the exact versions and resolutions your project installs, so that npm ci reproduces the same tree every time. An SBOM records the full component inventory of a built artefact, including transitive dependencies, for visibility and vulnerability correlation. A lockfile enforces reproducibility; an SBOM describes composition. Neither proves the components are safe, and lockfiles lock versions, not behaviour.
Can I trust a package just because millions of people download it?
No, popularity is not a trust signal. High download counts usually mean the package is useful, and they can also mean a worm has spread widely before anyone noticed, as ChainDrop demonstrated across the npm ecosystem. Derive trust from the pipeline behind the package, the identity that published it and the behaviour you observe at install time, not from adoption numbers.
