DevSecOps frazionato: analisi di sicurezza del tuo software

Il momento in cui serve questa pagina di solito è uno di tre. Un cliente più grande ti ha mandato un questionario di sicurezza. Una gara chiede di dimostrare come controlli il software che consegni. Oppure la NIS2 è arrivata fino a te lungo la filiera. In tutti e tre i casi non ti serve una consulenza che produce documenti: ti serve poter mostrare che i controlli esistono, girano a ogni build e bloccano.

La maggior parte delle aziende che sviluppano software non ha un ingegnere della sicurezza e non ne ha bisogno a tempo pieno. Ha bisogno di qualcuno che guardi il codice, le dipendenze e l’applicazione in esecuzione con gli strumenti giusti, dica cosa conta e lasci controlli che continuano a funzionare dopo. È quello che offro, qualche giorno al mese, in tre fasi.

Fase 1, analisi

Analizzo il software che hai già su tre livelli. Il codice sorgente con il SAST (SonarQube). L’applicazione in esecuzione con il DAST (OWASP ZAP), che la attacca dall’esterno come farebbe un attaccante. Ogni libreria e componente con una SBOM in formato CycloneDX tenuta in Dependency-Track (SCA). Un agente che ho costruito legge i tre risultati affiancati e io rivedo le sue conclusioni. Ricevi un report unico: un indice di rischio complessivo, i finding che contano, quelli che possono aspettare, e perché.

Fase 2, nella pipeline

Gli stessi controlli entrano nella tua CI/CD, GitLab CI, GitHub Actions o quello che usi, con soglie di blocco scritte nel repository e il motivo accanto a ognuna. Prima di fidarsene, ogni controllo viene fatto fallire apposta. Un controllo verde manda lo stesso segnale quando va tutto bene e quando è rotto: in un progetto un osservatore era agganciato a un nodo del DOM che non esisteva, non guardava niente e restava verde. L’unico modo per distinguere è provocare il fallimento.

Fase 3, affiancamento

Qualche giorno al mese: leggere i report con il tuo team, decidere cosa correggere prima, essere pronti quando esce una vulnerabilità critica. Con una SBOM aggiornata, «siamo esposti?» diventa una ricerca invece di un inventario fatto di corsa.

Da dove viene

Con Dfence ho gestito un servizio di vulnerability assessment continuo su circa 100 appliance presso i clienti. Da CTO di una software house B2B ho costruito lo stadio di pipeline GitLab che legge insieme SAST, DAST e SCA. Su un e-commerce di circa 2.400 prodotti ho aggiornato uno stack fermo da mesi un componente alla volta, con una suite automatica passata da 36 a 58 test e un rollback provato davvero.

Cosa non faccio

Niente SOC attivo 24 ore su 24, niente incident response forense, niente penetration test manuale. Gli scanner trovano classi note di debolezza: non sostituiscono un penetration test sui sistemi critici, e un falso negativo di uno strumento resta un falso negativo anche dopo l’agente.