Il processo di SAST deve sempre essere inserito nel contesto del S-SDLC per la corretta verifica della bontà del codice in termini di sicurezza
Per ogni azienda verificare in termini di sicurezza la bontà del codice sviluppato è difficile e, soprattutto, oneroso. Per rispondere a questa esigenza, i principali vendor offrono soluzioni tecnologiche valide e con peculiarità diverse tra loro.
Il valore degli strumenti viene valutato dal mercato rispetto a diverse caratteristiche, come ad esempio:
- copertura linguaggi;
- scansione del compilato;
- minor numero di falsi positivi anche attraverso l’applicazione di AI;
- integrabilità con gli strumenti di CI/CD;
- integrazione con motori di Software Composition Analysis (SCA);
- reportistica secondo i principali benchmark e/o enti certificatori;
- differenziazione dell’offering rispetto a modelli a consumo o a licenza perpetua.
L’aspetto tecnologico, però, non è il solo elemento da tenere in considerazione; altrettanto importante è il processo. Serve avere l’auto più performante se non può essere utilizzata e valorizzata da un team capace di meccanici e piloti?
Anche in questo ambito, non si parla solo di capacità delle persone che sviluppano il codice o di quelle che ne verificano le vulnerabilità riscontrate, ma della sinergia tra strumenti e utilizzatori.
Il classico processo di SAST (Static Application Security Testing), deve sempre essere declinato e inserito nel contesto del S-SDLC (Secure - Software Development Life Cycle) in essere nell’organizzazione per ottenere i giusti risultati. Qualunque sia il modello di sviluppo adottato, waterfall o agile, o in presenza di un contesto DevOps o legacy, è fondamentale coinvolgere lo strumento nella fase più adeguata del ciclo di vita del software.
Secure - Software Development Life Cycle: un esempio
Prendiamo come esempio un modello di adozione in un contesto a reiterazione veloce tipica dei modelli agile.
Il modello rappresentato è caratterizzato da una forte mediazione della prioritizzazione e della conseguente pianificazione di remediation da parte del responsabile di progetto, così da evitare il classico “gate” bloccante e lasciare la responsabilità del rischio residuo al business. Il team di sicurezza è coinvolto per assicurare la consistenza dei risultati ottenuti dalla tecnologia, al fine di evitare la gestione a valle di falsi positivi o di vulnerabilità caratterizzate da una valutazione di rischio errato. Ogni processo che si rispetti deve essere misurabile: a tal proposito devono essere implementati dei KPI dedicati, necessari a valutare l’andamento delle vulnerabilità risolte e reintrodotte.
Infine, ma non meno importante, è il tema della formazione: alcune organizzazioni impongono una formazione in aula ai team coinvolti nello sviluppo. A volte, però, questa formazione risulta inefficace, perché effettuata su materiale di letteratura ed esempi generici. Per questo, altre organizzazioni trovano invece più efficace dare diretto accesso agli strumenti di SAST al personale coinvolto, così da sfruttare a pieno le informazioni a corredo della vulnerabilità e dar modo di “imparare sul campo”.
L' approccio di Kirey Group
Kirey Group mette a disposizione delle aziende la propria esperienza decennale in ambito tecnologico e di processo, maturata sia durante progetti rivolti a clienti sia durante progetti interni.
Il team di DevSecOps ha le capacità e le esperienze cross-ambito per proporsi con attività di advisory, di system integration e di consulenza di processo. Un tipico progetto sul tema SAST può coinvolgere figure champions con skills di security e skills di sviluppo.
Le principali fasi sono:
- Assessment sul processo S-SDLC attuale
- Individuazione della tecnologia più adatta rispetto i requisiti cliente
- Demo/POC
- Definizione del progetto, degli stakeholder e dei milestones
- Implementazione della tecnologia
- Revisione del processo esistente con la definizione di nuove procedure operative
- Tutoring
-1.png "002-Kirey Group - una riga - (color)-1")
