Compliance Framework: Automating Conformity
Compliance in the DevSecOps context is not a bureaucratic exercise, but a set of technical controls that can be automated and continuously verified. Frameworks like GDPR, SOC2, ISO27001, and PCI-DSS define security requirements that translate directly into implementable DevSecOps controls as code.
The compliance-as-code approach transforms compliance requirements into automated policies, continuous evidence collection, and verifiable audit trails. This reduces audit effort, eliminates gaps between audits, and provides demonstrable real-time compliance.
What You'll Learn
- Mapping GDPR, SOC2, ISO27001 requirements to DevSecOps controls
- Compliance-as-Code: automating evidence collection
- Audit logging and evidence collection
- Compliance automation tools (Vanta, Drata, CloudCompli)
- Continuous compliance monitoring
- Audit preparation
Mapping Compliance to DevSecOps Controls
Each compliance framework defines requirements that can be satisfied through the DevSecOps controls we've explored in this series:
DevSecOps to Compliance Framework Mapping
| DevSecOps Control | SOC2 | ISO27001 | PCI-DSS |
|---|---|---|---|
| SAST/DAST | CC7.1, CC8.1 | A.14.2.1 | 6.5, 6.6 |
| SCA | CC7.1 | A.14.2.1 | 6.2 |
| Secret Management | CC6.1 | A.10.1.1 | 3.4, 8.2 |
| Access Control | CC6.1, CC6.2 | A.9.1-A.9.4 | 7.1, 7.2 |
| Audit Logging | CC7.2 | A.12.4 | 10.1-10.7 |
| Incident Response | CC7.3-CC7.5 | A.16 | 12.10 |
| Container Security | CC7.1 | A.14.2.5 | 6.3, 6.5 |
| Encryption | CC6.1 | A.10.1 | 3.4, 4.1 |
SOC2: Trust Service Criteria
SOC2 (Service Organization Control Type 2) is the most requested compliance standard for SaaS companies. It's based on five Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy.
For DevSecOps, the most relevant criterion is Security (Common Criteria), which requires controls to protect systems from unauthorized access:
- CC6 - Logical Access: RBAC, MFA, least privilege, periodic access reviews
- CC7 - System Operations: monitoring, vulnerability management, incident response
- CC8 - Change Management: code review, approval workflows, testing
ISO27001: Information Security Management
ISO27001 is the international standard for information security management. It defines an ISMS (Information Security Management System) with 93 controls in Annex A, many of which map directly to DevSecOps practices.
Compliance-as-Code: Implementation
The compliance-as-code concept is implemented at three levels:
1. Automatic Policy Enforcement
Compliance policies are implemented as code (OPA/Rego, Kyverno) and automatically applied in the pipeline and infrastructure.
2. Continuous Evidence Collection
Compliance evidence is automatically collected from every pipeline execution, deploy, and security operation. This eliminates manual pre-audit collection.
# .github/workflows/compliance-evidence.yml
name: Compliance Evidence Collection
on:
push:
branches: [main]
jobs:
collect-evidence:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: SAST Evidence (CC7.1)
run: |
semgrep scan --config auto --sarif > evidence/sast-results.sarif
echo "SAST scan completed at $(date -u)" >> evidence/audit-log.txt
- name: SCA Evidence (CC7.1)
run: |
npm audit --json > evidence/sca-results.json
echo "SCA scan completed at $(date -u)" >> evidence/audit-log.txt
- name: Container Scan Evidence (CC7.1)
run: |
trivy image --format json myapp:latest > evidence/container-scan.json
echo "Container scan completed at $(date -u)" >> evidence/audit-log.txt
- name: SBOM Generation (Supply Chain)
run: |
syft myapp:latest -o cyclonedx-json > evidence/sbom.json
echo "SBOM generated at $(date -u)" >> evidence/audit-log.txt
- name: Store Evidence
uses: actions/upload-artifact@v4
with:
name: compliance-evidence-