Da qualche parte nel tuo stack c'è uno strumento di sicurezza per sviluppatori con una licenza che nessuno usa. Ha superato l'approvvigionamento. Ha superato il progetto pilota. CISO ha dato il via libera. E sei mesi dopo, gli sviluppatori aggirano il problema, disattivano gli avvisi o continuano a lavorare tranquillamente come hanno sempre fatto. Non si tratta di un problema di formazione o di cultura della conformità. È un problema di adozione della sicurezza da parte degli sviluppatori, ed è molto più comune e prevedibile di quanto la maggior parte dei responsabili della sicurezza voglia ammettere.
Cosa significa realmente l'adozione della sicurezza da parte degli sviluppatori
L'adozione della sicurezza da parte degli sviluppatori è il divario tra l'implementazione di uno strumento e il suo utilizzo quotidiano, secondo le modalità per cui è stato progettato, senza che sia necessario alcun intervento per imporne l'uso. Uno scanner in esecuzione in CI Una soluzione che gli sviluppatori non aprono mai viene implementata, non adottata. Una scoperta che viene scartata a prima vista perché le ultime dieci erano falsi positivi viene implementata, non adottata. La vera adozione della sicurezza da parte degli sviluppatori sembra noiosa: gli sviluppatori aprono volontariamente lo strumento, agiscono in base a ciò che dice e non cercano di aggirarlo.
Questa distinzione è importante perché le metriche di approvvigionamento e le metriche di adozione misurano cose completamente diverse. Un team di sicurezza può dichiarare una copertura di implementazione del 100% mentre l'adozione della sicurezza da parte degli sviluppatori è prossima allo zero, ed entrambi i valori possono essere veri contemporaneamente.
Perché i software di sicurezza tradizionali per sviluppatori non vengono utilizzati?
La maggior parte degli strumenti di sicurezza per sviluppatori non viene adottata per una serie di motivi ricorrenti, riscontrabili in quasi tutte le organizzazioni che hanno tentato di implementarne uno:
- Troppo rumore, troppa poca fiducia. Il modo più rapido per ostacolare l'adozione di misure di sicurezza da parte degli sviluppatori è un elevato tasso di falsi positivi. Dopo che uno sviluppatore ha indagato su tre segnalazioni che si sono rivelate infondate, smette di fidarsi della quarta e di prendere in considerazione anche la quinta.
- Si trova in un posto dove gli sviluppatori non si trovano. A dashboard gli sviluppatori devono ricordarsi di aprire è un dashboard Se ne dimenticheranno. Un software di sicurezza che richiede di uscire dall'IDE, cambiare contesto e tornare in seguito, fa perdere l'occasione di apportare la correzione più semplice ed economica.
- Segnala i problemi senza proporre soluzioni. Un risultato che dice "SQL injection, riga 42" senza spiegare il percorso dell'exploit o suggerire una soluzione dà allo sviluppatore dei compiti a casa, non un aiuto. Questo è un costo significativo per l'adozione della sicurezza da parte degli sviluppatori, perché trasforma ogni risultato in un progetto di ricerca invece che in uno sviluppocisione.
- Blocca le build senza fornire spiegazioni. Un rosso pipeline Senza contesto, viene percepito come un ostacolo, non come un segnale. Gli sviluppatori imparano a vedere il cancello di sicurezza come qualcosa da superare, non come qualcosa a cui prestare attenzione.
- È stato creato per il revisore dei conti, non per lo sviluppatore. Gli strumenti progettati principalmente per produrre prove di conformità spesso lo dimostrano: report prolissi, risultati pieni di tecnicismi, nessun tentativo di parlare il linguaggio di chi in realtà dovrebbe agire di conseguenza.
Test per sviluppatori di software di sicurezza: lo aprirebbero una seconda volta?
Ecco un utile filtro per valutare qualsiasi software di sicurezza per sviluppatori prima di acquistarlo: uno sviluppatore, senza che gli venga richiesto, lo aprirebbe di nuovo domani? Non perché una policy lo imponga, ma perché gli ha fornito qualcosa di utile ieri. La maggior parte degli strumenti che non vengono adottati dagli sviluppatori in ambito di sicurezza fallirebbero questo test fin dal primo giorno, e tutti lo sospettavano già prima della firma del contratto.
Gli strumenti che superano il test condividono alcune caratteristiche comuni. Vivono all'interno dell'editor, non dietro un loginSpiegano un problema come farebbe un ingegnere senior durante una revisione del codice, non come farebbe un report di conformità. Suggeriscono una soluzione specifica, non solo una diagnosi. E, cosa fondamentale, sono corretti abbastanza spesso da non richiedere a uno sviluppatore di ricontrollare ogni singolo avviso prima di fidarsi.
Cosa spinge realmente all'adozione?
Ottenere una corretta adozione della sicurezza da parte degli sviluppatori non significa migliorare la formazione o imporre un obbligo più rigoroso. Si riduce a un piccolo numero di principi di progettazione.cisioni:
- Incontra gli sviluppatori dove già lavorano. Sicurezza integrata nell'IDE, il pull requeste viene utilizzata la CLI. La sicurezza che richiede una destinazione separata non viene utilizzata.
- Spiega, non limitarti a segnalare. Una scoperta accompagnata da una spiegazione chiara e comprensibile del percorso di sfruttamento trasforma un avviso criptico in qualcosa su cui uno sviluppatore può ragionare e agire immediatamente.
- Proponete la soluzione, non solo il problema. La correzione automatica, che uno sviluppatore può esaminare e accettare in pochi secondi, rispetta il suo tempo in un modo che una segnalazione di bug non può mai fare.
- Mantieni elevato il rapporto segnale/rumore. Un filtraggio aggressivo dei falsi positivi non è un optional, ma il fattore determinante per la sopravvivenza dell'adozione delle misure di sicurezza da parte degli sviluppatori oltre il primo mese.
- Riserva i blocchi più difficili per ciò che conta davvero. Guardrails che interrompono la costruzione su ogni bassa gravità trovando sviluppatori di treni che si risentono del cancello. Guardrails Il fatto che blocchi solo i problemi realmente critici e risolvibili insegna agli sviluppatori ad avere fiducia nel sistema.
Come Xygeni affronta la progettazione del software di sicurezza per gli sviluppatori
Plugin Xygeni IDE Funziona dove gli sviluppatori già si trovano, all'interno dell'IDE, analizzando continuamente il codice generato da esseri umani e IA durante la scrittura, senza richiedere alcun intervento da parte loro. Quando rileva una vulnerabilità, spiega l'intero percorso di sfruttamento in un linguaggio semplice e propone una soluzione che lo sviluppatore può esaminare e applicare, anziché lasciarlo dedurre la causa da un semplice identificativo CVE.
Triage dell'intelligenza artificiale applica lo stesso filtro dei falsi positivi su SAST, Segreti, IaCe rilevazioni di malware a livello di piattaforma, in modo che il problema del rumore che ostacola l'adozione della sicurezza da parte degli sviluppatori altrove venga affrontato prima che una rilevazione raggiunga la coda di uno sviluppatore. Build guardrails far rispettare la politica presso pipeline a livello, ma in modo selettivo, bloccando solo i problemi realmente critici e risolvibili, anziché trattare ogni problema riscontrato come ugualmente in grado di compromettere la build. È questa distinzione che impedisce agli sviluppatori di imparare a eludere il controllo.
Niente di tutto ciò sostituisce la realtà che gli sviluppatori sono solitamente una leva, non l'acquirente economico, in un enterprise AppSec decisione A CISO firma il contratto; un vicepresidente dell'ingegneria si preoccupa se lo strumento crea problemi al suo team. Ma l'adozione della sicurezza da parte degli sviluppatori è proprio ciò che trasforma questa leva in un vantaggio concreto: uno strumento che gli sviluppatori utilizzano effettivamente risolve le vulnerabilità reali, mentre uno strumento che aggirano non ne risolve nessuna, indipendentemente da chi ha approvato l'ordine di acquisto.
Misurare l'adozione, non solo l'implementazione.
Se desideri un quadro onesto dell'adozione della sicurezza da parte degli sviluppatori all'interno della tua organizzazione, la copertura delle implementazioni non è la metrica giusta. Indicatori migliori includono:
- Con quale frequenza gli sviluppatori aprono lo strumento senza che venga loro richiesto.
- Quale percentuale delle soluzioni proposte viene accettata rispetto a quella respinta.
- La questione è se i tempi di risoluzione dei problemi si stiano effettivamente riducendo, non solo se i risultati vengano registrati.
- Sia che gli sviluppatori richiedano lo strumento in un nuovo progetto, sia che attendano di ricevere istruzioni per installarlo.
Il numero di licenze acquistate indica se la sicurezza per gli sviluppatori è stata effettivamente adottata.
FAQ
Che cosa significa "adozione della sicurezza da parte degli sviluppatori"?
Si tratta del divario tra l'implementazione di uno strumento di sicurezza e il suo effettivo utilizzo, ovvero in modo volontario e quotidiano, senza imposizioni. Un'elevata copertura di implementazione e una scarsa adozione delle misure di sicurezza da parte degli sviluppatori possono coesistere, e spesso coesistono.
Perché gli sviluppatori ignorano gli strumenti di sicurezza anche dopo aver ricevuto una formazione specifica?
La formazione non risolve i problemi di uno strumento che genera troppi falsi positivi, che si trova al di fuori del flusso di lavoro dello sviluppatore o che segnala un problema senza suggerire una soluzione. Si tratta di problemi di progettazione, non di lacune di conoscenza, e nessuna formazione, per quanto accurata, può eliminare le criticità di fondo.
Qual è il fattore più importante che influenza l'adozione della sicurezza da parte degli sviluppatori?
Abbi fiducia nel segnale. Quando gli sviluppatori smettono di fidarsi della veridicità di una scoperta, smettono di agire in base a tutte, comprese quelle importanti. Un filtraggio aggressivo dei falsi positivi è solitamente la soluzione più efficace disponibile.
In che modo il software di sicurezza per sviluppatori si differenzia dagli strumenti tradizionali di sicurezza delle applicazioni?
Il miglior software di sicurezza per sviluppatori considera lo sviluppatore come utente principale, non solo come destinatario dei controlli di conformità: funziona all'interno dell'IDE, spiega i risultati in un linguaggio semplice e propone soluzioni, anziché generare un report che qualcun altro dovrà interpretare in seguito.
Dovrebbe a CISA chi importa dell'adozione della sicurezza da parte degli sviluppatori se sono loro ad acquistare lo strumento?
Sì, direttamente. Uno strumento con una forte copertura di conformità ma una scarsa adozione della sicurezza da parte degli sviluppatori non riduce effettivamente il rischio, produce solo report. La riduzione del rischio un CISL'acquisto di O si concretizza solo se gli sviluppatori utilizzano lo strumento.
