Linee guida OWASP DevSecOps

Le Linee guida OWASP DevSecOps spiegano come possiamo implementare una pipeline sicura, utilizzare le migliori pratiche e introdurre strumenti che possiamo usare in tal senso. Inoltre, il progetto cerca di aiutarci a promuovere la cultura della sicurezza shift-left nel nostro processo di sviluppo. Questo progetto aiuta qualsiasi azienda di ogni dimensione che abbia una pipeline di sviluppo o, in altre parole, una pipeline DevOps. Durante questo progetto cerchiamo di delineare una prospettiva di una pipeline DevOps sicura e poi di migliorarla in base ai nostri requisiti personalizzati.

L'obiettivo ideale è "rilevare i problemi di sicurezza (per progettazione o vulnerabilità dell'applicazione) il prima possibile."

Come è organizzata la linea guida

La linea guida è costruita attorno a tre pilastri:

• Persone — team, ruoli, cultura e formazione.
• Processo — attività di sicurezza intessute in ogni fase dell'SDLC: Design, Develop, Build, Test, Release, Deploy, Operate.
• Governance — conformità, policy as code, reporting, ASPM e governance dell'IA.

L'edizione attuale è aggiornata per il 2025/2026 e allineata a framework come NIST SSDF, OWASP SAMM, OWASP DSOMM e SLSA. Consulta il Sommario di seguito, oppure sfoglia la versione corrente.

Passi iniziali

DevSecOps consiste nell'inserire la sicurezza nel DevOps. Ma per stare al passo con il ritmo del CI/CD, la sicurezza deve essere iniettata precocemente nella scrittura e nel testing del software.

OWASP Proactive Controls elenca i 10 principali controlli di sicurezza che ogni sviluppatore deve implementare durante la codifica di qualsiasi applicazione. Considera questo insieme come punto di partenza quando devi progettare, scrivere o testare codice nel ciclo DevSecOps.

Puoi anche seguire l'OWASP Software Assurance Maturity Model (SAMM) per stabilire cosa considerare per i requisiti di sicurezza (e non solo) in base al tuo livello di maturità.

Cosa aggiungere in una pipeline

Inizialmente, consideriamo di implementare i seguenti passi in una pipeline di base:

• Scansione dei repository git per trovare potenziali fughe di credenziali.
• SCA (Software Composition Analysis)
• SAST (Static Application Security Test)
• IaC Scanning (scansione del codice Terraform, HelmChart per trovare misconfigurazioni)
• Sicurezza della supply-chain software (SBOM, firma degli artefatti e provenienza, sicurezza della pipeline CI/CD)
• IAST (Interactive Application Security Testing)
• Sicurezza delle API
• DAST (Dynamic Application Security Test)
• CNAPP (Cloud Native Application Protection)
• Scansione dell'infrastruttura
• Scansione continua da altri strumenti
• Verifica di conformità e policy as code
• Security gate (quality gate che bloccano build e release rischiose)
• Reporting centralizzato e ASPM (Application Security Posture Management)
• Sicurezza AI/LLM e governance dell'IA (mettere in sicurezza lo sviluppo assistito dall'IA e le funzionalità basate sull'IA)

Possiamo personalizzare i passi della nostra pipeline in base al nostro Software Development Life Cycle (SDLC) o all'architettura software e aggiungere automazione in modo progressivo se stiamo iniziando. Ad esempio, possiamo passare da SAST/DAST a una suite di test regolare con controlli di sicurezza integrati oppure aggiungere uno script di audit che verifica dipendenze vulnerabili note.

CI/CD è un vantaggio per SecOps, un punto di ingresso privilegiato per misure e controlli di sicurezza. Tuttavia, quando si usano strumenti CI/CD per fornire automazione, tieni presente che gli strumenti stessi spesso ampliano la tua superficie di attacco, quindi applica controlli di sicurezza al software di build, deployment e automazione.

---

Sommario