GitHub Reusable Workflows

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.

Protections

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.

Pull-request Attestation

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": ...
       ...
    }
  }
}

Links

• 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:
  • Cosign
    • Race condition when creating multiple signatures
  • Gitsign
  • provenance generation and verifying attestation using cosign with new predicate type
• Spicing up Container Image Security with SLSA & GUAC - Ian Lewis, Google
• Supply-chain Levels for Software Artifacts, SLSA
• Inspiration:
  • github.com/liatrio/gh-trusted-builds-workflow