Deploy defense-in-depth SDLC hardening across four phases: pre-commit hooks, CI/CD gates, runtime enforcement, and continuous audit evidence collection systems.
Implements defense-in-depth SDLC hardening across four phases: pre-commit hooks, CI/CD gates, runtime enforcement, and continuous audit evidence collection. Use this when you need a structured roadmap to deploy auditable security controls that prevent bad code from entering your system and prove compliance to auditors.
/plugin marketplace add adaptive-enforcement-lab/claude-skills/plugin install enforce@ael-skillsThis skill inherits all available tools. When active, it can use any tool Claude has access to.
examples.mdreference.mdscripts/example-1.shscripts/example-2.shscripts/example-3.shscripts/example-4.shThis implementation roadmap provides a structured approach to hardening your Software Development Lifecycle (SDLC) across four critical phases:
Each phase builds on the previous one, creating defense-in-depth through multiple enforcement layers.
Before starting Phase 1, ensure you have:
Start Small
Begin with a single repository or team. Validate controls work before scaling organization-wide. Use pilot repository as reference implementation for others.
Every control in this roadmap is actionable and verifiable. No vague policies. No wishful thinking.
Audit Foundation
These controls are what auditors will verify. Skip items at your own risk. Each control must be fully deployed and evidenced before claiming compliance.
This implementation roadmap provides a structured approach to hardening your Software Development Lifecycle (SDLC) across four critical phases:
Each phase builds on the previous one, creating defense-in-depth through multiple enforcement layers.
Establish local development controls and repository protection.
Phase Components:
Why This Phase Matters: If secrets enter git history, rotation doesn't help. If admins can bypass reviews, the policy is worthless. Foundation controls prevent bad code from ever entering the system.
Automate security and quality checks in CI/CD pipelines.
Phase Components:
Why This Phase Matters: Tests that fail, code with vulnerabilities, and builds without SBOMs never merge. CI becomes a gate, not a log. Supply chain security becomes automatic.
Control what runs in production, not just what gets committed.
Phase Components:
Why This Phase Matters: Pods without resource limits, images from untrusted registries, or missing security context cannot run. Policy is enforced before deployment, not after incidents.
Prove compliance through continuous evidence collection and validation.
Phase Components:
Why This Phase Matters: Auditors will ask "prove branch protection was enabled on 2025-01-01". Archived config proves it. Evidence collection must be automatic and tamper-proof.
| Phase | Timeline | Key Milestone | Validation Method |
|---|---|---|---|
| Phase 1: Foundation | Weeks 1-4 | Branch protection on all repos | Test admin bypass attempt |
| Phase 2: Automation | Weeks 5-8 | CI gates block failing tests | Merge attempt with failing test |
| Phase 3: Runtime | Weeks 9-12 | Kyverno enforces pod policies | Deploy pod without limits |
| Phase 4: Advanced | Month 4+ | OpenSSF Scorecard 10/10 | Automated evidence retrieval |
These are non-negotiable
- Branch protection on every release branch (main, production, release-*)
enforce_admins: true(no admin bypasses)- 100% signature coverage on all repositories
- SLSA provenance on every release
- OpenSSF Scorecard 10/10 for critical repositories
- Monthly evidence collection with tamper-proof storage
- Audit simulation before real auditors arrive
Each phase includes validation steps that prove controls are working:
Foundation Phase:
# Test pre-commit hook blocks secrets
echo "AKIAIOSFODNN7EXAMPLE" > .env && git add .env && git commit -m "test"
# Expected: Commit blocked by TruffleHog
# Test admin enforcement
gh api repos/org/repo/branches/main/protection | jq '.enforce_admins.enabled'
# Expected: true
Automation Phase:
# Test CI blocks failing tests
echo "func TestFail(t *testing.T) { t.Fatal() }" >> main_test.go
git push origin feature-branch
# Expected: Merge blocked by CI failure
# Verify SBOM generation
gsutil ls gs://audit-evidence/sbom/$(date +%Y-%m-%d)/
# Expected: SBOM files for today's builds
Runtime Phase:
# Test pod without resource limits is rejected
kubectl apply -f pod-no-limits.yaml
# Expected: Admission webhook denies request
# Test untrusted registry is blocked
kubectl apply -f pod-dockerhub.yaml
# Expected: Image source validation fails
Advanced Phase:
# Verify evidence archive exists
gsutil ls gs://audit-evidence/2025-01/branch-protection.json
# Expected: File exists with branch protection config
# Check OpenSSF Scorecard score
docker run gcr.io/openssf/scorecard-action:stable --repo=github.com/org/repo
# Expected: Score ≥ 8.0/10
Before starting Phase 1, ensure you have:
Start Small
Begin with a single repository or team. Validate controls work before scaling organization-wide. Use pilot repository as reference implementation for others.
Don't assume a control works because it's deployed. Every control must be tested with an attack scenario.
Solution: Use validation commands from each phase to prove controls block violations.
Setting enforce_admins: false makes all other controls optional.
Solution: Keep admin enforcement enabled. If emergency bypass is needed, document it, use it, then re-enable immediately.
Automated evidence collection means nothing if the data is corrupt or incomplete.
Solution: Monthly spot-check of evidence archives. Verify JSON is valid, timestamps are correct, and files are complete.
Your score can regress if controls are disabled or practices slip.
Solution: Run Scorecard monthly. Alert on score drops > 0.5 points. Investigate immediately.
Foundation laid. Controls enforced. Evidence collected. Auditors get irrefutable proof. SDLC hardening is not a checklist item. It's operational reality.
This implementation roadmap provides a structured approach to hardening your Software Development Lifecycle (SDLC) across four critical phases:
Each phase builds on the previous one, creating defense-in-depth through multiple enforcement layers.
Establish local development controls and repository protection.
Phase Components:
Why This Phase Matters: If secrets enter git history, rotation doesn't help. If admins can bypass reviews, the policy is worthless. Foundation controls prevent bad code from ever entering the system.
Automate security and quality checks in CI/CD pipelines.
Phase Components:
Why This Phase Matters: Tests that fail, code with vulnerabilities, and builds without SBOMs never merge. CI becomes a gate, not a log. Supply chain security becomes automatic.
Control what runs in production, not just what gets committed.
Phase Components:
Why This Phase Matters: Pods without resource limits, images from untrusted registries, or missing security context cannot run. Policy is enforced before deployment, not after incidents.
Prove compliance through continuous evidence collection and validation.
Phase Components:
Why This Phase Matters: Auditors will ask "prove branch protection was enabled on 2025-01-01". Archived config proves it. Evidence collection must be automatic and tamper-proof.
| Phase | Timeline | Key Milestone | Validation Method |
|---|---|---|---|
| Phase 1: Foundation | Weeks 1-4 | Branch protection on all repos | Test admin bypass attempt |
| Phase 2: Automation | Weeks 5-8 | CI gates block failing tests | Merge attempt with failing test |
| Phase 3: Runtime | Weeks 9-12 | Kyverno enforces pod policies | Deploy pod without limits |
| Phase 4: Advanced | Month 4+ | OpenSSF Scorecard 10/10 | Automated evidence retrieval |
These are non-negotiable
- Branch protection on every release branch (main, production, release-*)
enforce_admins: true(no admin bypasses)- 100% signature coverage on all repositories
- SLSA provenance on every release
- OpenSSF Scorecard 10/10 for critical repositories
- Monthly evidence collection with tamper-proof storage
- Audit simulation before real auditors arrive
Each phase includes validation steps that prove controls are working:
Foundation Phase:
# Test pre-commit hook blocks secrets
echo "AKIAIOSFODNN7EXAMPLE" > .env && git add .env && git commit -m "test"
# Expected: Commit blocked by TruffleHog
# Test admin enforcement
gh api repos/org/repo/branches/main/protection | jq '.enforce_admins.enabled'
# Expected: true
Automation Phase:
# Test CI blocks failing tests
echo "func TestFail(t *testing.T) { t.Fatal() }" >> main_test.go
git push origin feature-branch
# Expected: Merge blocked by CI failure
# Verify SBOM generation
gsutil ls gs://audit-evidence/sbom/$(date +%Y-%m-%d)/
# Expected: SBOM files for today's builds
Runtime Phase:
# Test pod without resource limits is rejected
kubectl apply -f pod-no-limits.yaml
# Expected: Admission webhook denies request
# Test untrusted registry is blocked
kubectl apply -f pod-dockerhub.yaml
# Expected: Image source validation fails
Advanced Phase:
# Verify evidence archive exists
gsutil ls gs://audit-evidence/2025-01/branch-protection.json
# Expected: File exists with branch protection config
# Check OpenSSF Scorecard score
docker run gcr.io/openssf/scorecard-action:stable --repo=github.com/org/repo
# Expected: Score ≥ 8.0/10
Before starting Phase 1, ensure you have:
Start Small
Begin with a single repository or team. Validate controls work before scaling organization-wide. Use pilot repository as reference implementation for others.
Don't assume a control works because it's deployed. Every control must be tested with an attack scenario.
Solution: Use validation commands from each phase to prove controls block violations.
Setting enforce_admins: false makes all other controls optional.
Solution: Keep admin enforcement enabled. If emergency bypass is needed, document it, use it, then re-enable immediately.
Automated evidence collection means nothing if the data is corrupt or incomplete.
Solution: Monthly spot-check of evidence archives. Verify JSON is valid, timestamps are correct, and files are complete.
Your score can regress if controls are disabled or practices slip.
Solution: Run Scorecard monthly. Alert on score drops > 0.5 points. Investigate immediately.
Foundation laid. Controls enforced. Evidence collected. Auditors get irrefutable proof. SDLC hardening is not a checklist item. It's operational reality.
Don't assume a control works because it's deployed. Every control must be tested with an attack scenario.
Solution: Use validation commands from each phase to prove controls block violations.
Setting enforce_admins: false makes all other controls optional.
Solution: Keep admin enforcement enabled. If emergency bypass is needed, document it, use it, then re-enable immediately.
Automated evidence collection means nothing if the data is corrupt or incomplete.
Solution: Monthly spot-check of evidence archives. Verify JSON is valid, timestamps are correct, and files are complete.
Your score can regress if controls are disabled or practices slip.
Solution: Run Scorecard monthly. Alert on score drops > 0.5 points. Investigate immediately.
See examples.md for code examples.
See reference.md for complete documentation.
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.
Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.
Create beautiful visual art in .png and .pdf documents using design philosophy. You should use this skill when the user asks to create a poster, piece of art, design, or other static piece. Create original visual designs, never copying existing artists' work to avoid copyright violations.