Unsigned artifacts remove a reliable way to prove what was built, so tampered output can be redeployed repeatedly. Shared runners create lateral spread risk because one infected job can contaminate other jobs through disk, cache, or workspace reuse. Together, these gaps turn a small infection into a persistent supply chain problem.
Why This Matters for Security Teams
Unsigned build artifacts and shared CI runners are not just hygiene issues. They weaken provenance, integrity, and containment at the exact point where software becomes deployable. If a pipeline cannot prove which code, dependencies, and configuration produced a package, then downstream release and incident response decisions are built on trust rather than evidence. NIST SP 800-53 Rev 5 Security and Privacy Controls frames this problem through integrity, configuration management, and system monitoring expectations, which is why build assurance belongs in the control set rather than in informal engineering practice.
The practical risk is that one compromised job can alter outputs that look legitimate enough to pass internal handoffs, artifact repositories, or deployment automation. Shared runners amplify this because cache reuse, workspace residue, and insufficient job isolation can let one workload influence the next. That turns a single compromise into a repeatable supply chain failure, especially when teams assume the pipeline itself is the trust boundary.
In practice, many security teams discover this only after a release has already been trusted, deployed, and used as the starting point for further compromise, rather than through intentional build provenance checks.
How It Works in Practice
Build integrity depends on two separable capabilities: proving what was produced and constraining where production happened. Signing artifacts gives downstream systems a way to verify origin and integrity, while isolated runners reduce the chance that one job can tamper with another. Current guidance suggests treating both as complementary controls, not alternatives. A signed artifact from a noisy, shared runner still deserves scrutiny, and a hardened runner still leaves uncertainty if output cannot be authenticated.
Operationally, teams usually need four layers:
- Generate artifacts in ephemeral runners with minimal image scope and no long-lived secrets on disk.
- Sign build outputs and store signatures separately from the artifact, with key custody controlled through a dedicated trust boundary.
- Attach provenance metadata, including source commit, builder identity, dependency inputs, and time of build, so later validation can detect mismatch.
- Verify signatures and provenance before promotion into registries, deployment systems, or release automation.
For software supply chain assurance, NIST SP 800-53 Rev 5 Security and Privacy Controls remains useful for mapping these measures to configuration management, auditability, and integrity requirements. Where teams use shared CI infrastructure, the relevant question is not whether a runner is convenient, but whether its isolation is strong enough to block cross-job contamination of caches, build layers, or temporary files. Best practice is evolving toward signed provenance and ephemeral execution, but there is no universal standard for tool-specific enforcement yet.
These controls tend to break down when runners are long-lived, stateful, and reused across projects because residual files, cached dependencies, or leaked credentials can persist beyond a single job.
Common Variations and Edge Cases
Tighter build isolation often increases cost, latency, and operational overhead, requiring organisations to balance supply chain assurance against delivery speed. That tradeoff is real in large environments with many pipelines, especially when legacy jobs assume persistent workspaces or local caches.
One common edge case is air-gapped or highly regulated environments where signing is present but key rotation and verification are inconsistently enforced. Another is containerized CI where the runner is “ephemeral” on paper, but shared base images, mounted volumes, or remote cache backends reintroduce cross-job exposure. There is also a difference between internal package promotion and external release: a private artifact registry may accept weaker controls temporarily, but that should not be mistaken for acceptable production assurance.
Teams also need to distinguish between artifact signing and full provenance. Signing confirms the package has not changed since it was signed, but it does not by itself prove the build path was clean. For that reason, many programs pair signing with provenance attestations and restricted runner identity, using CISA secure development guidance and OWASP SAMM to operationalize maturity checks. In environments that depend on third-party CI plugins, shared package mirrors, or untrusted pull-request builds, the assurance model weakens fastest because the pipeline inherits trust from components it does not fully control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS | Artifact signing protects data integrity across the release pipeline. |
| MITRE ATT&CK | T1552 | Shared runners can expose credentials left in workspaces or caches. |
| NIST AI RMF | GOVERN | Supply chain trust needs explicit ownership and risk governance. |
Verify artifact integrity before promotion and block unsigned outputs from deployment.
