Compliance Framework: Automatizzare la Conformità
La compliance nel contesto DevSecOps non e un esercizio burocratico, ma un insieme di controlli tecnici che possono essere automatizzati e verificati continuamente. Framework come GDPR, SOC2, ISO27001 e PCI-DSS definiscono requisiti di sicurezza che si traducono direttamente in controlli DevSecOps implementabili come codice.
L'approccio compliance-as-code trasforma i requisiti di conformità in policy automatiche, evidence collection continua e audit trail verificabili. Questo riduce lo sforzo per gli audit, elimina i gap temporali tra un audit e l'altro e fornisce conformità dimostrabile in tempo reale.
Cosa Imparerai
- Mapping dei requisiti GDPR, SOC2, ISO27001 ai controlli DevSecOps
- Compliance-as-Code: automatizzare la raccolta di evidenze
- Audit logging e evidence collection
- Strumenti per compliance automation (Vanta, Drata, CloudCompli)
- Continuous compliance monitoring
- Preparazione per gli audit
Mapping Compliance ai Controlli DevSecOps
Ogni framework di compliance definisce requisiti che possono essere soddisfatti attraverso i controlli DevSecOps che abbiamo esplorato in questa serie:
Mapping DevSecOps a Framework di Compliance
| Controllo DevSecOps | 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) e lo standard di compliance più richiesto per le aziende SaaS. Si basa su cinque Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality e Privacy.
Per DevSecOps, il criterio più rilevante e Security (Common Criteria), che richiede controlli per proteggere i sistemi da accessi non autorizzati:
- CC6 - Logical Access: RBAC, MFA, least privilege, access review periodiche
- CC7 - System Operations: monitoring, vulnerability management, incident response
- CC8 - Change Management: code review, approval workflows, testing
ISO27001: Information Security Management
ISO27001 e lo standard internazionale per la gestione della sicurezza delle informazioni. Definisce un ISMS (Information Security Management System) con 93 controlli nell'Annex A, molti dei quali si mappano direttamente a pratiche DevSecOps.
Compliance-as-Code: Implementazione
Il concetto di compliance-as-code si implementa su tre livelli:
1. Policy Enforcement Automatico
Le policy di compliance vengono implementate come codice (OPA/Rego, Kyverno) e applicate automaticamente nella pipeline e nell'infrastruttura.
2. Evidence Collection Continua
Le evidenze di conformità vengono raccolte automaticamente da ogni pipeline execution, deploy e operazione di sicurezza. Questo elimina la raccolta manuale pre-audit.
# .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-