Artefact integrity and provenance

The security of an application depends on trust in the artefacts that are produced and distributed. If an artefact (e.g. binary, image, package) is manipulated at any stage - build, storage or publication - the resulting software can no longer be trusted.

This practice defines the controls needed to ensure the integrity, authenticity and verifiable provenance of the artefacts generated by CI/CD pipelines.

An artefact must never be published or promoted without proven integrity and verifiable provenance.

---

🎯 Objectives

• Ensure that each artefact was produced in a secure and traceable way;
• Enable automatic verification of the provenance and integrity of artefacts;
• Prevent the publication of manipulated, unauthorised or ambiguous artefacts.

---

🛠️ Practices

1. Digital signing of generated artefacts

   • Each relevant build must produce digitally signed artefacts (e.g. cosign, GPG);
   • Signatures must be stored in a way that is accessible and verifiable by third parties.

2. Automatic generation of provenance metadata

   • Artefacts must contain hashes, code origin, build environment, pipeline ID and timestamp;
   • Provenance must follow the SLSA model (e.g. .intoto) and be generated automatically.

3. Mandatory validation before publication or deploy

   • Artefacts without valid provenance or signature must be rejected;
   • There must be a formal “no provenance, no deploy” policy.

4. Secure storage and transport of artefacts

   • Repositories must support TLS, integrity verification and strong authentication;
   • Publication must be controlled, authorised and auditable.

5. Detection of manipulation or collisions

   • There must be verification mechanisms (e.g. hashes, reproducible builds) that make it possible to guarantee that artefacts have not been altered;
   • Artefacts must be idempotent and verifiable at any time.

---

⚖️ Proportional application by risk level

Level	Mandatory requirements	Enhanced requirements
L1	Hashes and build origin logs	-
L2	Automated provenance; publication control	Formal digital signatures
L3	Complete SLSA provenance; validation policies	Reproducible builds; complete chain of trust

---

📌 Practical examples

• GitHub Actions + Sigstore

  • Generation of .intoto provenance with slsa-github-generator;
  • Signing with cosign; publication only via GitHub Release with verification.

• GitLab CI

  • job artifacts with access control;
  • Integration with Keyless Signing and manual provenance via CI metadata.

• Azure DevOps

  • SHA256 + timestamp artefacts;
  • Publication to Azure Artifacts with validation of origin and publisher.

• Jenkins

  • Integration with GPG for artefact signing;
  • Use of plugins for reproducible builds and policy-based validation before the deploy.

---

📉 Mitigated risks

• Manipulation or substitution of artefacts (OSC&R: CI0011);
• Injection of malicious code via a compromised build (OSC&R: CI0002);
• Publication of artefacts of unknown origin (OSC&R: CI0004, CI0008);
• Use of counterfeit artefacts or artefacts altered in transit.

---