Eight days ago, the OpenSSF published a post with a title that reads like a confession: Mini Shai-Hulud: Where SLSA’s Boundaries Fall. It is a careful, unsentimental piece of writing by people who built and believe in SLSA, and it concedes a boundary in one sentence that we have been circling for a year:
“The boundary of observability is the boundary of the trust context.”
We want to take that sentence seriously, because it is correct, and because the thing on the far side of that boundary is the thing we are building.
A worm wearing a valid attestation
The campaign that prompted the post is worth stating precisely, because the precise version is more alarming than the loud version. Beginning May 11, 2026, an attacker compromised 84 npm package artifacts across 42 @tanstack packages, and the self-propagating payload spread to 170-plus packages across @mistralai, @uipath, and other namespaces. The TanStack wave was later assigned CVE-2026-45321, CVSS 9.6.
That CVE is the tell. This was not a TanStack anomaly: security vendor Phoenix Security’s Malware Package Intelligence corpus tracks 59 supply-chain campaigns from June 2024 through June 2026 — 657 malicious package-versions across npm, PyPI, and the editor ecosystem — and reports the same fact about every one of them: “Across all 59 campaigns, CVE count: zero during active exploitation. Every single one.” CVE-2026-45321 exists, but it was assigned after disclosure — after the window in which it could have stopped an install. A control that waits on a CVE is, by construction, a control that fires once the campaign is already over. That is the layer problem in one number, and it is the backdrop against which the provenance failure below should be read.
Here is the part that matters for this essay. The malicious versions shipped with cryptographically valid SLSA Build Level 3 provenance. Not forged in the sense of a faked signature over a fabricated claim — valid. The attacker extracted the legitimate OIDC token directly from GitHub Actions runner process memory mid-workflow, authenticated to Sigstore’s Fulcio CA with it, and signed through npm’s trusted-publishing infrastructure. The resulting attestation accurately reported the builder, the source repository, and the workflow. It was, in the post’s words, “indistinguishable from legitimate ones.”
Read that again. The attestation was not lying. It said this artifact was built by the real TanStack workflow, from the real TanStack repository, on the real builder — and every word of that was true. The provenance did its job perfectly. The job was simply not the one a consumer needed done.
We flagged this exact failure mode in passing when we read the antv/g2 compromise as a catalog operator — the worm there also used stolen OIDC to dress follow-on releases in the language of supply-chain integrity. What was a footnote in May is the headline in June. OpenSSF has now named it from the inside.
The concession, in their words
The post does not hedge. Three sentences carry the argument:
“Build platforms can accurately record what ran within their trust boundary, but they cannot vouch for whether what ran produced an uncompromised artifact.”
“Once attacker-controlled code runs inside a trusted workflow, SLSA’s build-time guarantees are already behind them.”
“A signed artifact is not necessarily a trustworthy one.”
And then the sentence that, for a control-plane operator, is the whole game:
“SLSA records evidence; policy decides what is acceptable.”
That is not a criticism of SLSA. SLSA is doing precisely what it was specified to do: attest the integrity of a build process. The provenance answers who built this, from what, where. It was never specified to answer and is the thing it built going to read your ~/.npmrc and open a listener on :4444. Those are different questions, and the second one is the one that gets your credentials stolen.
Where the post points — and where it stops
Intellectual honesty requires saying where OpenSSF’s own remedies go, because they do not go where we go, and pretending otherwise would be the kind of marketing that loses an audit.
The post’s prescriptions are build-side. Move from L2 to L3 — “Moving from L2 to L3 directly addresses the class of attack used here,” it notes, because L3’s isolation guarantees close the cache-poisoning vector that seeded this particular worm. Add Source Track attestations. Compose Verification Summary Attestations. Stand up independent rebuilders on isolated infrastructure. Monitor for publishes from failed workflow runs. Practice workflow hygiene — least privilege, no pull_request_target, cache isolation. And the post’s quietly confident closer: “The controls to close most of those gaps exist today.”
All of that is right. All of that is necessary. We are not here to argue against build-time hardening; a fleet that ingests packages with no L3 floor is negligent. But notice what every one of those controls has in common. They live inside the build’s trust context — the same context whose boundary the post defined as the boundary of observability. Better isolation, more attestation types, independent rebuilds: each raises the cost of getting attacker code to run inside the pipeline. None of them changes what is observable once it does. The rebuilders re-run the same build; if the build’s inputs are poisoned, two honest rebuilders agree on a poisoned output. The boundary holds. The attacker, in the cases that matter, is already inside it.
That is not a flaw in the post. It is the post’s own thesis, taken one hop further than the post takes it.
The observation point a build does not have
A consumer — a catalog operator deciding whether to admit a version to a fleet — has access to something a build pipeline structurally cannot have: a second observation point, in an environment the attacker does not control, after the build, before admission.
The build platform watches the artifact get made. We watch the artifact run. Detonate the package in a controlled sandbox — install it, let its lifecycle hooks fire, capture the footprint — and you are observing behavior from outside the trust context the provenance was sealed inside. The OIDC theft that produced the valid attestation happened in their runner. The credential read that the package performs at install time happens in our sandbox, where there is nothing real to steal and everything to record.
Now put the two records side by side. That diff is the artifact.
Provenance claims Detonation observed
───────────────── ───────────────────
✓ Signed via Fulcio / Rekor • Credential-staging file dropped
✓ SLSA Build L3 • Autostart persistence added
✓ Declared egress: api.vendor.com • Untrusted driver loaded
• Egress → 185.x.x.x (non-allowlisted)
— looks clean — ≠ — behaves dirty —
divergence ⇒ raise attestation flag · "provenance clean, behavior dirty"
The provenance column can be entirely, cryptographically true and the behavior column still damning. The two do not have to agree, and when they disagree, the disagreement is the finding. Not “this signature is invalid” — the signature is fine. The finding is: provenance says X, behavior showed Y. A credential-staging file the manifest never accounts for. An autostart nothing in the build attests to. A kernel driver chaining to no trusted root. Egress to a host the declared footprint never names.
This is the judgment OpenSSF says provenance alone cannot make — “policy decides what is acceptable” — turned into a single, signed, demoable artifact. Provenance is a necessary input to that artifact. It is not the output that gates admission. The output is the diff.
Two refinements keep the artifact from being naive. The first is the combination rule: when the signals disagree, the verdict takes the worst of them, and a clean signal never buys back a dirty one. A valid SLSA attestation cannot offset an observed credential read — behavior is the moat, and a green provenance column does not raise the floor the behavior column sets. The diff is not a tie to be averaged; it is a disagreement resolved in behavior’s favor.
The second is a third column the diagram omits for clarity: signer continuity. Most public packages carry weak provenance — winget’s Publisher is unverified plaintext, Chocolatey community packages are essentially never author-signed — so is this signed by someone we trust is often unanswerable. But is this signed by the same identity as the last several admitted versions is answerable with no trust root, fully offline, and it is the cheapest signal in the set. A publisher that silently swaps its signing certificate between versions is exactly the substitution an attacker makes, and it is observable without knowing the first thing about the attacker. Provenance, behavior, continuity — the worst tier across the three is the verdict, and it defaults to observe: surfaced to an operator, not slammed shut.
What ships today — and what is still composing
The honest accounting: the hard half already ships, and the diff that composes it has started to land.
The footprint capture is live today — autostarts, listeners, scheduled tasks, driver loads, firewall deltas, signer identity, the full behavioral record of a detonation run. It runs on the broker-mediated Hyper-V backend and now on a native Proxmox/KVM backend with parity, so the observation point is real and reproducible. That is the right-hand column above, and it exists.
The diff itself has started to land. The first slice is live for the package managers we govern today — winget and Chocolatey. At detonation reconcile, an analyzer compares the captured footprint against a curated red-flag rule set, weighted by the package’s composed provenance tier, and persists a flag-only finding. The rule set is deliberately small and high-signal: persistence additions (autostarts, services, scheduled tasks) and untrusted-driver loads at high confidence; credential-staging artifacts and anomalous egress — raw-IP, cloud-metadata-shaped, or off a pre-staged allowlist — as warn-until-tuned. The finding never gates: it is computed observe-only, surfaced on the package’s detail page as a triage card, and shareable as a single-use snapshot. The promotion gate that could act on it is built but dark — default-off behind a measurement-accepted threshold.
Update, July 2026: the noisiest benign class now resolves with real evidence instead of a waiver. A quiet self-updater — Chrome, Brave, Edge, Zoom, anything Omaha-shaped — registers persistence whose binary never lands inside the sandbox’s settle window, so its finding is born open: honest, because there is no evidence yet. It flips to expected only when the fleet supplies the evidence the sandbox cannot — at least two enrolled endpoints (the quorum is config-raised for larger fleets, and the corroborators must span more than one enrollment batch or network segment) report a binary at the exact registered path whose signature chain-validates to a pinned trusted root and whose publisher identity matches the installer captured at detonation. The flip carries an auditable fleet-corroborated basis, and it reverts if the corroboration goes away. A quorum of two is a floor, not a fortress — the residual shrinks as the quorum grows, and we say so rather than round it to zero.
What is still composing is the rest: tuning the warn-until-tuned signals against a live catalog, turning the gate from dark to enforcing, and — the piece this essay’s npm case actually needs — ingesting external machine-readable provenance (SLSA, Fulcio/Rekor, cosign) so the same diff runs against an npm package’s attestation, not just a winget installer’s Authenticode identity. That npm rendition is on the published roadmap; the winget and Chocolatey one is in your hands now. The value of the OpenSSF post is not that it validates a finished feature — it is that it names, from inside the standard, the exact boundary the diff is built to cross.
What the screen shows
An artifact like this only earns trust if you can watch it happen, so the demo is deliberately one screen — and as of this week it is a screen you can open, not a mockup. Three panes, on a real package’s detail page.
Left — what it claims. The provenance pane. For a winget or Chocolatey package today, that is the composed tier: the installer’s Authenticode publisher identity, and whether that signer is continuous with the versions admitted before it. For the npm case this essay opened with, it is the SLSA L3 attestation and the Fulcio/Rekor signature — the same pane, once the external-provenance ingestion lands.
Middle — what it did. The detonation record: the red flags the run actually fired — a credential-staging file dropped, an autostart added, an untrusted driver loaded, egress to a non-allowlisted or cloud-metadata host.
Right — the diff. The divergence finding: provenance clean, behavior dirty, flag-only, sealed into a record an operator can triage and hand off as a single-use shareable snapshot.
No CVE feed. No signature database. No roadmap slide. The footprint capture runs, the analyzer runs, the finding renders — and the one thing still catching up is the left pane for npm: the external-provenance ingestion that swaps a winget installer’s Authenticode identity for a package’s SLSA attestation. The shape is shipped; the npm rendition is the next slice. Either way it is a thing you can be shown, on a real package, rather than promised.
What we would not claim
Five limits, named on purpose.
Behavioral interpretation is judgment-laden, so the output is a flag, not a verdict. A false “divergence” is worse than no divergence — it teaches an operator to ignore the alert, and an ignored alert is a deleted control. So the rule set stays tight and defensible — persistence additions, untrusted drivers, credential-staging artifacts, and egress that is raw-IP, cloud-metadata-shaped, or off a pre-staged allowlist — with the higher-false-positive classes labelled warn-until-tuned rather than treated as gospel. The artifact flags and routes to human review; it does not auto-reject. We would rather miss a subtle case than cry wolf on a clean one. Fail open, surface the diff, let an operator decide.
Absence of provenance is not divergence. Plenty of public packages publish no machine-readable provenance at all. That is not a finding — it is simply less to diff against, and the detonation footprint still stands on its own. Ingesting provenance across the long tail of registries that do not emit it cleanly is real, unglamorous work, and we would be overselling to call it solved.
A single detonation does not beat a patient payload. A version that waits for a calendar check, or that fingerprints process.env.CI and ~/.aws/credentials before doing anything, can pass one quiet sandbox run. The mitigations are the same ones we have named before — re-detonate on every ring promotion with the clock advanced and jittered, and shape the sandbox with honey-credentials so it looks worth attacking. Both are work, not checkboxes.
The same publisher, compromised, still passes. The diff catches a package whose behavior changed or whose signer changed. It does not catch a clean-behaving package republished under the same compromised publisher — same identity, same continuity, and nothing the sandbox observes in its window. Every signal reads green and the verdict is still wrong. That is the residual we do not claim to close, and naming it is the price of being trusted on the cases we do close.
A consumer-side gate cannot un-publish a worm. Once the bad version is on the registry, everyone who installed it inside the publish window is already exposed. Refusing to admit it to a managed catalog protects the fleet behind the gate; it does not clean npm, and it does not rotate the credentials a victim already lost. Attestation is an admission control, not a time machine.
The boundary, and what crosses it
OpenSSF gave the boundary its name: observability ends where the trust context ends. Their roadmap — and it is a good roadmap — works to make the trust context harder to breach. Ours starts from the assumption that it sometimes will be breached, attestation and all, and asks what a consumer can observe from the outside that the producer, by definition, cannot.
The answer is behavior. Not provenance — behavior. The thing the package does when you run it somewhere the attacker is not watching, compared against everything it claimed about itself. When those two disagree, you do not need to know the attacker’s name, the C2 domain, or the obfuscation routine. You need the diff, and a receipt you can hand an auditor without flinching.
That receipt — a controlled detonation, a behavioral diff against what the artifact claimed, signed — is the same one we said was missing at the end of the antv/g2 read. The OpenSSF post is the industry conceding, in its own vocabulary, that the diff is where the unsolved problem lives. We agree. We are building the diff.
This essay reflects publicly reported indicators of the Mini Shai-Hulud campaign and quotes the OpenSSF post “Where SLSA’s Boundaries Fall” (2026-06-10) and its slsa.dev companion. Attestree is in design-partner mode and pre-GA. Our detonation footprint capture ships today on the Hyper-V and Proxmox/KVM backends; the provenance-versus-behavior diff ships flag-only for winget and Chocolatey today, with the enforcing promotion gate built but default-off. The npm rendition is on the published roadmap. We do not claim to have caught this campaign. We claim that the divergence between valid provenance and observed behavior is a control a catalog operator can build, and we are building it.