SLSA

Per Supply-chain Levels for Software Artifacts (SLSA) v1.0+: build integrity. Requirements include (a) Source - version controlled + auditable + (b) Build - scripted + isolated + parameterless + hermetic + reproducible + (c) Provenance - generated by isolated builder + complete attestation + cryptographically signed + (d) align with SLSA Build Levels L1-L4.

• SLSA evidence for SUPCHAIN-1

• L4 + verification + SBOM partial

Document the build process so that any party with the source can reproduce or verify how artifacts are produced, including tooling versions and steps.

• README or BUILDING.md describing build steps
• Dockerfile or build container definition
• Build tool version pins (Bazel, Make, Gradle, npm)
• Build script in repository

• Build steps only known to one engineer
• Tooling versions floating and not pinned
• Manual steps undocumented in CI configuration

Generate and distribute SLSA provenance attestations alongside each released artifact, describing how the artifact was built.

• in-toto attestation JSON file per artifact
• Provenance predicate (SLSA Provenance v1)
• Release page showing attestation alongside binary
• SHA256 digest of artifact referenced in provenance

• Provenance generated but not published with release
• Provenance missing subject digest binding
• Provenance only available for some artifacts in release

Run builds on a hosted build platform that is administered separately from individual developers, removing reliance on developer workstations.

• CI service identification (GitHub Actions, GitLab CI, Buildkite, Tekton)
• Workflow YAML stored in repository
• Build runner inventory and ownership
• Admin access list for build platform

• Builds run on developer laptops or shared VMs
• Self-hosted runners with no isolation between projects
• Workflow files editable without code review

Cryptographically sign provenance attestations using a key controlled by the build platform so that consumers can verify authenticity.

• Sigstore Cosign signature or DSSE envelope
• Fulcio certificate or long lived public key
• Rekor transparency log entry
• Documented verification procedure for consumers

• Provenance unsigned or signed by developer key
• Public verification key not published
• Signature scheme not bound to build platform identity

Operate the build platform such that build steps cannot inject false provenance, with tenant isolation and ephemeral build environments.

• Build platform threat model and L3 conformance statement
• Configuration showing ephemeral or single use runners
• Build secret access policy
• Penetration test or external review of build platform

• Long lived runners reused across projects
• Build user able to read signing key material
• No documented threat model for the build platform

Generate provenance in a control plane that the build steps cannot influence, ensuring the attestation reflects what actually ran.

• Architecture diagram showing control plane vs worker
• Code reference for provenance generator (GitHub OIDC, SLSA GitHub generator)
• Audit log showing provenance produced by control plane
• Evidence build steps cannot write to attestation

• Provenance generated inside the same job as the build
• Build steps can edit attestation before signing
• No log proving control plane authored provenance

Record all build parameters and environment variables that influence the output, capturing them in provenance for reproducibility analysis.

• Provenance buildDefinition.externalParameters field populated
• Provenance buildDefinition.internalParameters where applicable
• Documentation of which parameters affect output
• Sample provenance showing complete parameter set

• Provenance lists empty external parameters
• Secret values or non determinism not noted in provenance
• Different invocations producing artifacts with no recorded parameter diff

Maintain the integrity of build runners through patched base images, restricted network egress, and segregation of duties.

• Runner image build pipeline and version inventory
• Network egress allow list for build jobs
• Runner patch and rebuild schedule
• Access control restricting who can SSH or exec into runners

• Long lived runners with unpatched OS
• Builds with unrestricted internet access enabling exfiltration
• Engineers with shell access to production runners

Per SLSA Dependency Track: dependencies. Requirements include (a) Software Bill of Materials (SBOM) + (b) dependency verification + provenance + (c) vulnerability scanning + (d) license + malicious package screening + (e) reproducible dependency resolution.

• SLSA evidence for SUPCHAIN-3

• L4 + verification + SBOM partial

Maintain an accurate inventory of all direct and transitive dependencies consumed by the software, with version pinning.

• package-lock.json, poetry.lock, go.sum, Cargo.lock or equivalent
• CycloneDX or SPDX SBOM per release
• Container base image manifest with pinned digests
• Vendored dependency directory or proxy configuration

• Lock files not committed or out of date
• Floating tags used for container base images
• SBOM generated but never compared release to release

Verify provenance and integrity of dependencies before they enter the build, using digests, signatures, or trusted registries.

• Package manager integrity check configuration (npm audit signatures, pip hashes)
• Internal artifact proxy or repository (Artifactory, Nexus, GitHub Packages)
• Cosign verify policy for container images
• Allow list of approved registries

• Direct pulls from public registries without hash verification
• No verification of upstream signatures even when provided
• Mirror not configured to reject unsigned uploads

Continuously monitor dependencies for known vulnerabilities and apply patches or mitigations on a defined schedule.

• Dependabot, Renovate or Snyk configuration
• Vulnerability scanner report per release
• Triage queue or issue tracker showing CVE handling
• Remediation SLA policy by severity

• Critical CVEs open beyond SLA
• Scanner findings ignored without documented rationale
• No alerting when new CVE published against pinned versions

Publish or maintain expectations describing the source repository, builder, and provenance fields that must match for an artifact to be trusted.

• YAML or JSON expectations file in version control
• Mapping of artifact name to expected builder ID and source URI
• Change history showing review of expectations updates
• Test cases proving expectations match real provenance

• Expectations only in engineer head, not file
• No process to update expectations when builder changes
• Single global expectation, not per artifact

Identify and document the producer (organization or team) responsible for each software artifact, enabling consumers to trace artifacts back to a known accountable party.

• Producer identity document (name, contact, public key)
• Repository CODEOWNERS file
• Published producer page on project site
• Signed producer statement bound to artifacts

• Anonymous or shared maintainer accounts with no real identity tie
• No published contact for security disclosures
• Producer identity not bound to signing keys

Host source code in a version controlled repository that records all changes with author attribution and immutable history.

• Git repository URL and config export
• Branch protection settings screenshot
• Commit signing policy
• Force push and history rewrite restrictions

• Force pushes allowed on protected branches
• Commits without verified author identity
• Local mirrors not synchronized with canonical source

Per SLSA Source Track: source integrity. Requirements include (a) branch protection + signed commits + (b) code review + two-person review for changes + (c) source repository security + (d) developer identity + access controls + (e) audit log of changes.

• SLSA evidence for SUPCHAIN-2

• L4 + verification + SBOM partial

Ensure source code history is verifiable, with commits bound to identified contributors and history protected from rewriting.

• Branch protection requiring signed commits
• GPG or sigstore commit signature policy
• Audit log of force push attempts blocked
• Contributor identity verification process

• Unsigned commits accepted on default branch
• Bot accounts pushing without identity binding
• History rewrites accepted via admin override

Require that every change to protected branches is reviewed and approved by at least one party other than the author.

• Branch protection rule requiring pull request approval
• Sample pull requests showing reviewer approval
• List of users with admin bypass and justification
• CODEOWNERS file routing reviews

• Self review allowed by admins
• Bypass used routinely for hotfixes without compensating control
• Approval given by same person via shared bot account

Maintain a documented procedure to respond to supply chain incidents affecting source, build, or dependencies, including artifact recall.

• Supply chain incident response runbook
• Past incident postmortem (or tabletop exercise record)
• Public security advisory template
• Process to revoke or yank affected releases

• No runbook specifically for build platform compromise
• No way to invalidate provenance or signal compromise to consumers
• Incident process exists but never exercised

Per SLSA Verification: verification + attestation. Requirements include (a) verify provenance attestations + (b) integrate with in-toto + Sigstore + (c) implement verification policy + (d) reject unverified artifacts + (e) integrate with admission control.

• SLSA evidence for SUPCHAIN-4

• L4 + verification + SBOM partial

Verify SLSA provenance on artifacts before deploying or installing them, including signature, builder identity, and source reference.

• slsa-verifier or cosign verify command in deployment pipeline
• Admission controller policy (Kyverno, OPA, Gatekeeper)
• Logs showing failed verification rejecting deployment
• Documented expected builder identity per artifact

• Verification logs absent or only warning, not blocking
• Builder identity not pinned, allowing any signed artifact
• Verification skipped for break glass deployments

Store and distribute released artifacts in a registry that preserves immutability and supports digest based retrieval.

• Container registry with immutable tags or digest pinning
• Object storage with versioning and write once policy
• Access control matrix for publish vs read
• Replication and backup configuration

• Tags overwritten in container registry
• Public artifact bucket without integrity logging
• Single registry without backup for recovery

Produce Verification Summary Attestations after verifying an artifact, so downstream consumers can rely on the verification result without rerunning all checks.

• VSA in DSSE format signed by verifier identity
• Mapping of VSA verifier identity to consumer trust list
• Storage location of VSAs alongside artifacts
• Documented policy mapping VSA result to deployment decision

• No VSA produced, every consumer reverifies independently
• VSA produced but never signed
• VSA result not checked at deployment gate