Contrast Security questa settimana ha aggiunto a Intelligenza del percorso modulo per una valutazione della vulnerabilità Contrast Assess che automatizza il processo di scansione del codice.

Surag Patel, responsabile della strategia per Contrast Security, ha affermato che Route Intelligence utilizza sensori sotto forma di agenti leggeri per strumentare le applicazioni in modo che i team IT possano identificare più facilmente dove si trovano le vulnerabilità all'interno del codice in fase di sviluppo. Questi sensori consentono alla piattaforma Contrast Assess non solo di valutare continuamente le vulnerabilità delle applicazioni man mano che vengono create e aggiornate, ma anche di stabilire la priorità su quali vulnerabilità devono essere affrontate per prime in base alla loro potenziale gravità, ha affermato Patel.

L’obiettivo generale è promuovere l’adozione dei migliori processi DevSecOps in modo da generare il minor numero di attriti, ha aggiunto. Oggi gran parte del processo di riparazione è estremamente lento perché, una volta identificata una vulnerabilità, i team di sicurezza informatica trascorrono una quantità eccessiva di tempo alla ricerca di tutti i punti del codice in cui potrebbe esistere tale vulnerabilità.
Route Intelligence fornisce agli sviluppatori l'equivalente di una mappa per identificare tutte le istanze di una specifica vulnerabilità all'interno del loro codice, ha affermato Patel.

Questo approccio va oltre il semplice trasferimento della responsabilità della sicurezza delle applicazioni sulle spalle degli sviluppatori; estende inoltre la portata di DevSecOps a destra, strumentando il codice dell'applicazione in modo da facilitare la scoperta delle vulnerabilità, ha affermato Patel.

La strumentazione del software è, ovviamente, uno dei principi fondamentali di una migliore pratica DevOps. Contrast Security sta semplicemente sostenendo l’estensione della strumentazione e dell’osservabilità per includere la sicurezza informatica come parte dell’adozione di DevSecOps, ha affermato Patel. I team IT possono anche sfruttare le interfacce di programmazione delle applicazioni (API) REST per integrare Contrast Assess nelle loro piattaforme di integrazione continua/distribuzione continua (CI/CD).

Non è chiaro a questo punto in che misura DevSecOps diventerà un insieme distinto di compiti e funzioni all’interno di un processo DevOps o diventerà semplicemente un’estensione naturale di qualsiasi processo di garanzia della qualità delle applicazioni. L’attuale attenzione su DevSecOps può solo servire a evidenziare quanto lavoro sia necessario fare in quest’area poiché il volume degli attacchi informatici lanciati contro le applicazioni continua ad aumentare. Le organizzazioni, ovviamente, dipendono più che mai dal software, quindi ogni attacco riuscito sta causando molti più danni di quanto avrebbe potuto causare solo pochi anni fa.

Al momento, tuttavia, DevSecOps è molto più un’aspirazione che una realtà nella maggior parte delle organizzazioni. I team di sicurezza informatica hanno sempre guardato gli sviluppatori con sospetto perché la maggior parte delle vulnerabilità sfruttate dai criminali informatici hanno origine proprio dagli sviluppatori. Allo stesso tempo, gli sviluppatori oberati di lavoro non sono in grado di affrontare ogni vulnerabilità scoperta da un team di sicurezza informatica. Gli sviluppatori hanno bisogno di più contesto per trovare un equilibrio tra la quantità di tempo che dedicano alla correzione dei bug e alla creazione di nuovo codice. In molti casi, gli sviluppatori, giustamente o no, sono arrivati ​​a considerare il team di sicurezza informatica come un ostacolo alla loro capacità di fornire più codice più velocemente. In un mondo ideale, gli sviluppatori verrebbero ricompensati di più per fornire codice più sicuro e più velocemente. Tuttavia, per raggiungere questo obiettivo, le organizzazioni dovranno mettere in atto un quadro che consenta ai propri team IT di andare oltre il continuare a pubblicare occasionalmente la banalità DevSecOps.

- Michael Visir