💡 Artifact Attestation and SLSA Build Provenance Org-Wide Enforcement

[github-actions[bot]]

Summary

Adopt GitHub's artifact attestation feature org-wide by adding actions/attest-build-provenance to the canonical CI template, defining an org policy for attestation verification, and preparing for GitHub's shift toward making attestation generation the default for public repositories. This completes the supply chain integrity picture: the org already verifies what goes IN (action SHA pinning) but does not yet certify what comes OUT (artifact provenance).

Market Signal

• GitHub is transitioning artifact attestation from opt-in to default for public repositories in 2026 (GitHub Docs: Artifact Attestations)
• Attestations bind artifacts to specific workflow runs via SLSA Build Provenance predicates using Sigstore-backed keyless signing — ephemeral certificates that live for 10 minutes, with proof on an immutable transparency log
• Enforcement tools have matured: Kubernetes admission controllers (gh attestation verify), organization-level attestation policies, and linked artifacts pages with build history
• SLSA L1 provenance is becoming table stakes for software supply chain security — the framework adoption is accelerating across GitHub, Google, and the OpenSSF ecosystem
• The 2026 guide to software supply chain security identifies agentic governance of build provenance as an emerging best practice

User Signal

The org has strong supply chain INPUT verification but no OUTPUT certification:

Supply Chain Phase	Current Standard	Status
Action inputs	SHA pinning (ci-standards.md)	✅ Enforced
Secret inputs	Push protection (push-protection.md)	✅ Enforced
Dependency integrity	Idea #295 (Workflow Dependency Integrity Verification)	🔄 Proposed
Artifact outputs	None	❌ Gap

The recently merged CI template updates (#578: secret-scan + coverage jobs) provide a natural integration point. The existing deploy-standard-workflows.sh script handles fleet-wide rollout of template changes.

Technical Opportunity

The org's CI template (standards/workflows/) is the single point of leverage:

# Addition to the canonical CI template
- name: Attest build provenance
  uses: actions/attest-build-provenance@<SHA>
  with:
    subject-path: '<artifact-path>'

This single template change propagates attestation to all consuming repos via the standard workflow deployment mechanism. Verification can be enforced via:

1. gh attestation verify in downstream consumption workflows
2. Kubernetes admission controllers for containerized deployments
3. Organization-level attestation policies (GitHub Enterprise)

The attestations: write permission must be added to workflow permissions blocks — the org's restrictive permissions pattern (ci-standards.md) means this must be explicitly declared.

Assessment

Dimension	Score	Rationale
Feasibility	high	Well-documented action exists; single template change propagates org-wide
Impact	high	Completes the supply chain integrity picture; creates cryptographic audit trail for CI artifacts
Urgency	med	Becoming default for public repos; internal repos benefit from attestation for agent-deployed changes

Adversarial Review

Strongest objection: The org's repos are mostly private internal tooling. SLSA provenance is designed for public package distribution — who would verify these attestations?

Rebuttal: Supply chain integrity isn't just about public distribution — it's about internal trust boundaries. With multiple downstream repos (Broodly, TalkTerm, markets) consuming reusable workflows and scripts from .github, attestation provides cryptographic proof that an artifact was built by the expected workflow at the expected commit. This matters especially when the org's own CI agents (dev-lead, compliance-audit) automatically deploy changes — attestation is the chain-of-custody record. Additionally, if any org repo ever publishes packages or containers, the infrastructure is already in place.

Suggested Next Step

Add actions/attest-build-provenance to the canonical CI template in standards/workflows/ci.yml, define an org attestation policy in standards/artifact-attestation.md, and update ci-standards.md with verification requirements.