This repository have reusable workflows for building a SLSA level 3 secure software supply chain.
The following figure illustrates SLSA Supply chain threats:
See example application pository for an example use of the workflows from this repositoty.
Mitigation of threats as described by SLSA are described below.
Legend
- 📝 Attestation or other metadata produced/used by workflows.
- ⛔ Control/governance point, i.e. decision point for accepting artifacts.
- 🎩 Trusted process through separation of duties.
- ❌ No mitigation
Mitigation mechanisms for threat-points from figure above:
- A. Submit unauthorized source:
- 📝 PR provenance attestation showing PR status, who reviewed, approved and merged etc.
- TODO: Investigate Gittuf
- B. Compromised source repository:
- ❌ None
- TODO: Produce Git signature attestation
- C. Build from modified source
- ❌ None
- TODO: Produce Git signature attestation
- D. Compromised dependencies
- 📝 SBOM attestation
- 📝 Container CVE scan attestation
- E. Compromised build process
- 🎩 Separated workflows using GitHub reusable workflows
- 📝 SLSA provenance using the slsa-github-generator
- ⛔ Apply organisation policies using artifact-underwriter
- 📝 Generate Verification Summary Attestation (VSA) based on organisation policy verification status
- F. Upload modified artifacts
- 📝 Container digest used throughout workflows
- 📝 Container signed
- G. Compromised artifact storage
- 📝 Container digest used throughout workflows
- 📝 Container signed
- H. Deploy compromised artifact
- 📝 Container digest used to identify container artifact
- 📝 Container signed
- ⛔ Sigstore policy controller policies
Note, that SLSA levels describe the build-phase and does not cover the source-phase, i.e. tampering with the source prior to building.
The policy-verification workflow applies Rego-based organisation policies to the attestions produced by prior workflows using artifact-underwriter. Based on the policy verification result, a Verification Summary Attestation (VSA) is issued.
The attestations produced by the workflows are generally standardised, except for the pull-request attestation since no standard exists. The produced pull-request attestation are summarised below.
{
"_type": "https://in-toto.io/Statement/v0.1",
"predicateType": "https://github.com/michaelvl/gha-reusable-workflows/pr-provenance",
"subject": [
...
],
"predicate": {
"pull_requests": {
"associatedPullRequests": {
"nodes": [
{
"author": {
... # Who created the PR
},
"approvers": {
... # Who approved the PR
},
"assignees": {
... # PR review assignees
},
"body": ..., # Body text of PR
"mergedAt": ...
"mergedBy": ... # Who merged the PR
"reviewDecision": # Overall review state
"state": "MERGED",
"title": ...
}
]
},
},
"repository": { # Git references
"digest": {
"sha1": ...
},
"name": ...
"ref": ...
...
}
}
}
- GitHub attacks and protections
- GitHub attack tree: SLSA dip — At the Source of the problem!
- Using SSH does not imply Git integrity
- GitHub action pinning ratchet
- Signing artifacts:
- Spicing up Container Image Security with SLSA & GUAC - Ian Lewis, Google
- Supply-chain Levels for Software Artifacts, SLSA
- Inspiration: