SOC 2 richiede penetration test e scansione delle vulnerabilità?

SOC 2 richiede il penetration test?

SOC 2 non richiede il penetration test. I Trust Services Criteria lo citano in un point of focus del CC4.1, come esempio delle valutazioni separate che un'organizzazione può usare per verificare che i suoi controlli funzionino. Se ti serve un test, e con quale frequenza, dipende dalla tua valutazione del rischio e dai controlli che descrivi nel report.

I criteri li pubblica l'AICPA, l'associazione dei revisori statunitensi. La loro forma attuale sono i Trust Services Criteria del 2017 con i points of focus rivisti nel 2022, un documento gratuito ma accessibile solo con un account AICPA, quindi la formulazione riportata qui sotto viene dalle società di audit che la riproducono. Linford & Co, una società di revisione (CPA firm) che esegue audit SOC 2, la mette in modo netto: «the simple answer is no», la risposta semplice è no. Il CC4.1 chiede all'organizzazione di condurre valutazioni continue o separate per assicurarsi che le componenti del controllo interno siano presenti e funzionanti. Il suo point of focus elenca il penetration test accanto alle certificazioni indipendenti, come quelle ISO, e all'audit interno, fra i tipi di valutazione che il management può usare. L'articolo di Linford è di giugno 2021, quindi precede la revisione del 2022.

La revisione del 2022 non ne ha fatto una regola. BARR Advisory, un'altra società di audit SOC 2, cita l'AICPA a proposito dei points of focus rivisti: «do not, in any way, alter the criteria in the 2017 TSC», cioè non modificano in alcun modo i criteri del 2017.

Sulla carta, quindi, il test è facoltativo, e la scelta tocca a te giustificarla. Linford consiglia a qualunque azienda che offre i propri servizi attraverso un sito web pubblico e interattivo di prenderne seriamente in considerazione uno, con frequenza e perimetro stabiliti da un'accurata valutazione del rischio.

In un caso la scelta è già fatta. La società di audit TrustNet descrive la system description come la tua scomposizione di sistemi, servizi e controlli, scritta da te e rivista dall'auditor. Il giudizio dell'auditor dice poi se quei controlli sono progettati bene (Type I) e se hanno funzionato nel tempo (Type II). Se la tua descrizione o la tua policy dice che fai un penetration test all'anno, quel test è diventato uno dei tuoi controlli, e l'auditor ti chiederà il report.

SOC 2 richiede la scansione delle vulnerabilità?

SOC 2 non indica la scansione delle vulnerabilità come requisito. Il CC7.1 chiede procedure di rilevamento e monitoraggio che intercettino le modifiche di configurazione che introducono nuove vulnerabilità e la tua esposizione a quelle appena scoperte. Il suo point of focus «Conducts Vulnerability Scans» descrive scansioni periodiche e dopo ogni modifica significativa, con le carenze trovate corrette in tempi adeguati.

Linford & Co riporta il point of focus: le scansioni vanno eseguite «on a periodic basis and after any significant change in the environment», periodicamente e dopo ogni modifica significativa dell'ambiente, e l'organizzazione corregge in tempi adeguati quello che trovano. Il verdetto è lo stesso del penetration test, nessun requisito, ma con un avvertimento: «it may be tough for a user organization to accept a clean SOC 2 report», un'organizzazione cliente può fare fatica ad accettare un report SOC 2 pulito che non faccia alcun riferimento alle scansioni.

Il riepilogo di BARR Advisory sulla revisione del 2022 non mette il CC7.1 fra le modifiche: per le operazioni di sistema cita la gestione delle informazioni riservate nel CC7.3. Il criterio sulla gestione delle modifiche, il CC8.1, ha invece guadagnato dei points of focus sulla «identification, testing, and implementation of software patches», cioè l'individuazione, il test e l'applicazione delle patch software. Aggiornare una dipendenza vulnerabile è una patch, quindi anche il lato correttivo delle scansioni ricade nella gestione delle modifiche.

Il point of focus non indica né uno strumento, né una frequenza, né un perimetro. Sei tu a decidere che cosa copre «l'ambiente» (il tuo codice, le sue dipendenze, i container, la configurazione cloud, gli host), lo scrivi nella tua policy, e l'auditor ti chiede conto di quello che hai scritto.

Che differenza c'è tra una scansione delle vulnerabilità e un penetration test?

Una scansione delle vulnerabilità è automatica: uno strumento confronta il tuo codice, le dipendenze o gli host con debolezze note ed elenca quello che trova. Un penetration test lo fanno delle persone, con strumenti e giudizio proprio, per sfruttare le debolezze e mostrare dove arriverebbe un attaccante. Per SOC 2, le scansioni supportano il CC7.1, il penetration test il CC4.1.

Linford & Co traccia la stessa linea. Un vulnerability assessment «is an automated activity», un'attività automatizzata svolta con uno strumento, mentre un penetration test lo esegue una persona o un gruppo di persone che sfruttano vulnerabilità ed errori di configurazione con strumenti automatici e tecniche proprie. Per un team che sviluppa software, la parola «scansione» copre diversi tipi di strumento: l'analisi statica del codice (SAST), l'analisi delle dipendenze (SCA), il secret scanning e i controlli sui file di infrastruttura e sulle immagini container.

Ogni quanto bisogna fare le scansioni per SOC 2?

Scansiona con la frequenza che stabilisce la tua policy, e dopo ogni modifica significativa. SOC 2 non fissa un intervallo: il point of focus «Conducts Vulnerability Scans» del CC7.1 chiede scansioni periodiche e dopo ogni modifica significativa dell'ambiente. Una scansione su ogni pull request copre le modifiche, e una scansione pianificata copre tutto il resto.

Il CC7.1 ha due metà, e ognuna chiede il suo trigger. La prima riguarda le modifiche di configurazione che introducono vulnerabilità, e le intercetti scansionando la modifica stessa, in CI, prima del merge. La seconda riguarda l'esposizione a vulnerabilità appena scoperte, e la intercetti scansionando a calendario anche il codice che non hai più toccato, perché i nuovi advisory continuano a colpire vecchie dipendenze. Nella nostra scansione del 3 novembre, quattro dei nove finding critici sulle dipendenze venivano da advisory pubblicati fra luglio e settembre 2026. Una scansione eseguita a giugno, esattamente sullo stesso codice, non avrebbe potuto segnalarli.

Scrivi entrambi i trigger nella tua policy, con una scadenza per ogni livello di gravità entro cui correggere quello che le scansioni trovano. L'auditor può prendere un finding qualsiasi del periodo e confrontarlo con le tue scadenze, quindi scegli scadenze che riesci a rispettare.

Quali prove chiede un auditor SOC 2?

L'auditor chiede registrazioni: che le scansioni siano state eseguite quando lo prevedeva la policy, che cosa coprivano, che cosa hanno trovato e che fine ha fatto ogni finding, corretto entro la scadenza o accettato come eccezione con una motivazione e un approvatore. In un report Type II il giudizio copre un intero periodo, quindi anche le registrazioni devono coprirlo.

Un report SOC 2 è un esame svolto da un revisore abilitato e indipendente, un CPA, secondo gli standard di attestazione dell'AICPA, come si legge nel comunicato della stessa AICPA. In un Type II, il giudizio del CPA riguarda il modo in cui i tuoi controlli hanno funzionato lungo un periodo. Per la gestione delle vulnerabilità, questo si traduce in un breve elenco di domande:

Gli scanner open source possono produrre prove per SOC 2?

Gli scanner open source producono la metà delle prove SOC 2 che riguarda il rilevamento. Il 3 novembre 2026 abbiamo fatto girare Trivy, Gitleaks e Opengrep su OWASP Juice Shop e ottenuto 383 finding grezzi in quattro file JSON, in 56 secondi. Nessun file indica il commit scansionato, un responsabile, una scadenza o uno stato: proprio ciò che l'auditor campiona.

Abbiamo usato OWASP Juice Shop nella versione 20.3.0, rilasciata l'11 ottobre 2026. Il suo README la presenta come «probably the most modern and sophisticated insecure web application», probabilmente l'applicazione web insicura più moderna e sofisticata in circolazione, quindi i numeri qui sotto non dicono nulla di un codebase normale: mostrano la forma di quello che gli strumenti ti consegnano. Juice Shop non include un lockfile, quindi per la scansione delle dipendenze ne abbiamo generato uno il giorno stesso a partire da una copia del suo package.json, con gli script di installazione di npm disattivati. Poi abbiamo lanciato quattro comandi:

trivy fs --scanners vuln --format json --output trivy-sca.json sca/
trivy fs --scanners misconfig,secret --format json --output trivy-repo.json juice-shop/
gitleaks dir juice-shop --report-format json --report-path gitleaks.json
opengrep scan --config opengrep-rules/javascript --config opengrep-rules/typescript \
  --config opengrep-rules/terraform --json --output opengrep.json juice-shop/

Risultati di quattro scansioni open source di OWASP Juice Shop 20.3.0, eseguite il 3 novembre 2026. Abbiamo scansionato il tag v20.3.0 al commit f189f52, con le regole community di Opengrep al commit f1d2b56, le impostazioni predefinite di Trivy e nessuna messa a punto. Le quattro esecuzioni hanno richiesto 56 secondi di tempo reale, compreso l'aggiornamento del database di Trivy:

Ogni strumento ha trovato quello per cui è stato costruito. Fra questi file e una prova SOC 2 restano comunque quattro ostacoli:

1. I duplicati. I cinque segreti trovati da Trivy sono fra i 69 di Gitleaks, allo stesso file e alla stessa riga. Dei 54 finding Terraform di Opengrep, 17 stanno sulla stessa riga di un finding di Trivy e 34 entro tre righe da uno. Senza un'unione, un solo problema diventa due ticket e due scadenze.
2. Tre scale di gravità. Trivy classifica da critico a basso, Opengrep da error a info, e Gitleaks non classifica affatto. Una policy che dice «finding critici corretti entro N giorni» ha bisogno di una scala sola, quindi qualcuno deve ricondurre le altre due a quella.
3. La copertura. Opengrep ha scansionato 1.306 file e registrato 32 errori di parsing e parsing parziali, in una sezione errors che vedi solo se leggi il file. Un auditor che chiede se la scansione ha coperto il codice ha bisogno proprio di quella riga.
4. La registrazione in sé. I file di Trivy riportano un timestamp di creazione e il percorso scansionato. Quelli di Opengrep non hanno nessun timestamp. In modalità directory, Gitleaks lascia vuoti i campi del commit e della data. Nessun file ha un responsabile, una scadenza o uno stato.

Gli scanner open source, in sé, reggono bene. I nostri test degli strumenti SAST open source verificati su GitHub e di sei scanner di segreti open source messi alla prova sullo stesso repository pieno di segreti finti mostrano che puoi coprire codice e segreti senza pagare uno scanner. Il volume è l'altra metà del lavoro, e il nostro articolo su che cosa trasforma i finding SAST in rumore spiega perché un conteggio grezzo di 149 finding sul codice è una coda di triage, non 149 vulnerabilità.

Per trasformare i file in prove ti serve una coda per ogni repository, in cui i finding di tutti gli strumenti vengono uniti, ognuno riceve un responsabile e una scadenza secondo la tua policy, e la sua storia resta: aperto, corretto, accettato come eccezione. I team la costruiscono con uno strumento open source di gestione delle vulnerabilità come DefectDojo, con i ticket, oppure con una piattaforma. CybeDefend Open Source si occupa di questa parte: fa girare gli scanner che scegli tu, qualunque strumento scriva SARIF, e mette quello che trovano in un'unica coda senza duplicati, gratis e sui tuoi server. Arriva a breve, e la lista d'attesa è aperta.

Che cosa cambia quando il codice lo scrivono gli agenti AI?

I criteri SOC 2 restano gli stessi quando il codice lo scrivono gli agenti AI, ma le modifiche significative diventano più frequenti, quindi la scansione del CC7.1 deve girare su ogni modifica, non solo a calendario. I criteri 2027 proposti dall'AICPA aggiungono points of focus sull'AI, obbligatori solo per gli incarichi che iniziano a partire dal 31 dicembre 2027.

La quota di codice scritto dagli agenti può essere alta. Il 3 novembre 2026, 482 dei 509 commit entrati nel branch principale del repository del nostro sito nei 90 giorni precedenti portavano un trailer di co-autore di Claude Code. A questo ritmo, per SOC 2 cambiano tre cose:

• La lettura riga per riga la fa la scansione. Un gate di merge che scansiona ogni pull request è il controllo che gira su ogni modifica, ed è quello che chiedono il CC7.1 e il CC8.1. Il nostro articolo sui controlli di sicurezza per la pull request di un agente AI descrive quel gate passo per passo.
• Le dipendenze arrivano insieme alle funzionalità. Un agente che aggiunge un pacchetto aggiunge una voce che la scansione pianificata deve tenere d'occhio, e ogni aggiornamento che fa è una patch ai sensi del CC8.1.
• I test verdi dimostrano meno. Spesso un agente scrive una funzionalità e i relativi test nella stessa sessione. I suoi test verificano ciò che voleva costruire, quindi una regola che gli è sfuggita nel codice può mancare anche nei test, e la CI resta verde. Uno scanner lanciato dalla CI è un controllo che l'agente non ha scritto.

Anche i criteri si stanno muovendo. Il 28 ottobre 2026 l'AICPA ha messo in consultazione un exposure draft, una bozza, dei nuovi Trust Services Criteria di SOC 2. Il comunicato elenca nuovi points of focus su «AI governance, model monitoring, prompt manipulation, data poisoning», cioè governance dell'AI, monitoraggio dei modelli, manipolazione dei prompt e avvelenamento dei dati, oltre alla trasparenza degli output generati dall'AI, alla gestione dei dati di addestramento e alle decisioni automatizzate. I commenti sono aperti fino al 15 gennaio 2027. Se approvati, i nuovi criteri si applicherebbero agli incarichi che iniziano a partire dal 31 dicembre 2027, con adozione anticipata consentita. Il comunicato non dice se questi points of focus riguardano anche gli agenti di coding, e la bozza stessa richiede un account AICPA, quindi non l'abbiamo letta. Finché i nuovi criteri non saranno definitivi e in vigore, il tuo audit si basa sui criteri del 2017 con i points of focus del 2022.

Che cosa devi avere pronto prima dell'audit SOC 2?

Ti servono una policy di gestione delle vulnerabilità scritta, scansioni a calendario e su ogni modifica, una registrazione per ogni finding con responsabile, scadenza ed esito, eccezioni approvate e il report di un penetration test se la tua valutazione del rischio lo prevede, il tutto a copertura dell'intero periodo di audit.

1. La policy dice che cosa, quando e in quanto tempo. Il perimetro delle scansioni, il calendario, i trigger, una scadenza per ogni livello di gravità, e chi può approvare un'eccezione.
2. Ogni modifica viene scansionata. Codice, dipendenze, segreti e file di infrastruttura su ogni pull request, che l'abbia aperta una persona o un agente, dietro un gate che rifiuta un finding critico.
3. Il calendario intercetta i nuovi advisory. Una scansione notturna o settimanale del branch principale e delle immagini che fai girare, per le vulnerabilità pubblicate dopo che il codice è stato scritto.
4. Un finding, una registrazione. Unita fra gli strumenti, su una sola scala di gravità, con un responsabile, una scadenza, uno stato e la sua storia.
5. Le eccezioni sono messe per iscritto. Il perimetro, la motivazione, chi le approva e la data di scadenza.
6. Il penetration test è pianificato. Un perimetro ricavato dalla valutazione del rischio, il report conservato, i finding gravi corretti e ricontrollati.
7. Il report copre il periodo. Un unico documento costruito dalle registrazioni, non un foglio di calcolo messo insieme la settimana prima che arrivi l'auditor.

Scansione su ogni modificaUna registrazione per findingResponsabile e scadenzaCorretto, o eccezione approvataNel report del periodo

I punti 2, 5 e 7 sono quello che fa la piattaforma AppSec di CybeDefend. Su ogni repository analizza le debolezze del codice (SAST), le dipendenze (SCA), i segreti, l'infrastructure as code, i container e le pipeline CI/CD. Una policy di sicurezza scritta come codice blocca il merge su un finding critico e lascia passare con un avviso i rischi minori, e un'eccezione è limitata a un percorso, datata, motivata e approvata da una persona con nome e cognome, e ognuna lascia una riga di audit. I report di sicurezza mappano i finding sull'OWASP Top 10 e sulla CWE Top 25, per organizzazione, team o progetto, ed escono in PDF per l'auditor o in JSON per uno strumento GRC. Stiamo facendo lo stesso percorso anche noi: l'audit SOC 2 Type II di CybeDefend è in corso. Se stai preparando il tuo con un team che sviluppa con gli agenti, possiamo ripercorrerlo insieme a te.

Domande frequenti

Per il SOC 2 Type 2 serve il penetration test?

No. I report Type I e Type II usano gli stessi criteri, e nessuno di questi richiede un penetration test. Un Type II verifica che i tuoi controlli abbiano funzionato lungo un periodo, quindi se la tua policy prevede un penetration test annuale, l'auditor controlla che sia stato fatto all'interno del periodo e che i suoi finding siano stati gestiti.

Ogni quanto va fatto il penetration test per SOC 2?

I criteri non fissano un intervallo. Lo fissano la tua valutazione del rischio e la tua policy, e l'auditor verifica che tu abbia rispettato quello che hai scritto. Un cambiamento importante in ciò che il tuo sistema espone, come una nuova API pubblica o un nuovo prodotto, è un buon motivo per rifare il test prima della data prevista.

Per SOC 2 basta una scansione delle vulnerabilità?

Per il CC7.1, un programma di scansione è proprio quello che gli auditor si aspettano di vedere, con le registrazioni di come è stato gestito ogni finding. Una scansione però non sostituisce la valutazione dei controlli prevista dal CC4.1, che può essere un penetration test, un audit interno o una certificazione indipendente.

SOC 2 obbliga a fare SAST o scansione del codice?

Nessun criterio nomina il SAST. Il point of focus del CC7.1 copre vulnerabilità ed errori di configurazione nel tuo ambiente, e il CC8.1 chiede che le modifiche al software siano testate e approvate prima di essere implementate. Se sviluppi software, scansionare il codice e le sue dipendenze a ogni modifica è il modo più semplice per dimostrare entrambe le cose.

Si possono usare scanner open source per SOC 2?

Sì. I criteri non nominano alcuno strumento, e l'auditor verifica che le scansioni siano state eseguite come dice la tua policy e che i finding siano stati gestiti. Gli scanner open source vanno bene se intorno a loro tieni la registrazione: le date, il commit scansionato, i finding uniti fra gli strumenti, i responsabili, le scadenze e gli esiti.

Cos'è il CC7.1 di SOC 2?

Il CC7.1 è il criterio comune (common criteria, da cui la sigla CC) dedicato a rilevamento e monitoraggio. Chiede a un'organizzazione di usare procedure che identifichino le modifiche di configurazione che introducono nuove vulnerabilità e la sua esposizione alle vulnerabilità appena scoperte. Uno dei suoi points of focus è l'esecuzione di scansioni delle vulnerabilità periodiche e dopo le modifiche significative.

Cos'è il CC4.1 di SOC 2?

Il CC4.1 è il criterio comune sulle attività di monitoraggio. Chiede a un'organizzazione di condurre valutazioni continue o separate per confermare che le componenti del controllo interno siano presenti e funzionanti. Il suo point of focus cita il penetration test, le certificazioni indipendenti come quelle ISO e l'audit interno come esempi di queste valutazioni.

Che cosa cambia con i nuovi criteri SOC 2 proposti per il 2027?

Il 28 ottobre 2026 l'AICPA ha pubblicato un exposure draft che ristruttura parti dei criteri e aggiunge points of focus sull'AI, fra cui la governance dell'AI, la manipolazione dei prompt, l'avvelenamento dei dati e la trasparenza degli output generati dall'AI. I commenti si chiudono il 15 gennaio 2027. Se approvati, i criteri diventerebbero obbligatori per gli incarichi che iniziano a partire dal 31 dicembre 2027, con adozione anticipata consentita.