Gestione delle vulnerabilità open source: cosa puoi gestire da solo prima di un audit SOC 2 o ISO 27001

Cos'è la gestione delle vulnerabilità open source?

La gestione delle vulnerabilità è il ciclo che parte dopo il rilevamento: raccogliere i finding di ogni scanner, eliminare i duplicati, ordinarli per priorità, dare a ciascuno un responsabile e una scadenza, correggerlo o accettarlo, e conservarne la prova. Nella versione open source questo ciclo si costruisce con strumenti gratuiti che ospiti tu, al posto di una piattaforma commerciale.

Gli scanner sono la parte facile, e li abbiamo messi alla prova: strumenti SCA open source sullo stesso repository e scanner di segreti open source a confronto. Quello che non ti danno è una memoria. Il 3 novembre 2026 abbiamo eseguito Trivy, Gitleaks e Opengrep su OWASP Juice Shop per la nostra guida alle scansioni per SOC 2: 383 finding in quattro file JSON, e nessuno riportava un commit, un responsabile, una scadenza o uno stato. È proprio questo il vuoto che colma il livello di gestione.

Cosa chiedono SOC 2 e ISO 27001?

Nessuno dei due framework nomina uno strumento. Il criterio CC7.1 di SOC 2 ti chiede di rilevare le nuove vulnerabilità e la tua esposizione a quelle appena scoperte. Il controllo A.8.8 della ISO 27001:2022 ti chiede di procurarti informazioni sulle vulnerabilità tecniche, valutare la tua esposizione e intervenire. Entrambi lasciano le scadenze alla tua policy, poi verificano che tu le abbia rispettate.

Il testo di SOC 2, così come lo riportano le società di audit, chiede procedure di rilevamento e monitoraggio che individuino da un lato le modifiche di configurazione che introducono nuove vulnerabilità, dall'altro l'esposizione a vulnerabilità appena scoperte. L'Annex A 8.8 della ISO 27001, dedicato alla gestione delle vulnerabilità tecniche, si apre così: «le informazioni sulle vulnerabilità tecniche dei sistemi informativi in uso dovrebbero essere ottenute». Poi chiede di valutare l'esposizione e di adottare misure adeguate. HighTable, una società di consulenza ISO 27001, fa notare che la norma non impone un numero preciso di ore: i tempi di correzione vengono da un accordo sui livelli di servizio (SLA) che definisci tu in base alla gravità.

Quindi l'auditor legge prima la tua policy, poi estrae un campione di finding e confronta ciascuno con quello che la policy prevede. La nostra guida su cosa chiedono gli auditor ISO 27001 e SOC 2 quando il codice lo scrivono gli agenti AI copre i controlli di sviluppo sicuro che stanno intorno, dall'A.8.25 all'A.8.29.

Quale strumento open source copre quale parte?

Ogni strumento qui sotto copre una parte del ciclo, e il registro al centro è il pezzo più facile da saltare.

Dependency-Track risponde a «quali delle nostre applicazioni contengono un componente appena diventato vulnerabile?», e un registro risponde a «a che punto è ogni finding, di ogni strumento, ed è ancora entro la scadenza?». DefectDojo è un registro che alimenti con l'export di ogni scanner, mentre CybeDefend Open Source lancia da sé gli scanner e riempie la sua coda a ogni esecuzione, senza export né import nel mezzo.

DefectDojo non scansiona: importa quello che esportano gli altri strumenti, elimina i duplicati e segue lo stato di ogni finding. Ha una Community Edition gratuita da ospitare in proprio, con licenza BSD-3-Clause, e un'edizione Pro a pagamento, e il suo repository contiene parser per Trivy, Grype, OSV-Scanner, Gitleaks, Semgrep, SARIF e Dependency-Track, fra gli altri.

OWASP Dependency-Track si definisce una piattaforma intelligente di Component Analysis. Sorveglia l'uso dei componenti in tutte le versioni di ogni applicazione del suo portafoglio, legge e produce SBOM e VEX in formato CycloneDX, e prende i dati sulle vulnerabilità da NVD, GitHub Advisories, OSV e altre fonti. La versione 5.2.1 è uscita il 25 ottobre 2026.

OpenCVE copre un vuoto che gli altri strumenti lasciano aperto. Ti permette di sorvegliare i tuoi fornitori e prodotti e di ricevere gli avvisi CVE che ti riguardano, inviati per email, Slack o webhook secondo regole che definisci tu, con il contesto CVSS, EPSS e KEV combinato in segnali di rischio chiari. Non è uno scanner SCA e non legge i tuoi lockfile. Il suo posto è la sorveglianza tra una scansione e l'altra, e sul software che sta fuori dai tuoi repository: il motore del database, la VPN, il runner della CI. OpenCVE gira come servizio cloud con un piano gratuito, oppure sui tuoi server secondo i termini della sua licenza, che richiedono una licenza commerciale per l'uso on-premise a fini commerciali.

Quali finding controlla l'auditor, e come?

Un auditor sceglie alcuni finding del periodo e segue ciascuno: quando è stato trovato, su quale commit o asset, chi ne era responsabile, quale scadenza fissava la tua policy per la sua gravità e come si è chiuso. Una correzione richiede la modifica che l'ha risolto. Un rischio accettato richiede una motivazione, un approvatore e una data di scadenza.

Lungo un periodo SOC 2 Type II, o tra due audit di sorveglianza ISO 27001, questa traccia deve esistere per mesi, non solo nella settimana prima dell'audit. Tre registrazioni reggono questa traccia:

• La policy: livelli di gravità, scadenze per ogni livello, chi può accettare un rischio e per quanto tempo.
• Il registro: ogni finding con le sue date, il responsabile, lo stato e il collegamento alla scansione che l'ha prodotto.
• Le eccezioni: ogni rischio accettato con il suo perimetro, la motivazione, l'approvatore e la scadenza.

Quanto costa davvero gestire tutto da soli?

Gli strumenti sono gratuiti. Il lavoro no: ospitare e aggiornare il registro, tenere i parser allineati all'output degli scanner, collegare i livelli di gravità alle tue scadenze e fare il triage ogni settimana, perché il registro resti fedele alla realtà. Ogni scanner e il registro pubblicano le proprie release, e qualcuno nel tuo team deve installare quegli aggiornamenti.

Per un team con un platform engineer e pochi repository, questo compromesso spesso conviene. Diventa più difficile quando crescono il numero dei repository e il ritmo delle modifiche, perché il registro vale quanto l'ultimo triage.

Cosa cambia quando il codice lo scrivono gli agenti AI?

Agenti di coding come Claude Code, Cursor, GitHub Copilot e OpenAI Codex aumentano il numero di modifiche a settimana, quindi i finding arrivano più in fretta e il registro deve stare al passo. Due registrazioni contano più di prima: la scansione di ogni modifica prima del merge, e la persona che ha approvato la modifica scritta da un agente.

L'agente che scrive il codice può anche lanciare l'audit. Con CybeDefend Open Source, /cybedefend lancia gli scanner AppSec dall'agente di coding a ogni modifica, poi manda lo stesso agente a cercare le falle che gli scanner non vedono e gli fa dimostrare ognuna con un exploit scritto come test. Ogni finding entra nella coda con la scansione che l'ha prodotto, e il registro tiene il passo degli agenti. L'agente può anche proporre la correzione, e il registro deve comunque mostrare chi l'ha rivista e chi ha fatto il merge, perché l'auditor campiona l'approvazione, non la patch. La nostra guida SOC 2 a scansioni e penetration test mostra come un finding passa dalla scansione su una modifica al report del periodo.

Dove si colloca CybeDefend?

CybeDefend Open Source arriva a breve, ed è fatto per il ciclo che questa guida descrive. Un comando nel tuo agente di coding, /cybedefend, fa un audit completo in due livelli. Prima gli scanner AppSec, open source, con un docker compose up, fra cui Opengrep, Trivy, Gitleaks e zizmor, per il codice, le dipendenze, i segreti, l'infrastructure as code, la CI/CD e i container. Tieni quelli che vuoi e aggiungi i tuoi. Poi lo scanner AI, eseguito dal tuo agente di coding. Gli scanner cercano pattern. Lo scanner AI legge cosa il tuo codice dovrebbe fare e trova dove si rompe, nella logica di business, nei permessi di accesso e nelle falle che emergono solo quando il codice gira, e dimostra ogni falla con un exploit scritto come test.

Sotto i due livelli c'è tutta la nostra piattaforma, un ASPM agentico, la stessa che ospitiamo già come CybeDefend Cloud. È lei a tenere il registro: i finding di tutti gli scanner in un'unica coda senza duplicati, e una policy di sicurezza scritta come codice che blocca il merge su un finding critico, con ogni eccezione delimitata, datata, motivata e approvata da una persona con nome e cognome. I report di sicurezza mappano i finding sull'OWASP Top 10 e sulla CWE Top 25, ed escono in PDF per l'auditor o in JSON per uno strumento GRC. Facciamo lo stesso percorso anche noi: il nostro audit SOC 2 Type II è in corso. Se stai preparando il tuo, possiamo ripercorrerlo insieme a te. Per lanciare l'audit sul tuo codice appena apre, iscriviti alla lista d'attesa di CybeDefend Open Source.

Domande frequenti

DefectDojo è gratuito?

La Community Edition di DefectDojo è open source con licenza BSD-3-Clause e puoi ospitarla in proprio gratis. DefectDojo vende anche un'edizione Pro, in cloud o on-premise. La Community Edition importa i finding, elimina i duplicati e ne segue lo stato. Prima di costruirci sopra il tuo processo, controlla nella pagina delle edizioni che ci siano le funzioni che ti servono.

Qual è il miglior strumento open source per gestire le vulnerabilità?

Dipende dal lavoro da fare. Dependency-Track sorveglia i componenti tramite gli SBOM. DefectDojo tiene un registro dei finding importati da molti scanner. OpenVAS scansiona host e reti. CybeDefend Open Source concatena gli scanner AppSec e uno scanner AI eseguito dal tuo agente di coding, e tiene un'unica coda governata dalle tue policy. Per un audit, una configurazione comune unisce un insieme di scanner e un registro.

La ISO 27001 obbliga a fare scansioni delle vulnerabilità?

Il controllo A.8.8 non nomina le scansioni. Ti chiede di ottenere informazioni sulle vulnerabilità tecniche, valutare la tua esposizione e adottare misure adeguate. Le scansioni regolari sono il modo abituale per dimostrare i primi due punti, e la frequenza la fissa la tua policy.

Entro quanto vanno corrette le vulnerabilità per la ISO 27001?

La norma non fissa nessun termine. Li definisci tu nella policy, per livello di gravità, e l'auditor verifica che tu li abbia rispettati. Secondo HighTable, gli auditor accettano in genere questo calendario: 48 ore per le critiche, 7 giorni per le alte, 30 giorni per le medie e 90 giorni per le basse.

OpenCVE è uno scanner di vulnerabilità?

No. OpenCVE sorveglia le pubblicazioni di CVE per i fornitori e i prodotti che segui e ti avvisa per email, Slack o webhook, con il contesto CVSS, EPSS e KEV. Non legge il tuo codice né i tuoi lockfile, quindi lavora accanto a uno scanner SCA e non lo sostituisce.

Esiste una versione open source di CybeDefend?

La sua edizione open source, CybeDefend Open Source, arriva a breve: tutta la nostra piattaforma, un ASPM agentico, gratis sui tuoi server. Il comando /cybedefend concatena gli scanner AppSec open source e uno scanner AI eseguito dal tuo agente di coding, e mette ogni finding in un'unica coda governata dalle tue policy. Fino ad allora, CybeDefend Cloud è la stessa piattaforma, ospitata da noi. Iscriviti alla lista d'attesa di CybeDefend Open Source.