Un sondaggio Gartner ha scoperto che un’elevata collaborazione tra sviluppatori e team di sicurezza migliora i risultati di sicurezza del 27%. Tuttavia, solo il 29% degli intervistati afferma che questi due gruppi sono fortemente d’accordo tra loro. Quando si tratta di pratica, risultati e consegna nel mondo reale, alcune piccole e medie organizzazioni considerano ancora DevOps, DevSecOps e “Shift Security Left” come concetti incerti. Per altri, queste metodologie fanno già parte del loro flusso di lavoro, offrendo vantaggi tangibili.
Quindi, cosa separa questi due gruppi? E perché alcune organizzazioni hanno difficoltà a semplificare le operazioni quotidiane quando adottano queste metodologie?
Un Approccio Vincente
Tutto si riduce a un solo fattore: il modello di adattamento.
Le procedure, gli strumenti e il cambiamento culturale che il team di un’organizzazione deve attraversare quando adotta queste metodologie o framework devono essere personalizzati. Non esiste un modello universale.
In SORINT.lab, ogni cliente riceve una proposta e un modello operativo su misura. Ogni valutazione è unica e porta a risultati specifici, perché non esistono soluzioni identiche per esigenze diverse. Certo, ci sono parametri comuni, ma un piano di adattamento finale, completo di percorso, tempistiche, strumenti e milestone fattibili, non può mai essere valido per tutti. Per quanto ne so, è impossibile — spiega Mohab Abugabal, Strategist presso SORINT.lab
Riunire professionisti della sicurezza, sviluppatori e team operativi in un flusso di lavoro coeso è allo stesso tempo semplice e incredibilmente complesso. Perché? A causa delle variabili, fattori che devono essere identificati durante la fase di valutazione prima di elaborare una roadmap “efficace”. Esempi di variabili chiave dal lato del cliente:
- Livelli di maturità dell’organizzazione e del team
- Complessità del progetto
- Fondamenti teorici
- Pratiche e strumenti attuali (se presenti)
- Sfide, obiettivi e scopi
- Alchimia del team, lacune di competenze e altro
E molto altro.
In SORINT.lab, la fase di valutazione non è completa finché tutti gli stakeholder chiave (ingegneri, sviluppatori, specialisti della sicurezza e project manager) non comprendono appieno cosa è necessario per creare una roadmap efficace e orientata ai risultati. Che si tratti di ottimizzare una metodologia esistente o di implementare un framework di lavoro completamente nuovo, in ogni caso, in SORINT.lab la roadmap è sempre personalizzata al 100% per adattarsi agli obiettivi aziendali e alle sfide specifiche del cliente.
Ecco un esempio di programma di workshop realizzato di recente per un cliente:
- Panoramica SSL: cos’è e come viene utilizzato
- Collaborazione tra sviluppatori e ingegneri della sicurezza
- Formazione degli sviluppatori sulle vulnerabilità chiave
- Creazione di flussi di lavoro di prevenzione prima della distribuzione del prodotto
- Utilizzo di strumenti di analisi dinamica e statica (DAST e SAST)
- Esecuzione di test di penetrazione manuali
- Monitoraggio continuo durante l’intero ciclo di vita del prodotto
Per questo programma, alcuni punti possono sembrare ovvi o logici, ma ecco cosa ha fatto una differenza notevole: il 100% degli esempi utilizzati nella sessione erano direttamente pertinenti al settore del cliente, ai progetti in corso, al livello di competenza del team e allo stack tecnologico in uso del cliente. Input personalizzati, ma non casuali. Erano infatti il risultato di valutazioni precedenti condotte dal team di SORINT.lab.
Quindi, garantire il pieno allineamento con il team del cliente è ciò che fa la differenza. Ecco cosa significa “efficacia” e pertinenza.
Conclusione
Un’analisi dettagliata dell’agenda di cui sopra, come è stata realizzata, sarà tema di un articolo separato. Ciò fornirà una comprensione pratica di come le organizzazioni possono e dovrebbero integrare efficacemente queste metodologie nel loro flusso di lavoro di sviluppo software utilizzando modalità pertinenti.