Trova, classifica e risolvi le vulnerabilità di sicurezza nei tuoi repository
Security Swarm è il prodotto di Devin per la scansione di sicurezza e la remediation. Crea un modello delle minacce su misura per il tuo codice, indaga e verifica le potenziali vulnerabilità e ti aiuta a correggere i rilevamenti individuati tramite pull request. Può identificare vulnerabilità come l’esecuzione di codice remoto (RCE), SQL injection, path traversal, server-side request forgery (SSRF), bypass delle autorizzazioni, bug di memory safety, vulnerabilità di denial-of-service e altro ancora. Può persino identificare catene di exploit che coinvolgono più file.Security Swarm è un’orchestrazione personalizzata di Devins che chiamiamo Agentic MapReduce. Suddivide la tua repo tra più Devins in parallelo, offrendo un’ampia copertura e indagini approfondite, mantenendo sotto controllo i costi e rendendo conveniente la scansione di codebase di grandi dimensioni. Abbiamo anche valutato Security Swarm su un set di riferimento di vulnerabilità pubblicate tratte dal GitHub Advisory Database.
Prerequisiti
Per eseguire una scansione:
La tua organizzazione deve avere accesso al repository che vuoi analizzare.
Devi essere autorizzato a usare le sessioni Devin.
Ti serve l’autorizzazione Use code scans.
Per configurare una pianificazione Auto Scan, ti servono anche Manage code scans e l’autorizzazione per gestire le automazioni.
Se non vedi Sicurezza nella sidebar o non riesci ad avviare una scansione, chiedi a un amministratore di verificare il tuo ruolo. Per maggiori dettagli, consulta Access and permissions.
Apri Sicurezza nella barra laterale sinistra e fai clic su Avvia scansione.
In Singolo repo, scegli una repo da analizzare.
Assicurati che Modalità interattiva sia abilitata.
Fai clic su Esegui scansione.
Quando il modello di minaccia proposto è pronto, esaminalo e fai clic su Va bene, avvia la scansione oppure invia feedback.
Man mano che emergono rilevamenti, esamina le prove e intervieni sui rilevamenti che richiedono attenzione.
Per scansioni ripetibili, crea un profilo che includa il tuo ambito, il modello di minaccia, i criteri di gravità, i passaggi di convalida e i vincoli di remediation.
Apri una scansione per vedere i relativi rilevamenti. La pagina mostra a sinistra un elenco di rilevamenti, raggruppate per gravità, e a destra i dettagli del rilevamento selezionato.Le tab di stato mostrano un conteggio in tempo reale:
Open — richiede attenzione.
Reviewed — è stata esaminata e non richiede più interventi.
Dismissed — è stata identificata come falso positivo o duplicato.
Mentre una scansione è in corso, la pagina si aggiorna automaticamente man mano che arrivano nuovi rilevamenti.
Reviewed è uno stato del flusso di lavoro, non la conferma che una soluzione sia stata integrata. Un rilevamento può essere contrassegnato manualmente come Reviewed oppure quando una scansione successiva determina che non è più presente.
Gravità, stato, sfruttabilità, livello di attendibilità e categoria.
Il percorso del file e gli snippet di codice interessati.
Una descrizione del problema e una raccomandazione per la risoluzione.
Un risultato della convalida del runtime, prove a supporto e artefatti di convalida.
Le pull request associate e il loro stato: aperte, integrate o chiuse.
I responsabili del codice e le note, quando disponibili.
Considera un pattern di codice rischioso come un indizio, non come prova di una vulnerabilità. Verifica che il finding identifichi un percorso effettivamente raggiungibile a partire da input controllato da un attaccante, tenga conto dei controlli di convalida e autorizzazione e spieghi un impatto concreto sulla sicurezza.
Avvia una sessione di Devin per risolvere il problema e aprire una pull request. La sessione e la pull request risultante vengono registrate nel rilevamento.
Invia il contesto a una sessione di feedback che perfeziona il profilo di scansione per le scansioni future. Per esempio, spiega che un flusso di dati segnalato è protetto da un gateway interno, così le scansioni future potranno tener conto di quel controllo.
Applica un override al livello di gravità del rilevamento, con contesto facoltativo per Devin. Per esempio, riduci la gravità quando lo sfruttamento richiede un accesso interno privilegiato e includi questo vincolo come contesto.
Contrassegna il rilevamento come Aperto, Esaminato o Ignorato. Mantieni un rilevamento come Aperto finché richiede un intervento, contrassegnalo come Esaminato dopo il triage oppure ignoralo se è un falso positivo o un duplicato.
Un profilo di scansione definisce l’ambito della scansione e fornisce indicazioni per ogni fase del processo. Ogni scansione può usare un solo profilo. Per valutare un repository rispetto a più profili di attaccante o categorie di minacce, esegui scansioni separate con profili diversi.
Un modello di minaccia specifico è uno dei modi più efficaci per mantenere una copertura coerente tra le scansioni. Definisci l’attaccante, le risorse sensibili, i confini di attendibilità, i punti di accesso principali e le esclusioni esplicite.
Gestisci i profili dalla scheda Profili nella pagina Sicurezza.
Genera con Devin — descrivi l’applicazione, le minacce, l’ambito, le esclusioni e i criteri di gravità in linguaggio naturale. Devin crea una bozza del profilo per te.
Crea manualmente — compila personalmente ogni campo del profilo.
Generare con Devin è un utile punto di partenza, ma controlla ogni campo generato prima di usare il profilo. Se lasci vuoto un campo di istruzioni facoltativo, verrà applicato il comportamento predefinito di Security Swarm per quella fase.
Nome del profilo — indica la superficie dell’applicazione o la categoria di minaccia, anziché il team che esegue la scansione. Esempio: Autorizzazione API multi-tenant.
Descrizione — riassumi l’ambito del profilo e il relativo obiettivo di sicurezza. Esempio: Individua vulnerabilità di autenticazione, autorizzazione e isolamento del tenant nell'API pubblica.
Gli esempi seguenti confluiscono in un unico profilo per un’API multi-tenant. Adatta i confini, i comandi e i criteri di gravità alla tua applicazione.
Descrivi l’attaccante, gli asset sensibili, i confini di attendibilità, i principali punti di ingresso e tutto ciò che è esplicitamente fuori dall’ambito. Queste indicazioni definiscono le regole che Devin genera prima dell’avvio dell’indagine.
Considera un attaccante non autenticato proveniente da internet o un utente autenticato in un singolo tenant.Concentrati sui gestori HTTP pubblici, i callback OAuth, i token API, le azioni amministrativee gli accessi ai dati appartenenti al tenant. Considera fuori ambito gli script di sviluppo interni e gli strumentidisponibili solo in locale. Dai priorità ai bypass dell'autenticazione, agli accessi cross-tenant, alle fughe di token,alle injection e agli attacchi SSRF.
Definisci come Devin deve esaminare un potenziale problema e quali evidenze deve raccogliere. Chiedigli di tenere conto delle mitigazioni esistenti e di distinguere le vulnerabilità sfruttabili dai rischi puramente teorici.
Trace untrusted input from the route through middleware and service layers to thesensitive operation. Check authentication, authorization, tenant scoping, validation,and escaping at every boundary. Identify the exact reachable path and cite the relevantfiles and lines. Do not report a theoretical issue when an effective mitigation blocksthe path.
Definisci come Devin deve eliminare i duplicati e assegnare le priorità ai rilevamenti. Includi i criteri di gravità in modo che i rilevamenti siano in linea con gli standard della tua organizzazione.
Raggruppa i findings che condividono la stessa causa principale. Considera critici l'esecuzione di codice remoto non autenticata e l'accesso in scrittura cross-tenant. Considera ad alto rischio l'accesso in lettura cross-tenant e la divulgazione di credential. Considera a rischio medio i problemi di disponibilità per singolo utente, a meno che non possano influire sull'infrastructure condivisa. Classifica come a basso rischio le raccomandazioni di difesa in profondità.
Abilita la validazione del runtime quando Devin può compilare ed eseguire test sull’applicazione in sicurezza. Spiega come avviare l’applicazione, creare dati di test, autenticarsi e dimostrare il perimetro di sicurezza atteso.
Utilizza la configurazione di sviluppo documentata nel repo. Avvia l'API e crea duetenant non di produzione con un utente di test ciascuno. Esegui la richiesta sospetta comeutente dell'altro tenant, quindi verifica sia la risposta HTTP che i dati persistiti.Non chiamare servizi di produzione né modificare dati di produzione.
Una validazione non riuscita non sempre smentisce un rilevamento. Esamina il risultato della validazione e gli artefatti per determinare se una mitigazione efficace ha bloccato l’exploit o se l’ambiente configurato ha impedito a Devin di completare il test.
La validazione del runtime avvia una sessione separata di Devin per ogni rilevamento. Consulta Configure validazione del runtime per indicazioni sull’ambiente.
Attiva i report quando ti serve un riepilogo al termine della scansione. Specifica il pubblico di destinazione e le informazioni da mettere in evidenza nel report.
Scrivi un riepilogo esecutivo per i responsabili della sicurezza e dell'ingegneria. Elenca prima i risultati critici e ad alta gravità confermati, seguiti dai risultati non validati. Includi i componenti interessati, lo stato di validazione, lo stato della pull request e un piano di remediation con priorità definite.
Specifica i vincoli che Devin deve rispettare quando assegni una segnalazione per la correzione. Includi le aspettative di testing, i requisiti di compatibilità e le pratiche da evitare.
Preferire la modifica minima sicura e preservare il comportamento esistente dell'API pubblica. Aggiungere untest di regressione che fallisca prima della soluzione e passi dopo. Eseguire i comandilint e test del package interessato. Evitare aggiornamenti importanti delle dipendenze a meno che la vulnerabilità non possaessere risolta in modo sicuro senza di essi.
Apri Advanced per gestire l’ambito dei file e i batch di analisi:
Include globs — limita la scansione ai file corrispondenti. Per esempio, apps/api/** e packages/auth/**.
Exclude globs — rimuovi i file non pertinenti dall’ambito selezionato. Per esempio, **/generated/**, **/vendor/** e **/fixtures/**.
Batch size — controlla quanti file con segnali vengono raggruppati in ciascun batch di analisi. Lascia il valore predefinito, a meno che tu non voglia ottimizzare intenzionalmente il comportamento della scansione. L’intervallo consentito è 1–500; il valore predefinito è 5.
Esclusioni troppo ampie possono nascondere codice vulnerabile o rimuovere il contesto necessario per comprendere un flusso di dati. Escludi solo i file che sei certo non siano pertinenti per questo profilo.
I nuovi profili sono limitati all’organizzazione. In seguito, gli amministratori di Enterprise possono modificare la visibilità di un profilo in Enterprise, rendendolo disponibile in tutta l’Enterprise.I profili Enterprise possono essere modificati o archiviati solo dagli amministratori di Enterprise. Gli altri utenti con accesso a Sicurezza possono visualizzarli e usarli, ma non possono modificarli.
Con Modalità interattiva abilitata, Devin elabora una proposta di modello di minaccia e si ferma prima dell’analisi. La pagina di scansione mostra le regole proposte e ti consente di:
Sembra tutto corretto, avvia la scansione — accetta il modello di minaccia e avvia l’analisi.
Fornisci feedback sul modello di minaccia — descrivi cosa aggiungere, rimuovere o mettere in evidenza, quindi rivedi il modello aggiornato.
Usa la modalità interattiva per la prima scansione di un repository e ogni volta che la sua superficie di rischio o il suo profilo cambiano in modo significativo. Una volta che il profilo recepisce le indicazioni approvate, le scansioni di routine possono essere eseguite senza questa pausa.
La validazione del runtime viene eseguita solo quando il profilo selezionato ha la validazione del runtime abilitata e contiene istruzioni di validazione. Fornisci a Devin informazioni sufficienti per compilare, eseguire, inizializzare e autenticare l’applicazione nel suo sandbox.Se il repository ha una configurazione dichiarativa, Devin può riutilizzare la configurazione di build e installazione. In caso contrario, aggiungi alle istruzioni di validazione del profilo i comandi di configurazione richiesti.
Non inserire credenziali di produzione o valori segreti direttamente nelle istruzioni del profilo. Usa account di test non di produzione e credenziali già fornite tramite la configurazione dell’ambiente della tua organizzazione.
Usa la scheda All repos nella finestra di dialogo New Scan per mettere in coda scansioni a livello di organizzazione:
Inserisci facoltativamente un Repository name filter.
Seleziona facoltativamente un profilo di scansione.
Lascia abilitato Skip already-scanned repos per escludere i repository già sottoposti a scansione con il profilo selezionato.
Fai clic su Anteprima.
Controlla i repository trovati, deseleziona quelli che non vuoi sottoporre a scansione e conferma.
L’anteprima è una simulazione. Se modifichi il filtro, il profilo o l’impostazione skip, l’anteprima non è più valida e non puoi confermare un elenco non aggiornato.
Auto Scan analizza periodicamente i commit aggiunti dopo l’ultima scansione completata. Puoi configurarlo:
Durante l’avvio di una scansione di un singolo repository, selezionando una pianificazione giornaliera, settimanale, mensile o personalizzata.
Da una scansione esistente, aggiungendo, modificando, disattivando o eseguendo immediatamente la relativa pianificazione.
Auto Scan è implementato tramite un’automazione. Per configurarlo sono necessari sia Gestire le scansioni del codice sia l’autorizzazione a gestire le automazioni. Gli orari della pianificazione sono visualizzati nel tuo fuso orario locale.
Fai clic su Scansiona i nuovi commit in una scansione completata per analizzare i commit aggiunti dall’ultimo commit scansionato. Auto Scan utilizza lo stesso comportamento incrementale, quindi le scansioni successive sono meno costose rispetto a scansionare ripetutamente l’intero ambito del repository.
Dopo il completamento della prima scansione dell’organizzazione, la pagina Sicurezza mostra una dashboard a livello di organizzazione relativa agli ultimi 7, 30 o 90 giorni:
Statistiche delle pull request — pull request create, integrate, aperte e chiuse, oltre al tasso di merge.
Andamento dei rilevamenti — rilevamenti raggruppati per gravità nel periodo selezionato.
L’accesso a Sicurezza è controllato tramite le autorizzazioni per la scansione del codice nell’editor dei ruoli:
Autorizzazione
Cosa consente
Ruoli predefiniti
Visualizzare le scansioni del codice
Visualizzare scansioni, profili, rilevamenti e le relative sessioni di scansione.
Admin
Usare le scansioni del codice
Avviare scansioni, creare profili dell’organizzazione, inviare feedback sui rilevamenti, modificarli, cambiarne lo stato e assegnarli a Devin.
Admin
Gestire le scansioni del codice
Archiviare o rimuovere dall’archivio le scansioni e configurare le pianificazioni di Auto Scan.
Admin
Gestire le scansioni del codice dell’account
Promuovere i profili dell’organizzazione all’ambito Enterprise e modificare o archiviare i profili Enterprise.
amministratore Enterprise
Per avviare scansioni, inviare feedback e assegnare rilevamenti a Devin è inoltre necessaria l’autorizzazione a usare le sessioni di Devin. Auto Scan richiede anche l’autorizzazione a gestire le automazioni.Per impostazione predefinita, i membri non ricevono autorizzazioni per la scansione del codice. I proprietari dispongono di tutte le autorizzazioni e gli amministratori possono concederle ai membri tramite i ruoli personalizzati.
Per un confronto utile, assegna a entrambi gli scanner lo stesso ambito, lo stesso modello di minaccia, gli stessi criteri di gravità e gli stessi requisiti di validazione. Altrimenti, le differenze di configurazione possono oscurare le differenze nelle capacità effettive.Usa i profili per definire i criteri di confronto, la modalità interattiva per confermare il modello di minaccia generato e la validazione del runtime per applicare lo stesso standard di evidenza ai problemi segnalati.
In che modo Security Swarm riduce i falsi positivi?
Security Swarm analizza le potenziali vulnerabilità nel contesto del tuo repository, invece di segnalare pattern rischiosi in modo isolato. Devin traccia i flussi di dati pertinenti, verifica i controlli di convalida e autorizzazione e valuta se il problema ha un impatto concreto sulla sicurezza.Ogni rilevamento include un livello di attendibilità e gli elementi di supporto. Esaminali prima di intervenire, soprattutto quando un rilevamento non è stato convalidato a runtime.
Quali elementi dovrei esaminare in un rilevamento?
Verifica il codice interessato, il punto di ingresso, il flusso di dati, le mitigazioni esistenti, l’impatto dichiarato, l’attendibilità e la sfruttabilità. Quando la validazione del runtime è abilitata, esamina anche il risultato della convalida e i relativi artefatti di supporto.Se gli elementi forniti non tengono conto di un controllo o indicano un impatto non supportato, usa Feedback per fornire il contesto mancante per le scansioni future.
Cosa aggiunge la validazione del runtime?
La validazione del runtime tenta di riprodurre un rilevamento compilando ed eseguendo l’applicazione in un ambiente isolato. Una convalida riuscita fornisce prove più solide della sfruttabilità, mentre una convalida non riuscita può evidenziare presupposti o limitazioni dell’ambiente che richiedono ulteriori verifiche.La validazione del runtime è facoltativa e richiede indicazioni per la convalida sufficienti perché Devin possa compilare, eseguire, inizializzare e autenticare l’applicazione in modo sicuro.
In che modo Security Swarm trova vulnerabilità che coinvolgono più file?
Security Swarm analizza in parallelo parti del repository e combina i risultati in una vista dell’intero repository. Questo gli consente di identificare le relazioni tra i componenti, ad esempio un endpoint che espone un identificatore necessario per sfruttarne un altro.Qualsiasi rilevamento concatenato risultante dovrebbe comunque identificare i percorsi di codice pertinenti e spiegare come le singole condizioni si combinano in un impatto concreto.
Perché i risultati potrebbero variare tra una scansione e l'altra?
Security Swarm usa un’analisi agentic, quindi scansioni separate potrebbero non produrre rilevamenti o formulazioni identici. Un ambito ben definito, un modello di minaccia esplicito, criteri di gravità chiari e indicazioni di indagine specifiche aiutano a mantenere coerente la copertura.Raccogli questi requisiti in un profilo di scansione riutilizzabile, usa la modalità interattiva per esaminare il modello di minaccia proposto e fornisci feedback quando un risultato non coglie un contesto importante.
Una scansione completata significa che il repository non ha altre vulnerabilità?
Nessuno scanner di sicurezza può garantire una copertura completa. I risultati dipendono dall’ambito selezionato, dalle indicazioni del profilo, dal contesto del repository disponibile e dalla possibilità di convalidare i rilevamenti nell’ambiente configurato.Esegui scansioni separate per modelli di attaccante o categorie di minaccia distinti, mantieni aggiornati i profili man mano che l’applicazione cambia e usa Security Swarm insieme alle pratiche esistenti di revisione della sicurezza e testing.
