adaptive-enforcement-lab/slsa-implementation-playbook
plugins/enforce/skills/slsa-implementation-playbook/SKILL.md
Complete SLSA implementation playbook: clarify SLSA vs SBOM confusion, classify runner configurations, implement verification workflows, and adopt incrementally from Level 1 to Level 3.
tools
Updated Mar 27, 2026
$ install --global
skillsauthnpx skillsauth add adaptive-enforcement-lab/claude-skills slsa-implementation-playbookInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Mar 29, 2026, 10:46 AM36.5s5 files scanned
SKILL.md
- name:
- slsa-implementation-playbook
- description:
- >-
- Complete SLSA implementation playbook:
- clarify SLSA vs SBOM confusion, classify runner configurations, implement verification workflows, and adopt incrementally from Level 1 to Level 3.
SLSA Implementation Playbook
When to Use This Skill
Turn supply chain security from aspirational to operational.
What This Playbook Delivers
Clear implementation path from SLSA Level 1 to Level 3. Resolve SLSA vs SBOM confusion. Classify self-hosted runners correctly. Build verification workflows that actually work.
Prerequisites
Before implementing SLSA:
- GitHub Actions (or equivalent CI/CD platform)
- Release artifact publishing (GitHub Releases, container registry)
- Basic understanding of cryptographic signing
- Decision on GitHub-hosted vs self-hosted runners
When to Apply
"We want OpenSSF Scorecard 10/10"
SLSA Level 3 provenance moves Signed-Releases from 8/10 to 10/10.
What you need:
- Generate
.intoto.jsonlattestation files - Upload to GitHub releases
- Use GitHub-hosted runners (for Level 3)
Implementation: Current SLSA Provenance Guide
"We use self-hosted runners for security"
Self-hosted runners don't automatically disqualify you, but they cap your SLSA level.
Questions to answer:
- Are builds isolated from each other?
- Can developers access runner infrastructure?
- Are runner images ephemeral or persistent?
Detailed guidance coming in Runner Configuration guide.
"We already generate SBOMs"
Good. SBOM is complementary, not redundant.
- SBOM: Lists dependencies (inventory)
- SLSA Provenance: Proves build integrity (audit trail)
Both address supply chain risk from different angles.
Detailed comparison coming in SLSA vs SBOM guide.
Implementation
Turn supply chain security from aspirational to operational.
What This Playbook Delivers
Clear implementation path from SLSA Level 1 to Level 3. Resolve SLSA vs SBOM confusion. Classify self-hosted runners correctly. Build verification workflows that actually work.
The Problem
SLSA adoption stalls on three documented pain points:
- SLSA vs SBOM confusion - Teams can't decide which to implement first or when to use each
- Self-hosted runner classification - Unclear which SLSA level self-hosted runners qualify for
- Verification complexity - Generating provenance is easy, verifying it is hard
This playbook addresses all three directly.
What SLSA Actually Does
SLSA provenance proves build integrity. It answers:
- What source code produced this artifact?
- What build process ran?
- What environment executed the build?
- Was the build isolated from tampering?
SLSA is not a bill of materials. It's a cryptographic proof of the build process.
Core value: Detect compromised builds. Prevent supply chain attacks like SolarWinds.
SLSA vs SBOM: The Confusion
The SLSA community acknowledges this confusion as a problem they "hope to address." We address it now.
Quick answer:
- SBOM = Inventory (what's inside the artifact)
- SLSA Provenance = Proof (how the artifact was built)
You need both. They complement each other.
Full clarification coming in subsequent playbook sections.
Playbook Structure
This playbook is organized into focused sections covering the complete SLSA implementation journey:
Foundation & Conceptual Clarity
Start here to understand SLSA fundamentals:
- SLSA vs SBOM - When to use each, how they complement
- SLSA Levels Explained - Detailed requirements for Levels 1-4
- Current Implementation - GitHub Actions workflow patterns (available now)
Decision Trees & Classification
Determine your target SLSA level:
- Level Classification - Decision trees for GitHub-hosted and self-hosted runners
- Runner Configuration - SLSA implications for different runner types
Verification & Policy
Make SLSA provenance mandatory:
- Verification Workflows - Patterns for verifying provenance in CI/CD
- Policy Templates - Kyverno and OPA policies for enforcement
Incremental Adoption
Implement SLSA progressively:
- Adoption Roadmap - Phased approach from SLSA 1 to SLSA 3
Toolchain Integration
Language-specific implementation:
- Toolchain Guides - Go, Node.js, Python patterns
- GitHub Actions Patterns - Reusable workflow patterns
Playbook Content In Progress
Additional playbook sections are being developed. Start with the current implementation guide for immediate SLSA Level 3 provenance generation.
Quick Start: Choose Your Path
Path 1: I Need SLSA Level 3 Now
Use GitHub-hosted runners with slsa-github-generator:
See examples.md for detailed code examples.
Result: SLSA Level 3 provenance in one workflow change.
Learn more: Current SLSA Implementation
Path 2: I Have Self-Hosted Runners
Understand your SLSA level ceiling:
- Review runner isolation requirements
- Determine if self-hosted runners meet Level 2 isolation requirements
- Consider migration to GitHub-hosted runners for Level 3
Reality check: Most self-hosted runners max out at SLSA Level 1 or 2.
Detailed classification guidance coming in subsequent playbook sections.
Path 3: I Need to Understand SLSA First
Start with conceptual foundation:
- Review SLSA vs SBOM distinction (detailed guide coming soon)
- Understand SLSA level requirements (detailed guide coming soon)
- Read the current implementation guide for practical patterns
- Plan your incremental adoption (roadmap guide coming soon)
SLSA Levels: Quick Reference
| Level | Build Script | Source Provenance | Build Isolation | Provenance Signing | |-------|--------------|-------------------|-----------------|-------------------| | 0 | None | None | None | None | | 1 | Manual | Recorded | None | Manual | | 2 | Automated | Versioned | None | Service-generated | | 3 | Automated | Versioned | Isolated | Non-falsifiable | | 4 | Automated | Versioned | Hermetic | Non-falsifiable + 2-party review |
Critical distinction: Level 3 requires isolated build environments. This is where self-hosted runners struggle.
Full details coming in SLSA Levels guide.
Common Scenarios
"We want OpenSSF Scorecard 10/10"
SLSA Level 3 provenance moves Signed-Releases from 8/10 to 10/10.
What you need:
- Generate
.intoto.jsonlattestation files - Upload to GitHub releases
- Use GitHub-hosted runners (for Level 3)
Implementation: Current SLSA Provenance Guide
"We use self-hosted runners for security"
Self-hosted runners don't automatically disqualify you, but they cap your SLSA level.
Questions to answer:
- Are builds isolated from each other?
- Can developers access runner infrastructure?
- Are runner images ephemeral or persistent?
Detailed guidance coming in Runner Configuration guide.
"We already generate SBOMs"
Good. SBOM is complementary, not redundant.
- SBOM: Lists dependencies (inventory)
- SLSA Provenance: Proves build integrity (audit trail)
Both address supply chain risk from different angles.
Detailed comparison coming in SLSA vs SBOM guide.
Integration with Existing Controls
SLSA provenance layers with other enforcement mechanisms:
See examples.md for detailed code examples.
Integration points:
- Branch Protection - Require provenance generation in required status checks
- Status Checks - Block PRs without provenance
- Policy-as-Code - Verify provenance before admission
- Audit Evidence - Include provenance in compliance reports
Why SLSA Matters
Supply chain attacks exploit build process compromise:
- SolarWinds (2020): Attackers injected malware during build
- Codecov (2021): Compromised Bash uploader script
- ua-parser-js (2021): Hijacked npm package with backdoor
SLSA provenance detects these attacks by proving:
- Artifact came from known source commit
- Build ran in isolated environment
- Build process matches expected workflow
The gap SLSA fills: It's not enough to sign artifacts. You must prove the build process itself is trustworthy.
Prerequisites
Before implementing SLSA:
- GitHub Actions (or equivalent CI/CD platform)
- Release artifact publishing (GitHub Releases, container registry)
- Basic understanding of cryptographic signing
- Decision on GitHub-hosted vs self-hosted runners
Implementation Timeline
Realistic estimates:
- SLSA Level 1: 1-2 days
- SLSA Level 2: 1 week (automated provenance generation)
- SLSA Level 3: 2-3 weeks (isolated builds, verification workflows)
Complexity drivers: Verification workflows, policy enforcement, self-hosted runner migration.
Phased approach guide coming soon.
Tools You'll Need
Provenance Generation
- slsa-github-generator - GitHub Actions reusable workflows
- slsa-framework/provenance-action - Alternative GitHub Action
Verification
- slsa-verifier - CLI tool for provenance verification
- cosign - Container image signing and verification
Policy Enforcement
- Kyverno - Kubernetes admission control
- OPA Gatekeeper - Alternative policy engine
Next Steps
- Start implementing: Use the current SLSA provenance guide for immediate Level 3 provenance
- Understand SLSA vs SBOM: Detailed comparison guide coming soon
- Learn SLSA levels: Requirements guide coming soon
- Classify your setup: Runner configuration and level classification guides coming soon
- Plan adoption: Incremental adoption roadmap guide coming soon
Related Content
- Current SLSA Implementation - Technical workflow details
- SBOM Generation - Complementary control
- OpenSSF Scorecard - SLSA impact on scores
- Branch Protection - Require provenance in status checks
- Policy-as-Code - Verify provenance at runtime
SLSA provenance proves build integrity. Start with clarity, implement incrementally, verify everywhere.
The Problem
SLSA adoption stalls on three documented pain points:
- SLSA vs SBOM confusion - Teams can't decide which to implement first or when to use each
- Self-hosted runner classification - Unclear which SLSA level self-hosted runners qualify for
- Verification complexity - Generating provenance is easy, verifying it is hard
This playbook addresses all three directly.
What SLSA Actually Does
SLSA provenance proves build integrity. It answers:
- What source code produced this artifact?
- What build process ran?
- What environment executed the build?
- Was the build isolated from tampering?
SLSA is not a bill of materials. It's a cryptographic proof of the build process.
Core value: Detect compromised builds. Prevent supply chain attacks like SolarWinds.
SLSA vs SBOM: The Confusion
The SLSA community acknowledges this confusion as a problem they "hope to address." We address it now.
Quick answer:
- SBOM = Inventory (what's inside the artifact)
- SLSA Provenance = Proof (how the artifact was built)
You need both. They complement each other.
Full clarification coming in subsequent playbook sections.
Playbook Structure
This playbook is organized into focused sections covering the complete SLSA implementation journey:
Foundation & Conceptual Clarity
Start here to understand SLSA fundamentals:
- SLSA vs SBOM - When to use each, how they complement
- SLSA Levels Explained - Detailed requirements for Levels 1-4
- Current Implementation - GitHub Actions workflow patterns (available now)
Decision Trees & Classification
Determine your target SLSA level:
- Level Classification - Decision trees for GitHub-hosted and self-hosted runners
- Runner Configuration - SLSA implications for different runner types
Verification & Policy
Make SLSA provenance mandatory:
- Verification Workflows - Patterns for verifying provenance in CI/CD
- Policy Templates - Kyverno and OPA policies for enforcement
Incremental Adoption
Implement SLSA progressively:
- Adoption Roadmap - Phased approach from SLSA 1 to SLSA 3
Toolchain Integration
Language-specific implementation:
- Toolchain Guides - Go, Node.js, Python patterns
- GitHub Actions Patterns - Reusable workflow patterns
Playbook Content In Progress
Additional playbook sections are being developed. Start with the current implementation guide for immediate SLSA Level 3 provenance generation.
Quick Start: Choose Your Path
Path 1: I Need SLSA Level 3 Now
Use GitHub-hosted runners with slsa-github-generator:
See examples.md for detailed code examples.
Result: SLSA Level 3 provenance in one workflow change.
Learn more: Current SLSA Implementation
Path 2: I Have Self-Hosted Runners
Understand your SLSA level ceiling:
- Review runner isolation requirements
- Determine if self-hosted runners meet Level 2 isolation requirements
- Consider migration to GitHub-hosted runners for Level 3
Reality check: Most self-hosted runners max out at SLSA Level 1 or 2.
Detailed classification guidance coming in subsequent playbook sections.
Path 3: I Need to Understand SLSA First
Start with conceptual foundation:
- Review SLSA vs SBOM distinction (detailed guide coming soon)
- Understand SLSA level requirements (detailed guide coming soon)
- Read the current implementation guide for practical patterns
- Plan your incremental adoption (roadmap guide coming soon)
SLSA Levels: Quick Reference
| Level | Build Script | Source Provenance | Build Isolation | Provenance Signing | |-------|--------------|-------------------|-----------------|-------------------| | 0 | None | None | None | None | | 1 | Manual | Recorded | None | Manual | | 2 | Automated | Versioned | None | Service-generated | | 3 | Automated | Versioned | Isolated | Non-falsifiable | | 4 | Automated | Versioned | Hermetic | Non-falsifiable + 2-party review |
Critical distinction: Level 3 requires isolated build environments. This is where self-hosted runners struggle.
Full details coming in SLSA Levels guide.
Common Scenarios
"We want OpenSSF Scorecard 10/10"
SLSA Level 3 provenance moves Signed-Releases from 8/10 to 10/10.
What you need:
- Generate
.intoto.jsonlattestation files - Upload to GitHub releases
- Use GitHub-hosted runners (for Level 3)
Implementation: Current SLSA Provenance Guide
"We use self-hosted runners for security"
Self-hosted runners don't automatically disqualify you, but they cap your SLSA level.
Questions to answer:
- Are builds isolated from each other?
- Can developers access runner infrastructure?
- Are runner images ephemeral or persistent?
Detailed guidance coming in Runner Configuration guide.
"We already generate SBOMs"
Good. SBOM is complementary, not redundant.
- SBOM: Lists dependencies (inventory)
- SLSA Provenance: Proves build integrity (audit trail)
Both address supply chain risk from different angles.
Detailed comparison coming in SLSA vs SBOM guide.
Integration with Existing Controls
SLSA provenance layers with other enforcement mechanisms:
See examples.md for detailed code examples.
Integration points:
- Branch Protection - Require provenance generation in required status checks
- Status Checks - Block PRs without provenance
- Policy-as-Code - Verify provenance before admission
- Audit Evidence - Include provenance in compliance reports
Why SLSA Matters
Supply chain attacks exploit build process compromise:
- SolarWinds (2020): Attackers injected malware during build
- Codecov (2021): Compromised Bash uploader script
- ua-parser-js (2021): Hijacked npm package with backdoor
SLSA provenance detects these attacks by proving:
- Artifact came from known source commit
- Build ran in isolated environment
- Build process matches expected workflow
The gap SLSA fills: It's not enough to sign artifacts. You must prove the build process itself is trustworthy.
Prerequisites
Before implementing SLSA:
- GitHub Actions (or equivalent CI/CD platform)
- Release artifact publishing (GitHub Releases, container registry)
- Basic understanding of cryptographic signing
- Decision on GitHub-hosted vs self-hosted runners
Implementation Timeline
Realistic estimates:
- SLSA Level 1: 1-2 days
- SLSA Level 2: 1 week (automated provenance generation)
- SLSA Level 3: 2-3 weeks (isolated builds, verification workflows)
Complexity drivers: Verification workflows, policy enforcement, self-hosted runner migration.
Phased approach guide coming soon.
Tools You'll Need
Provenance Generation
- slsa-github-generator - GitHub Actions reusable workflows
- slsa-framework/provenance-action - Alternative GitHub Action
Verification
- slsa-verifier - CLI tool for provenance verification
- cosign - Container image signing and verification
Policy Enforcement
- Kyverno - Kubernetes admission control
- OPA Gatekeeper - Alternative policy engine
Next Steps
- Start implementing: Use the current SLSA provenance guide for immediate Level 3 provenance
- Understand SLSA vs SBOM: Detailed comparison guide coming soon
- Learn SLSA levels: Requirements guide coming soon
- Classify your setup: Runner configuration and level classification guides coming soon
- Plan adoption: Incremental adoption roadmap guide coming soon
Related Content
- Current SLSA Implementation - Technical workflow details
- SBOM Generation - Complementary control
- OpenSSF Scorecard - SLSA impact on scores
- Branch Protection - Require provenance in status checks
- Policy-as-Code - Verify provenance at runtime
SLSA provenance proves build integrity. Start with clarity, implement incrementally, verify everywhere.
Comparison
The SLSA community acknowledges this confusion as a problem they "hope to address." We address it now.
Quick answer:
- SBOM = Inventory (what's inside the artifact)
- SLSA Provenance = Proof (how the artifact was built)
You need both. They complement each other.
Full clarification coming in subsequent playbook sections.
Examples
See examples.md for code examples.
Full Reference
See reference.md for complete documentation.
Related Patterns
- Current SLSA Implementation
- SBOM Generation
- OpenSSF Scorecard
- Branch Protection
- Policy-as-Code
References
- Source Documentation
- AEL Enforce
Related Skills
adaptive-enforcement-lab/workload-identity-federation-implementation
documentation
VerifiedTrustedCommunity
Workload Identity Federation implementation guide. GKE setup, IAM bindings, ServiceAccount configuration, migration from service account keys, and troubleshooting patterns.
SKILL.mdUpdated Mar 27, 2026
adaptive-enforcement-lab/workflow-trigger-security
development
VerifiedTrustedCommunity
Secure GitHub Actions trigger patterns for pull requests, forks, and reusable workflows. Preventing privilege escalation and code injection through trigger misconfiguration.
SKILL.mdUpdated Mar 27, 2026
adaptive-enforcement-lab/third-party-action-risk-assessment
development
VerifiedTrustedCommunity
Structured framework for evaluating GitHub Actions security before adoption. Trust tiers, risk assessment checklist, and decision tree for action evaluation.
SKILL.mdUpdated Mar 27, 2026
adaptive-enforcement-lab/storing-credentials
testing
VerifiedTrustedCommunity
Securely store GitHub App credentials across different environments. GitHub Actions secrets, external CI, Kubernetes, and automated rotation patterns.
SKILL.mdUpdated Mar 27, 2026