Security teams should treat the build pipeline as a high-value attack surface and protect it with layered controls. That means hardening CI/CD systems, restricting developer and administrator access, inspecting dependencies before build time, and verifying what gets signed and released. Runtime detection helps, but it is a late control. The strongest defense is to prevent malicious code from entering the software release process at all.
Where build and signing infrastructure becomes the real target
Build systems are not just developer plumbing, they are trusted decision points that turn source code into something users install and trust. If an attacker can alter dependencies, inject code into a pipeline, steal signing keys, or abuse release permissions, they can turn a normal release process into a distribution channel for malicious software.
The defensive implication is that the software supply chain must be treated as a trust boundary, not a convenience layer. Controls need to cover source intake, dependency resolution, build execution, artifact promotion, signing, and release approval as separate steps, because compromise at any one of them can contaminate the final product.
That is why provenance and artifact integrity matter as much as code review. The goal is not just to detect bad code after the fact, but to make it harder for unapproved code to enter the build path and harder for unsigned or unexpectedly signed output to leave it. Guidance such as SLSA and NIST SSDF (SP 800-218) is useful here because both emphasise build integrity, controlled dependencies, and verifiable release practices.
Controls that matter before, during, and after the build
Defence should start with the smallest trusted computing base possible. That means locking down who can change pipeline definitions, who can approve privileged jobs, where build runners execute, and which secrets are available to each stage. A compromised runner or overprivileged service account often gives an attacker more practical leverage than the source repository itself.
Dependency hygiene is equally important. Teams should pin versions, verify package integrity where possible, and block unexpected dependency sources or publisher changes. For open source ecosystems, this is not a theoretical risk: malicious packages and compromised maintainer accounts are common entry points, so dependency controls need to be part of release engineering, not just AppSec.
Signing should also be separated from build execution. Ideally, the system that compiles software should not be the same system that holds long-lived signing material. If signing keys, certificates, or signing services are reachable from ordinary build jobs, the attacker only needs one pipeline foothold to produce trusted output. That is why artifact attestation, short-lived credentials, and restricted release promotion paths are so important.
For teams looking for a broader defensive reference set, OpenSSF is useful for ecosystem guidance, while CISA cyber threat advisories help teams track active supply chain patterns and adversary tradecraft.
Why supply chain compromise is hard to spot and why prevention wins
Build and signing attacks are attractive because they abuse trusted automation. Once malicious code passes through a legitimate pipeline, downstream customers, security tools, and update mechanisms may accept it as authentic. That means compromise is often discovered late, after artifacts have already been propagated widely.
This also creates a detection problem. Runtime alerting can confirm suspicious behaviour after deployment, but it rarely prevents a tainted package, image, or update from being distributed. The strongest control point is therefore upstream: stop unauthorised changes, prevent secret exposure, harden runners, and make signing conditional on controlled provenance rather than on pipeline success alone.
Threat reporting from CISA and the ENISA Threat Landscape both reinforce the same operational lesson: supply chain compromise tends to combine access abuse, trust exploitation, and persistence through legitimate delivery channels, so recovery is slower and blast radius is larger than with ordinary endpoint malware.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Controls who can alter build and signing systems. |
| 8 — Audit Log Management | Supports detection of pipeline abuse and release tampering. | |
| Recommendation — Restrict privileged access to pipeline and signing infrastructure. Log build, signing, and release events for tamper-aware monitoring. | ||
| NIST CSF 2.0 | PR.AC — Access Control | Build and signing paths depend on least-privilege access decisions. |
| PR.DS — Data Security | Protects secrets, signing keys, and release artifacts from exposure. | |
| DE.CM — Continuous Monitoring | Pipeline compromise often needs telemetry to spot anomalous build activity. | |
| Recommendation — Enforce least privilege across build, signing, and release workflows. Protect signing keys and sensitive build artifacts with strong controls. Monitor CI/CD and signing activity for anomalous or unauthorized actions. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Administrative and release access should be bound to stronger identity assurance. |
| AAL — Authenticator Assurance Level | High-value release actions need stronger authentication than ordinary developer access. | |
| FAL — Federation Assurance Level | Federated access to pipeline tools must preserve trust in privileged actions. | |
| Recommendation — Require stronger identity proofing for privileged build and signing access. Use high-assurance authenticators for signing and release approvals. Apply stronger federation controls to privileged CI/CD access paths. | ||
| NIST Zero Trust (SP 800-207) | 3 — ZTA Policy Engine and Policy Administrator | Central policy helps control who can execute trusted build and signing actions. |
| 2 — Zero Trust Architecture Logical Components | Build runners, registries, and signing services should be segmented trust components. | |
| Recommendation — Centralize policy decisions for privileged pipeline and signing actions. Segment build, signing, and release components into distinct trust zones. | ||
Practitioner Guidance
What to prioritise: Protect the signing path and the build runner before you spend time on downstream detection. If an attacker can get code into the release process or reach signing material, your confidence in every later control drops sharply.
What to verify: Confirm that pipeline administrators, release approvers, and key custodians are not the same standing identity set, and that build jobs cannot read secrets they do not need. Also verify that release artifacts can be traced back to a controlled, reproducible build input set.
Common mistake: Treating CI/CD hardening as a one-time configuration task. Build and signing infrastructure changes constantly, so access paths, secrets, and dependency sources need continuous review, especially after toolchain upgrades or new integrations.
Practitioner takeaway: The right defence is not “detect compromise faster”, it is to make unauthorised code materially harder to build, sign, and ship in the first place.
Related resources from NHI Mgmt Group
- How should security teams defend against npm supply-chain attacks that use typosquatted packages and multi-stage loaders?
- How should security teams defend against typosquatting attacks in software supply chains?
- How should teams implement software supply chain security across build pipelines?
- How can security teams detect package supply chain attacks that hide their C2 infrastructure?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
