The path from build to classified deployment

Andrew Nesbitt put the procurement question in one line in May 2026: a hash in a lockfile tells you the bytes haven’t changed since you locked them, but it can’t tell you they were ever the right bytes.¹ The point survives translation into procurement vocabulary cleanly. Signing produces forensic certainty after the fact, not prevention before it. The procurement objection that follows (“why pay for an attestation layer when nothing visible is wrong”) asks the wrong question. The right question is what evidence the deployment chain produces on the day something does go wrong, and whose jurisdiction the evidence lives under.

That’s the question this essay walks. The current wave of supply-chain compromises is a build-system story rather than a key-management one, and treating it as the latter misses the operational class of failure that’s live in 2026. The procurement evaluation has to move with it.

The current wave is build-system credential theft

The last quarter of incident reports doesn’t describe stolen signing keys. It describes stolen build-system credentials. The distinction matters because the procurement controls that defend against the first class do nothing against the second.

The npm worm campaign that researchers track as Shai-Hulud is the clearest specimen. Palo Alto Networks Unit 42’s reporting documents a self-propagating chain that compromises a maintainer’s account, publishes a poisoned package version, and during the package’s install hook scrapes the ephemeral cloud credentials sitting in the build job’s environment. Those credentials then publish further poisoned versions under any account the original maintainer had write access to. The signatures on the poisoned versions are valid. The build system issued them honestly to an identity it trusted.²

The TanStack incident in November 2025 is the same shape, captured by Orca Security in a post-mortem the procurement evaluator can read end to end. A maintainer credential was compromised, a poisoned version was published, the install-time payload reached into the build environment to extract whatever cloud credentials were within reach, and the worm continued. The build-system signing identities were used rather than bypassed.³

The Ultralytics compromise in December 2024 is the case the Python Package Index documented from the inside. The PyPI post-mortem walks the attack chain in plain language: a malicious pull request reached a public continuous-integration job, the job’s signing identity was used to publish a poisoned release, and the legitimate maintainer’s keys weren’t involved at any step. PyPI’s own write-up is unusually candid about what the public attestation infrastructure caught and what it didn’t.⁴

The two legacy reference points are still worth carrying in the procurement vocabulary, because they describe failure modes the current wave inherits. The xz backdoor disclosed in March 2024 was a multi-year social-engineering campaign that ended with a malicious contributor’s commits in a load-bearing compression library shipped through every major Linux distribution; only an accidental performance regression triggered the discovery.⁵ The SolarWinds compromise, catalogued by MITRE as campaign C0024, modified a vendor’s build output before the vendor’s own signing step, so every downstream customer received correctly-signed malicious software.⁶ Both incidents share the structural property that the signatures on the malicious artifacts were faithful. The compromise lived upstream of the signing event.

In none of these incidents did the cryptographic primitives fail. What failed in each was who the signing system trusted, and where that trust was scoped.

What the cloud-native signing path bought, and what it didn’t

The public-log signing model that the cloud-native ecosystem standardized on in the last five years did exactly what it was designed to do. After each incident named above, investigators reconstructed the attack chain from public records: the timing of the malicious publish event, the identity that issued the signature, the build job that requested it. The PyPI Ultralytics post-mortem is the cleanest worked example. Forensic attribution moved from “we think this is what happened” to “here is the cryptographic record of what happened” in a matter of hours.⁴

That is a real procurement win, and it should be named as one. The federal government has standardized on signed provenance as the supplier deliverable: the CISA Secure Software Self-Attestation Form requires the responsible executive of any software vendor selling to a federal agency to attest that the company has applied the practices in the federal Secure Software Development Framework, with signed build provenance as the evidentiary backbone.⁷ The form is short, the signature is personal, and the consequence for misattestation is liability. The infrastructure underneath it works.

What it doesn’t do is stop a poisoned build from being faithfully signed. The Shai-Hulud, TanStack, and Ultralytics incidents are the live, unmitigated class, where the build system signed honestly over input that was already wrong. Forensic certainty after the fact is exactly the procurement property the federal attestation form requires, and it was never claimed to be prevention.

What changes when the build identity is hardware-backed and the apply path is air-gapped

The procurement question for a classified workload sits one step further in. The federal attestation form is written for the open commercial supply chain, where forensic certainty after the fact is the achievable property and the regulator absorbs the cost of the events that produce evidence. A classified workload can’t absorb those events the same way. The operational class of failure has to be moved.

That movement has four structural pieces, none of which depends on a specific tool name.

The signing identity that produces an artifact for classified deployment is held in a hardware device the operator physically possesses. The private key never sits in a build job’s memory, where the Shai-Hulud install hook can scrape it. The act of producing a signature requires a physical touch on the device by the operator. A stolen build-system credential cannot exercise the signing identity by itself.

The verification path runs on infrastructure the deploying organization controls. The check that a deployable artifact carries a valid signature doesn’t depend on reaching a public transparency log run by a foreign-jurisdictional vendor. The verification machinery is air-gapped from the public internet, by design, on the day a classified deployment happens. The procurement question of “what happens to the deployment if the public log is unavailable, compromised, or compelled” stops applying.

The attestation record the apply event produces belongs to the deploying organization. The cryptographic record of which artifact reached which cluster, signed by which identity, at which time, is the operator’s evidence in the operator’s custody. Rather than a query against a third party’s database, it lives where no one other than the operator can edit or compel it. A procurement audit reaches into the operator’s own systems for the record. (The Northfleet platform is built around this property.)

Verification works offline with cryptographic tooling auditors already own. The accreditor doesn’t need a vendor binary on the audit machine to check the signatures, the hash chain on the audit log, or the provenance record. The work is auditable with stock open tooling on an offline workstation. Vendor dependency at audit time is, itself, a procurement liability.

Five procurement-evaluatable questions for the build-to-deployment chain

The shape of the procurement evaluation follows from those four structural pieces. Five questions cover the surface, and a vendor can’t credibly answer them with marketing copy.

1. Where does the signing identity that produces the deployable artifact actually live? A private key resident in a cloud build runner’s memory is one credential-theft incident away from issuing valid signatures over poisoned bytes. A signing identity bound to a hardware device the operator physically holds, requiring an explicit per-signature action, is not. The procurement-evaluation answer rests on structure rather than on a contractual promise.

2. Whose transparency log does the signature record depend on? A signature that can only be verified by reaching a public log run by a foreign-jurisdictional vendor has imported that vendor’s jurisdiction into the deployment chain. A signature whose record is held by the operator, on the operator’s infrastructure, has not. The question is supply-chain provability stated in jurisdictional terms.

3. Can apply-time verification run with the deployment network disconnected from the public internet? Verification that requires a callout to any external service is incompatible with classified deployment by definition. What matters is whether the default verification path requires reach-back at all, not whether the vendor’s product can be coaxed into an air-gapped configuration as an option.

4. What evidence does the apply event itself produce, and what is its integrity property? A log file on a shared filesystem, editable by anyone with write access, is not evidence in an accreditation sense. A cryptographically chained record, bound to an individual identity, where any tampering with a prior entry invalidates the chain, clears that bar. The evidence the procurement evaluation accepts is whatever the apply event produces by construction.

5. Is a privileged bypass possible, and is it audited? Operators will face the case where a deployment must proceed under conditions the verification rules refuse. The procurement-honest answer is not “impossible by construction,” because impossible-by-construction systems develop side-channel bypasses the audit trail doesn’t see. The procurement-honest answer is a named, audited bypass operation that requires a justification entered into the same hash-chained record. An audited bypass is the operationally truthful choice.

The honesty close

Signing attests provenance, and it stops short of attesting build-input integrity. A build poisoned upstream of the signing event is faithfully signed by the operator’s hardware identity, and the signature doesn’t catch what happened earlier in the chain. The deployment-time controls aren’t defective here. They have reached the boundary of what cryptography can prove, and any vendor claiming otherwise is selling marketing copy rather than procurement-grade work.

What the deployment-time controls do is what they’re designed to do, and what the federal attestation form requires the supplier to deliver: refusal of tamper in transit, individual-identity-bound apply at the destination, a cryptographically chained record of every privileged operation, and offline verification with tooling the auditor already owns. The accreditor evaluating a classified procurement is looking for those four properties named explicitly and demonstrated against a real bundle, not for a prevention claim that no honest vendor can make.

The procurement evaluation this corpus has been building toward is the one that asks the five questions above, in plain language, of every vendor in the trust path between build and apply. The vendors that answer them structurally are the vendors that can be defended in a contracting review. The vendors that answer them with phrasing about prevention are the vendors who haven’t read the incident reports of the last quarter.

If you’re evaluating sovereign infrastructure for classified workloads, or building toward a procurement evaluation that will ask the five questions above, the conversation is open.

Footnotes

1. Andrew Nesbitt, “Signing is for the bad days,” May 24, 2026. https://nesbitt.io/2026/05/24/signing-is-for-the-bad-days.html (accessed 2026-05-27). ↩

2. Unit 42, Palo Alto Networks, “Monitoring NPM supply-chain attacks: the Shai-Hulud campaign.” https://unit42.paloaltonetworks.com/monitoring-npm-supply-chain-attacks/ (accessed 2026-05-27). ↩

3. Orca Security, “TanStack npm supply-chain worm.” https://orca.security/resources/blog/tanstack-npm-supply-chain-worm/ (accessed 2026-05-27). ↩

4. Python Package Index, “Ultralytics attack analysis,” December 11, 2024. https://blog.pypi.org/posts/2024-12-11-ultralytics-attack-analysis/ (accessed 2026-05-27). ↩ ↩²

5. Andres Freund, “backdoor in upstream xz/liblzma leading to ssh server compromise,” openwall oss-security archive, March 29, 2024. https://www.openwall.com/lists/oss-security/2024/03/29/4 (accessed 2026-05-27). ↩

6. MITRE ATT&CK, “SolarWinds Compromise,” campaign C0024. https://attack.mitre.org/campaigns/C0024/ (accessed 2026-05-27). ↩

7. Cybersecurity and Infrastructure Security Agency, “Secure Software Self-Attestation Form.” https://www.cisa.gov/secure-software-attestation-form (accessed 2026-05-27). ↩