I team della sicurezza hanno difficoltà a tenere il passo con lo sviluppo software. Si trovano di fronte a una serie di problemi, ad esempio il fatto che la dirigenza trascura erroneamente l'importanza della sicurezza nel processo di sviluppo, e il rapporto tra sviluppatori ed esperti di sicurezza. E ora che l'IA è fra noi, il ritmo è ancora più rapido. La velocità di sviluppo non farà che aumentare, di pari passo con la crescita delle imprese. Per questo motivo gli strumenti di sicurezza usati per gestire i processi di sviluppo devono corrispondere a tale crescita.
Inoltre, i team di sicurezza delle applicazioni devono gestire e assegnare priorità alle vulnerabilità in modo efficace. Con i criteri di sicurezza di GitLab e la nostra suite di strumenti di sicurezza, è possibile promuovere la collaborazione tra AppSec e i team di sviluppo, consentendo il rilevamento, la valutazione e la correzione efficiente delle vulnerabilità. I criteri di sicurezza offrono anche un meccanismo per automatizzare la conformità alla sicurezza e gestirla su scala aziendale.
L'analisi di molteplici possibili fonti di vulnerabilità offre maggiori opportunità di rilevamento precoce e risoluzione dei ticket, ma l'enorme volume di risultati può sopraffare i team di AppSec. Individuare le soluzioni attuabili sta diventando sempre più difficile man mano che ulteriori analisi fanno emergere sempre più informazioni sulle vulnerabilità.
Processi di valutazione della gestione delle vulnerabilità
Oggi esistono alcuni approcci comuni per gestire la valutazione delle vulnerabilità:
-
Common Vulnerability Scoring System: il CVSS è un metodo standardizzato per valutare la gravità della vulnerabilità. Sfruttando i punteggi CVSS, è possibile assegnare priorità alle vulnerabilità in base al loro possibile impatto e allocare le risorse di conseguenza.
-
Punteggio basato sul rischio: consente di valutare le vulnerabilità in base alla probabilità di sfruttamento e al possibile impatto aziendale. Considerando i fattori contestuali, come il valore delle risorse, le capacità degli attori delle minacce e la prevalenza dello sfruttamento, è possibile assegnare priorità alle vulnerabilità.
-
Modellazione delle minacce: un approccio che comporta l'individuazione e la valutazione delle minacce potenziali di un'applicazione o un sistema. Effettuando un'analisi completa dell'architettura del sistema, del flusso di dati e dei possibili veicoli di attacco, è possibile assegnare priorità alle vulnerabilità in base al loro legame con probabili minacce. Questo approccio aiuta ad allocare le risorse in modo efficace, concentrandosi sulle vulnerabilità che hanno maggiori probabilità di essere sfruttate.
-
Business Impact Analysis (BIA): è una tecnica per valutare il potenziale impatto delle vulnerabilità sulle operazioni e sugli obiettivi aziendali. Comporta l'individuazione delle risorse critiche, la valutazione della loro importanza per l'azienda e la quantificazione delle possibili conseguenze di un attacco riuscito. Considerando il potenziale impatto finanziario, reputazionale e operativo, è possibile assegnare priorità alle vulnerabilità che comportano il rischio maggiore per le funzioni aziendali principali.
Man mano che aumenta la proliferazione del codice generato dall'IA, aumenta anche il numero di vulnerabilità involontarie introdotte. Tecniche come queste sono quindi vitali per valutare e capire come assegnare le priorità. Come possiamo applicare questi quadri concettuali nel lavoro quotidiano? Scopriamo come metterli in pratica.
Gestione dei criteri di sicurezza
I criteri di sicurezza sono la risposta per scomporre i criteri aziendali e i requisiti di conformità in istruzioni operative tangibili, integrate nelle pratiche DevSecOps e nel ciclo di sviluppo software. Creando regole all'interno dei criteri di sicurezza di GitLab, è possibile definire criteri granulari per la valutazione delle vulnerabilità, assicurando che solo i risultati utili siano contrassegnati per un'ulteriore indagine.
I criteri di sicurezza ti consentono di applicare i requisiti di sicurezza e conformità e le best practice, istanziandoli nel codice. I criteri di esecuzione dell'analisi impongono l'esecuzione degli scanner all'interno di progetti specifici in base alle esigenze e ai requisiti, assicurando che eventuali vulnerabilità ed esposizioni siano rilevate prima di eseguire il merge del codice in produzione.
È anche possibile sfruttare i criteri di approvazione delle richieste di merge per creare flussi di lavoro personalizzati per risolvere le vulnerabilità. I criteri valutano i risultati dell'analisi di sicurezza e conformità per impedire o bloccare le richieste di merge, a meno che queste non siano state accuratamente revisionate e approvate in base alle regole definite.
Usando i criteri di approvazione delle richieste di merge e i criteri di esecuzione dell'analisi, è possibile aggiungere un livello di supervisione al processo di sviluppo. Ciò può garantire che il codice scritto da esseri umani (o in altro modo) sia stato analizzato automaticamente e che le violazioni dei criteri incoraggino la collaborazione tra i reparti di engineering e AppSec dove è più utile.
Definizione di regole granulari nei criteri di approvazione delle richieste di merge
Per fare un passo avanti ulteriore, è possibile definire regole granulari all'interno dei criteri di approvazione delle richieste di merge in base ai filtri e agli attributi indicati qui sotto. Queste regole possono aiutarti a determinare quali vulnerabilità sono più utili e a trovare un segnale nello static:
-
Stato delle vulnerabilità: i criteri di sicurezza possono essere affrontati in base allo stato di una vulnerabilità; spesso è utile concentrarsi su vulnerabilità appena rilevate che devono essere valutate. È anche possibile creare regole basate su vulnerabilità rilevate in precedenza con una determinata gravità o includere/escludere le vulnerabilità se sono state eliminate.
-
Ramo: le procedure vengono applicate solo su rami specifici, ad esempio il ramo predefinito dei progetti critici o eventuali rami protetti.
-
Disponibilità della correzione: i risultati vanno filtrati dai risultati dell'analisi delle dipendenze e dei container per cui non è disponibile una correzione. Spesso questi dipendono da cambiamenti a monte di terze parti e non sono ancora attuabili. È possibile creare ticket a partire dalle vulnerabilità e monitorali con una data di scadenza, per risolverli quando è disponibile una correzione.
-
Falso positivo: quando i nostri scanner GitLab determinano che una vulnerabilità rilevata è un falso positivo (per l'analisi di container e dipendenze), contrassegniamo lo stato all'interno della vulnerabilità. A questo punto, i criteri di sicurezza possono usare questa informazione per filtrare i falsi positivi, consentendo agli ingegneri e agli sviluppatori AppSec di ignorare questi risultati ed eseguire il merge del codice senza scoraggiarsi. Le vulnerabilità rimarranno disponibili nel report dedicato, per consentire un'analisi più approfondita se necessario.
-
Maturità o contratto di servizio (SLA): a volte le vulnerabilità di gravità inferiore possono essere tollerate per un certo periodo, ma devono essere pianificate e affrontate in un contratto di servizio ragionevole. Con i criteri di sicurezza, è possibile impostare uno SLA in base alla gravità dei risultati di vulnerabilità. Ad esempio, è possibile consentire il merge di vulnerabilità di livello intermedio senza richiedere l'approvazione per uno SLA di 60 giorni (che può essere affrontato in un ticket di follow-up con una data di scadenza). Ma se la vulnerabilità rilevata è superiore allo SLA di 60 giorni, bloccherà le richieste di merge e richiederà che venga affrontata.
Assegnare priorità ai risultati critici in tutta l'azienda
Un approccio comune per la gestione di grandi volumi di vulnerabilità è quello di iniziare in piccolo e dare priorità ai risultati più critici rilevati in tutta l'azienda. Uno SLA per la valutazione della gestione delle vulnerabilità può aiutare a raggiungere questo obiettivo, definendo regole per affrontare le vulnerabilità all'interno di un determinato SLA in base alla loro gravità. Ecco una rapida dimostrazione di come sfruttare un criterio di approvazione delle richieste merge di GitLab per applicare uno SLA diverso per ogni livello di gravità della vulnerabilità. In questo caso, se viene rilevato un risultato di gravità elevata, le richieste di merge non verranno bloccate per 30 giorni, dando agli sviluppatori il tempo di risolvere il ticket nella finestra dello SLA.
Garantire la separazione delle mansioni
I criteri di sicurezza possono essere gestiti in diversi modi, ma vengono gestiti meglio in un progetto GitLab isolato che garantisce la separazione delle mansioni tra i professionisti della sicurezza e i team di sviluppo. I criteri sono archiviati in YAML. Questo approccio "policy as code" offre più possibilità al team della sicurezza e ha molti vantaggi, tra cui maggiore visibilità grazie a una cronologia Git di tutte le modifiche ai criteri, la possibilità di eseguire più facilmente il rollback delle modifiche più importanti tramite il controllo della versione, la supervisione e le approvazioni richieste di tutte le modifiche ai criteri (se necessario), la verificabilità tramite eventi di controllo di GitLab e controlli concreti condivisibili come prove con gli auditor.
Legare i diversi elementi
La gestione del crescente afflusso di vulnerabilità richiede un approccio di precisione, bilanciando un'analisi approfondita con valutazioni e correzioni efficienti. I criteri di sicurezza di GitLab sono una soluzione potente che consente la collaborazione, offre flessibilità nella definizione di criteri personalizzati e un mezzo per rendere operativi con precisione i requisiti aziendali e i framework di conformità. Sfruttando gli strumenti di sicurezza di GitLab e applicando filtri e attributi personalizzati, è possibile ottimizzare la gestione delle vulnerabilità e concentrarsi sui rischi più critici, migliorando in ultima analisi la security posture generale e soddisfacendo i requisiti di enti esterni. Nonostante i timori legati al codice generato dall'IA, rimangono validi i tre pilastri della sicurezza: persone, processi e tecnologia. Incorporando i criteri di sicurezza nei processi aziendali, è possibile proteggersi da questi rischi.
Oltre a usare i criteri di sicurezza per applicare l'approccio "policy as code" su larga scala, la piattaforma DevSecOps di GitLab offre una solida suite di strumenti di sicurezza. Nel nostro recente Report globale 2023 sulla sicurezza, il 57% dei professionisti della sicurezza dichiara di usare sei o più strumenti per lo sviluppo del software e il 69% afferma di voler consolidare la propria toolchain. Molti responsabile della sicurezza informatica desiderano consolidare gli strumenti: GitLab può essere un valido aiuto per ridurre l'espansione incontrollata della toolchain. Infatti, GitLab offre le principali soluzioni per l'analisi di sicurezza: test statici di sicurezza delle applicazioni (anche per l'Infrastructure as Code), rilevamento dei segreti, test dinamici della sicurezza delle applicazioni (anche per le API), analisi delle dipendenze e sicurezza delle API. Permette inoltre ai team AppSec di gestire le vulnerabilità grazie a report dinamici. Infine, consente di completare le prassi di conformità con i framework di conformità, i report sul rispetto della conformità e gli eventi di audit.
Scopri di più su come gestire la sicurezza delle applicazioni con GitLab.
Prossimo articolo: Josh Lemos, CISO di GitLab, spiega come risolvere alcune comuni frustrazioni legate alla sicurezza.