Why do CI/CD pipelines need attestation and access controls for build artifacts?

Attestation matters because a build is only trustworthy if teams can prove where it ran, what transformed the code, and what output was produced. Access controls matter because stored attestations can become evidence of compliance or a target for tampering. Together, signed attestations and protected storage help preserve integrity across the software supply chain.

What attestation proves about a build artifact

Attestation turns a build artifact from an opaque output into something you can verify and audit. It binds evidence to the build context, for example where the build ran, what inputs were used, what transformation occurred, and which output was produced. That evidence is what makes downstream trust decisions possible in a software supply chain.

For teams using modern pipeline controls, the key question is not whether a file exists in the registry, but whether it can be traced back to a known build path and a signed provenance record. That is why provenance and integrity tooling such as SLSA is directly relevant, alongside stronger artifact integrity practices in CI/CD environments like the CI/CD pipeline exploitation case study.

Attestation is most useful when it is machine-verifiable and hard to forge. Signed metadata can show that the artifact came from the expected pipeline, but it only remains meaningful if the signing process itself is protected and the attestation cannot be silently replaced, edited, or detached from the artifact.

Why access control matters for stored attestations

Stored attestations are security-sensitive records, not just documentation. If an attacker can alter, delete, or substitute them, they can undermine evidence of compliance, break release validation, or conceal tampering in the build chain. Access control therefore protects both the artifact record and the trust decisions that depend on it.

This is where repository permissions, signing-key protection, and restricted write access intersect. A pipeline can generate a valid attestation and still be vulnerable if too many identities can publish, overwrite, or approve the resulting metadata. The same pattern appears in real supply-chain compromise scenarios such as the Reviewdog GitHub Action supply chain attack and the Shai Hulud npm malware campaign, where pipeline trust was abused to reach sensitive assets.

In practice, access control should distinguish between the identity that builds, the identity that signs, and the identities that can read or verify attestations. Collapsing those roles increases the chance that one compromised account can both manufacture and bless an artifact.

Risk and Threat Considerations

When attestation storage is writable by the wrong people, the pipeline becomes vulnerable to provenance forgery, tampering, and false assurance. The danger is not just malicious replacement of evidence, but also accidental overwrite or weak retention that leaves teams unable to prove what was shipped.

Failure mechanism: An attacker or insider with excessive access can replace an attestation, steal signing material, or publish an artifact that looks legitimate while bypassing the intended build process.

Impact: Downstream consumers may accept an untrusted release, compliance evidence may be invalidated, and incident response may lose the ability to reconstruct the true build path.

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, CIS Controls v8, 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
NIST CSF 2.0	PR.DS-6 — Data is protected	Build attestations and artifacts must stay protected from tampering.
Recommendation — Protect artifact and attestation stores from unauthorized modification and deletion.
CIS Controls v8	6.8 — Unneeded Access	Restrict who can alter build outputs, signing records, and attestation stores.
	6.3 — Privileged Account Management	Signing and publishing rights are high-value privileges that require tighter control.
Recommendation — Remove unnecessary write access to build and provenance repositories. Limit and monitor privileged accounts that can sign or publish build artifacts.
MITRE ATT&CK	T1552 — Unsecured Credentials	Compromised signing or pipeline secrets can let attackers forge trusted outputs.
Recommendation — Hunt for exposed pipeline secrets that could be used to sign or publish artifacts.
NIST SP 800-63	IAL1 — Identity Assurance Level 1	Trusted pipeline actors need verified identity and controlled issuance before they can sign or publish evidence.
	AAL2 — Authenticator Assurance Level 2	Higher-assurance authentication helps protect accounts that can alter attestations or artifact records.
Recommendation — Require verified identities before granting signing or publication permissions. Use stronger authentication for accounts that manage artifact provenance.
NIST Zero Trust (SP 800-207)	AC-4 — Information Flow Control	Artifact and attestation flows need enforced policy boundaries between build, sign, and release stages.
Recommendation — Enforce policy-based separation between build, signing, and release actions.

Practitioner Guidance

What to verify: Confirm that the attestation is cryptographically bound to the artifact digest and that the storage location prevents unauthorized edits, deletions, and re-publication. If the attestation can be changed without re-signing, the control is weak even if the pipeline is otherwise automated.

Decision rule: If a role can both produce builds and modify attestations, split those permissions immediately. Build-time privilege should be temporary and narrow, while attestations and signing material should be handled as protected security evidence rather than ordinary CI/CD output.

Practitioner takeaway: Treat attestation as integrity evidence and access control as the protection for that evidence, because one without the other can leave a pipeline looking trustworthy while still being easy to subvert.