tomevault-io SDLC Hardening Implementation Roadmap
When to Use This Skill
This implementation roadmap provides a structured approach to hardening your Software Development Lifecycle (SDLC) across four critical phases:
- Phase 1: Foundation - Local enforcement and branch protection
- Phase 2: Automation - CI/CD gates and policy automation
- Phase 3: Runtime - Production policy enforcement
- Phase 4: Advanced - Audit evidence and compliance validation
Each phase builds on the previous one, creating defense-in-depth through multiple enforcement layers.
Prerequisites
Before starting Phase 1, ensure you have:
- Access to GitHub organization settings
- Cloud storage bucket for evidence (GCS, S3, Azure Blob)
- GitHub App or token with appropriate permissions
- Kubernetes cluster for runtime policies (Phase 3)
- Team buy-in on enforcement approach
Start Small
Begin with a single repository or team. Validate controls work before scaling organization-wide. Use pilot repository as reference implementation for others.
Implementation
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.
Overview
This implementation roadmap provides a structured approach to hardening your Software Development Lifecycle (SDLC) across four critical phases:
- Phase 1: Foundation - Local enforcement and branch protection
- Phase 2: Automation - CI/CD gates and policy automation
- Phase 3: Runtime - Production policy enforcement
- Phase 4: Advanced - Audit evidence and compliance validation
Each phase builds on the previous one, creating defense-in-depth through multiple enforcement layers.
Roadmap Phases
Phase 1: Foundation (Weeks 1-4)
Establish local development controls and repository protection.
Phase Components:
- Pre-commit Hooks - Secrets detection, linting, policy enforcement
- Branch Protection - Required reviews, status checks, admin enforcement
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.
View Phase 1 Overview →
Phase 2: Automation (Weeks 5-8)
Automate security and quality checks in CI/CD pipelines.
Phase Components:
- CI/CD Gates - Required checks, SBOM generation, vulnerability scanning, SLSA provenance
- Evidence Collection - Automated archival and metrics tracking
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.
View Phase 2 Overview →
Phase 3: Runtime (Weeks 9-12)
Control what runs in production, not just what gets committed.
Phase Components:
- Policy Enforcement - Core Kyverno policies, resource limits, image verification
- Advanced Policies - Namespace quotas, pod security, network policies
- Rollout Strategy - Audit-first deployment and metrics
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.
View Phase 3 Overview →
Phase 4: Advanced (Month 4+)
Prove compliance through continuous evidence collection and validation.
Phase Components:
- Audit Evidence - Branch protection, PR reviews, signatures, SBOMs
- Compliance Validation - OpenSSF Scorecard, SLSA verification, license checks
- Audit Simulation - Mock audit, gap analysis, remediation
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.
View Phase 4 Overview →
Implementation Timeline
| 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 |
Critical Success Factors
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
Validation Strategy
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
Prerequisites
Before starting Phase 1, ensure you have:
- Access to GitHub organization settings
- Cloud storage bucket for evidence (GCS, S3, Azure Blob)
- GitHub App or token with appropriate permissions
- Kubernetes cluster for runtime policies (Phase 3)
- Team buy-in on enforcement approach
Start Small
Begin with a single repository or team. Validate controls work before scaling organization-wide. Use pilot repository as reference implementation for others.
Common Pitfalls
Pitfall 1: Deploying controls without validation
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.
Pitfall 2: Admin bypass enabled "just in case"
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.
Pitfall 3: Evidence collection runs but isn't verified
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.
Pitfall 4: OpenSSF Scorecard score drops unnoticed
Your score can regress if controls are disabled or practices slip.
Solution: Run Scorecard monthly. Alert on score drops > 0.5 points. Investigate immediately.
Next Steps
- Review Phase 1: Foundation and identify repositories for pilot deployment
- Prepare cloud storage bucket for evidence collection
- Document current state (how many repos have branch protection? How many require reviews?)
- Schedule implementation kickoff with engineering teams
- Execute Phase 1 controls on pilot repository
- Validate controls work before scaling organization-wide
Related Patterns
- Execution Guide - Progress tracking and rollback planning
- Branch Protection Enforcement - GitHub configuration
- Pre-commit Security Gates - Local enforcement
- SLSA Provenance - Build attestations
- Audit Evidence Collection - Long-term evidence storage
- Policy-as-Code with Kyverno - Runtime enforcement
Foundation laid. Controls enforced. Evidence collected. Auditors get irrefutable proof. SDLC hardening is not a checklist item. It's operational reality.
Overview
This implementation roadmap provides a structured approach to hardening your Software Development Lifecycle (SDLC) across four critical phases:
- Phase 1: Foundation - Local enforcement and branch protection
- Phase 2: Automation - CI/CD gates and policy automation
- Phase 3: Runtime - Production policy enforcement
- Phase 4: Advanced - Audit evidence and compliance validation
Each phase builds on the previous one, creating defense-in-depth through multiple enforcement layers.
Roadmap Phases
Phase 1: Foundation (Weeks 1-4)
Establish local development controls and repository protection.
Phase Components:
- Pre-commit Hooks - Secrets detection, linting, policy enforcement
- Branch Protection - Required reviews, status checks, admin enforcement
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.
View Phase 1 Overview →
Phase 2: Automation (Weeks 5-8)
Automate security and quality checks in CI/CD pipelines.
Phase Components:
- CI/CD Gates - Required checks, SBOM generation, vulnerability scanning, SLSA provenance
- Evidence Collection - Automated archival and metrics tracking
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.
View Phase 2 Overview →
Phase 3: Runtime (Weeks 9-12)
Control what runs in production, not just what gets committed.
Phase Components:
- Policy Enforcement - Core Kyverno policies, resource limits, image verification
- Advanced Policies - Namespace quotas, pod security, network policies
- Rollout Strategy - Audit-first deployment and metrics
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.
View Phase 3 Overview →
Phase 4: Advanced (Month 4+)
Prove compliance through continuous evidence collection and validation.
Phase Components:
- Audit Evidence - Branch protection, PR reviews, signatures, SBOMs
- Compliance Validation - OpenSSF Scorecard, SLSA verification, license checks
- Audit Simulation - Mock audit, gap analysis, remediation
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.
View Phase 4 Overview →
Implementation Timeline
| 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 |
Critical Success Factors
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
Validation Strategy
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
Prerequisites
Before starting Phase 1, ensure you have:
- Access to GitHub organization settings
- Cloud storage bucket for evidence (GCS, S3, Azure Blob)
- GitHub App or token with appropriate permissions
- Kubernetes cluster for runtime policies (Phase 3)
- Team buy-in on enforcement approach
Start Small
Begin with a single repository or team. Validate controls work before scaling organization-wide. Use pilot repository as reference implementation for others.
Common Pitfalls
Pitfall 1: Deploying controls without validation
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.
Pitfall 2: Admin bypass enabled "just in case"
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.
Pitfall 3: Evidence collection runs but isn't verified
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.
Pitfall 4: OpenSSF Scorecard score drops unnoticed
Your score can regress if controls are disabled or practices slip.
Solution: Run Scorecard monthly. Alert on score drops > 0.5 points. Investigate immediately.
Next Steps
- Review Phase 1: Foundation and identify repositories for pilot deployment
- Prepare cloud storage bucket for evidence collection
- Document current state (how many repos have branch protection? How many require reviews?)
- Schedule implementation kickoff with engineering teams
- Execute Phase 1 controls on pilot repository
- Validate controls work before scaling organization-wide
Related Patterns
- Execution Guide - Progress tracking and rollback planning
- Branch Protection Enforcement - GitHub configuration
- Pre-commit Security Gates - Local enforcement
- SLSA Provenance - Build attestations
- Audit Evidence Collection - Long-term evidence storage
- Policy-as-Code with Kyverno - Runtime enforcement
Foundation laid. Controls enforced. Evidence collected. Auditors get irrefutable proof. SDLC hardening is not a checklist item. It's operational reality.
Anti-Patterns to Avoid
Pitfall 1: Deploying controls without validation
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.
Pitfall 2: Admin bypass enabled "just in case"
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.
Pitfall 3: Evidence collection runs but isn't verified
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.
Pitfall 4: OpenSSF Scorecard score drops unnoticed
Your score can regress if controls are disabled or practices slip.
Solution: Run Scorecard monthly. Alert on score drops > 0.5 points. Investigate immediately.
Examples
See examples.md for code examples.
Full Reference
See reference.md for complete documentation.
Related Patterns
- Execution Guide
- Branch Protection Enforcement
- Pre-commit Security Gates
- SLSA Provenance
- Audit Evidence Collection
- Policy-as-Code with Kyverno
References
Converted and distributed by TomeVault — claim your Tome and manage your conversions.