Get your daily dose of tech!

We Shape Your Knowledge

Codice in lavatrice!

Kirey Group

  

    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

    A cura di Enrico Frescura, Responsabile Area Data Security presso Kirey Group

    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.

    infografica SAST process-1

     

    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.

    New call-to-action

    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

    New call-to-action

    Post correlati:

    Le banche alle prese con nuovi schemi di pagamento...

    Prevenire il Money Muling è un problema storico per gli istituti finanziari per questione di danno d...

    Money Mule: come formare gli utenti perché non sia...

    Per contrastare il Money Muling occorre formare gli utilizzatori di servizi online sull’esistenza di...

    Le sfide della Cybersecurity per i fondi pensione ...

    L’oculata gestione degli attacchi cyber è un driver imprescindibile per il sano sviluppo di un’azien...