Ask a software vendor how its builds are isolated, whether artifacts come with verifiable provenance, who can change build steps, how signing keys are protected, and whether it can show the source commit behind a given release. Vague answers about being careful are a signal in themselves.
What a build compromise is
A build system compromise is an attack on the pipeline that turns source into a shippable artifact. The source repository can look clean while the output is not. CISA's advisory on the SolarWinds Orion incident states that a malicious version of a DLL was added to the vendor's software lifecycle and signed with the vendor's legitimate code signing certificate. A valid signature, in other words, proved who signed it, not that the build was clean.
The SLSA threat model lists the pieces that can fail: tampering with the build process, forging provenance, stealing cryptographic secrets, poisoning the build cache, and uploading a package that did not come from the expected build.
Questions to ask, grouped
Isolation and access
- Are builds run in ephemeral, isolated environments, or on long-lived shared machines?
- Who can edit the build definition, and does a change need a second reviewer?
Provenance
- Do releases include signed provenance that names the source repository, commit and builder?
- Can a customer verify it, and have you documented how?
Secrets and signing
- Where do signing keys live, and can a build job read them directly?
- Are publishing credentials short lived?
Traceability
- Can you map any shipped version to the exact commit and build run?
- Can you list the build dependencies you used for that release?
How to judge the answers
A good answer is specific and checkable: a named control, an owner, and evidence you can request. A weak answer is a policy statement with no mechanism. Be careful with certifications as a substitute. A report scopes what it covers, so ask what exactly was in scope.
NIST describes its Secure Software Development Framework as offering a common vocabulary that purchasers can use when communicating with suppliers. Using its terms keeps the conversation concrete.
What you can do on your side
You cannot inspect a vendor's build. You can limit what an update can do after it lands: restrict network egress for the software, keep an inventory of what you run, stage updates, and keep a way to roll back. For build compromises, these downstream controls matter most because the artifact may carry a valid signature.
Try it yourself
Open the demo and see how a pull request gate checks changes before they merge. It shows the same idea of verifying before trust, applied to your own pipeline.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
For your own pipelines, Safeguard offers policies, gates and guardrails plus SBOM and dependency scanning, so you can set rules on what enters a build and see what it contains. Try the free scan.
Quick check
If an update is signed, can I trust it?
A signature shows the signer's key was used. It does not show the build was clean, as the SolarWinds case illustrates.
Can I verify a vendor's build myself?
Usually not directly. You can ask for provenance and traceability, and limit what the software can do after install.
Sources
- CISA AA20-352A, SolarWinds Orion compromise
- SLSA v1.0, Threats and mitigations
- NIST SP 800-218, SSDF
Last reviewed: 19 October 2026.
