SOC 2 · ISO 27001

Superare SOC 2 o ISO 27001 copre la divulgazione delle licenze?

No. Le certificazioni di sicurezza e la divulgazione delle licenze di terze parti rispondono a domande diverse, ed entrambe possono essere vere allo stesso tempo: puoi avere un certificato valido e dover comunque un registro delle licenze rivisto a livello di prodotto.

Ultimo aggiornamento: 2 luglio 2026

01A cosa punta questa pagina

I punti di fallimento trascurati

Questi emergono nella due diligence e negli audit: gli obblighi esistono, la prova manca, e l'artefatto che gli acquirenti si aspettano è assente.

Le licenze open source sono obblighi legali, non preferenze
MIT, Apache, GPL, LGPL e gli accordi SDK proprietari impongono condizioni: avviso, attribuzione, copyleft, regole di distribuzione. Non rispettarle è una violazione di licenza, non una lacuna stilistica. I programmi SOC 2 e ISO non fanno sparire quegli obblighi; chiedono se i tuoi controlli li colgono prima del rilascio.
ISO 27001: la proprietà intellettuale è esplicita
L'Allegato A 5.32 richiede procedure per rispettare i diritti di proprietà intellettuale, incluse le licenze software. I revisori si aspettano prove, non solo un PDF di policy. Non includere i testi di licenza richiesti dove le licenze lo impongono è sia una violazione della proprietà intellettuale sia un fallimento delle prove dell'ISMS quando i tuoi controlli dichiarano che il software di terze parti è gestito.
SOC 2: nessun controllo sulla pagina delle licenze, ma i revisori seguono le tracce
I Trust Services Criteria non menzionano "pubblica tutte le licenze su un sito web". I revisori tracciano comunque la conformità legale e la gestione dei cambiamenti. Le lacune sistemiche (avvisi mancanti, inventario non rivisto, nessun registro a livello di prodotto) emergono come carenze di controllo quando i campioni non corrispondono alla policy.
L'ambito della certificazione non è l'ambito del prodotto
Un certificato SOC 2 Type II o ISO copre il tuo sistema e il tuo periodo, non automaticamente ogni dipendenza in ogni SKU. Gli acquirenti fanno comunque domande specifiche per prodotto. La tua certificazione aiuta; non sostituisce la divulgazione delle licenze di terze parti per il prodotto oggetto del contratto.
I pacchetti di prove diventano obsoleti tra un audit e l'altro
I team inviano alla sorveglianza ISO lo stesso foglio di calcolo OSS che avevano inviato l'anno scorso, mentre l'ingegneria ha rilasciato dodici release. I revisori di sorveglianza campionano i sistemi live. Il disallineamento tra prove e produzione è un classico rilievo maggiore, e lo stesso disallineamento affossa i rinnovi degli acquisti.
La scansione di sicurezza non è revisione delle licenze
Gli scanner di vulnerabilità e gli strumenti SBOM identificano i componenti e talvolta i campi di licenza. Non allegano il testo completo delle licenze, non approvano il rischio di copyleft, e non pubblicano una divulgazione pronta per gli acquirenti. Equiparare l'output degli strumenti AppSec alla conformità delle licenze crea falsa sicurezza sia nelle prove SOC sia nelle risposte alle RFP.
Le sorprese di copyleft danneggiano anche le organizzazioni certificate
GPL o AGPL in un prodotto rilasciato senza offerta di codice sorgente o revisione di conformità è un problema legale e di audit indipendentemente dalla certificazione ISO 27001. La scoperta durante la due diligence dell'acquirente, non durante la revisione interna, è la strada costosa.
Gli acquirenti vogliono una prova accanto al tuo rapporto
I clienti enterprise richiedono il tuo rapporto SOC e un registro delle licenze di terze parti per il prodotto: inventario, testo completo, processo di manutenzione. Il trust center copre la postura di sicurezza; la divulgazione delle licenze copre gli obblighi di proprietà intellettuale nella codebase. Entrambi compaiono nelle revisioni dei fornitori mature.

SOC 2 e ISO 27001 dimostrano che gestisci un sistema di sicurezza e gestione: controllo degli accessi, gestione dei cambiamenti, trattamento del rischio, supervisione dei fornitori. I revisori esaminano la progettazione e l'efficacia operativa dei controlli. Nessuna delle due certificazioni inventaria per impostazione predefinita ogni obbligo di licenza open source in ogni prodotto rilasciato.

Gli acquirenti trattano la certificazione come un requisito minimo, poi chiedono separatamente la divulgazione delle licenze di terze parti (testo completo, attribuzione, inventario circoscritto al prodotto). Superare SOC 2 non risponde a "quali componenti GPL ci sono nella build che abbiamo concesso in licenza".

Cosa richiede davvero ISO 27001 sulle licenze open source?

La ISO/IEC 27001:2022 richiede di gestire procedure che garantiscano la conformità ai diritti di proprietà intellettuale, incluse le condizioni delle licenze software, secondo il controllo 5.32 dell'Allegato A. Non prescrive una pagina delle licenze pubblica, ma un revisore può chiedere la prova che le condizioni di licenza di terze parti in quello che rilasci siano effettivamente rispettate.

Un documento di controllo che dice "rispettiamo le licenze OSS" senza prove (inventario rivisto, testo completo, allineamento alla release) è un rilievo in attesa di accadere. Specialmente quando il test a campione trova pacchetti in produzione non presenti in alcun elenco.

Policy per le licenze accettabili e i processi di approvazione.
Prova che i prodotti rilasciati rispettano le condizioni delle licenze di terze parti.
Registri di revisione, non solo l'output di una scansione di rilevamento.
Allineamento tra quanto dichiarato dall'ISMS e quanto rilasciato dall'ingegneria.
Gestione dei cambi di licenza quando le dipendenze si aggiornano.

Cosa cercano in pratica i revisori SOC 2 sulla conformità delle licenze?

I revisori SOC 2 non richiedono una pagina delle licenze pubblica; verificano se i tuoi controlli sui Trust Services Criteria dell'AICPA per la conformità legale, la gestione dei fornitori e il controllo dei cambiamenti colgono davvero gli obblighi di licenza di terze parti. Un'igiene OSS trascurata emerge lì come prova debole rispetto a criteri che dichiari già di gestire.

I revisori campionano i sistemi. Chiedono come sai che il software di terze parti è concesso in licenza correttamente. "Eseguiamo npm audit" non è una risposta. Non lo è nemmeno un badge di certificazione sul tuo sito senza un inventario a livello di prodotto.

Controllo	Cosa si aspettano i revisori	Prova che lo soddisfa
ISO 27001 A 5.32	Procedure che garantiscono la conformità su IP e licenze software	Inventario rivisto con testo completo delle licenze per ogni prodotto rilasciato
SOC 2 CC2.2	Governance e supervisione degli obblighi di conformità	Registri di revisione che mostrano chi ha approvato quali componenti, e quando
SOC 2 CC8.1	Le modifiche alle dipendenze passano attraverso la gestione dei cambiamenti	Registri di deriva che collegano le modifiche al lockfile alla nuova revisione
SOC 2 CC9.2	Il rischio del software di terze parti e dei fornitori è gestito	Registro di divulgazione circoscritto al prodotto, aggiornato alla release

I rilievi emergono quando una policy esiste ma la prova operativa no.

Perché le certificazioni e la due diligence degli acquirenti divergono

L'ambito della certificazione è l'ambiente di controllo: spesso un trust center, un periodo, un confine di sistema. L'ambito della due diligence dell'acquirente è il prodotto che acquista (questo SKU, questa release, questi obblighi oggi).

Il tuo rapporto SOC 2 copre come gestisci il cambiamento. Il loro team legale chiede il testo della licenza MIT per libfoo 2.4.1 nell'installer che distribuiscono. Domande diverse; entrambe richiedono risposte oneste.

Perché l'inventario diventa obsoleto nelle organizzazioni certificate?

L'inventario diventa obsoleto perché la certificazione è periodica mentre le dipendenze cambiano continuamente. Il report Open Source Security and Risk Analysis di Black Duck ha rilevato codice open source nel 96% delle codebase controllate, e che la maggior parte conteneva componenti con conflitti di licenza o senza licenza identificabile, quindi un unico pacchetto di prove annuale non può tenere traccia di quello che ogni release rilascia davvero.

Le aziende certificate fanno il merge di aggiornamenti alle dipendenze tra i cicli di audit. Gli sviluppatori aggiungono pacchetti senza aggiornare il foglio di calcolo del pacchetto di prove ISO dell'anno scorso. Il certificato è valido; l'inventario è obsoleto.

La conformità operativa delle licenze significa reimportare a ogni release, rivedere, ripubblicare. Lo stesso ciclo di manutenzione richiesto dal CRA e dagli acquisti, dentro un ISMS che dichiara già che gestisci il rischio di terze parti.

Prove accettate sia dai revisori sia dagli acquirenti

Inventario di terze parti rivisto legato ai tag di release. Testo completo della licenza archiviato con ogni componente approvato. Istantanea di pubblicazione o esportazione con data e approvatore. Rilevamento della deriva quando i lockfile cambiano. Divulgazione pubblica o rivolta ai clienti quando i contratti lo richiedono.

Il formato varia (URL, esportazione PDF, pacchetto JSON). La prova è il registro rivisto e il processo, non il tipo di file.

Importa da lockfile o SBOM a ogni release.
Revisione umana prima dell'approvazione, specialmente per il copyleft.
Audit trail: chi ha approvato cosa e quando.
Esportazioni allegate alle prove ISO o alle richieste dei revisori SOC.
Riesegui a ogni cambio di dipendenza, non solo annualmente.

Schemi di fallimento comuni in audit e trattative

Policy senza inventario. Inventario senza testo completo delle licenze. Testo completo raccolto una volta e mai aggiornato. Scansione di sicurezza scambiata per revisione delle licenze. Trust center che menziona privacy e sicurezza ma tace sull'OSS. GPL in produzione scoperta dalla scansione dell'acquirente, non dalla tua.

Ognuno di questi schemi crea rilievi ISO, eccezioni SOC o ritardi nelle trattative. La soluzione è un'infrastruttura operativa per gli obblighi di licenza, parallela ai (non sostituita dai) programmi di certificazione.

Come i team mappano i controlli sul lavoro delle licenze

Mappa il controllo 5.32 e i criteri di gestione dei cambiamenti SOC su passaggi concreti: importa, rivedi, pubblica, controlla la deriva. Nomina i responsabili in ingegneria e conformità. Allega le esportazioni di divulgazione alle cartelle di prove dell'ISMS. Campiona i prodotti durante l'audit interno nello stesso modo in cui lo faranno i revisori esterni.

La certificazione dimostra la maturità del processo. I registri delle licenze a livello di prodotto dimostrano che rispetti gli obblighi nel software che vendi. Le prove che acquirenti e test a campione ISO si aspettano sempre più insieme.

Fonti

Come SourceTrust supporta le prove a sostegno della certificazione

Le certificazioni dimostrano che hai un sistema di gestione. I registri delle licenze a livello di prodotto dimostrano cosa è stato rilasciato: rivisto, con testo completo, aggiornato quando le dipendenze cambiano.

SourceTrust importa file di pacchetto e SBOM, richiede la revisione prima della pubblicazione, e produce un registro di divulgazione mantenuto per ogni prodotto più esportazioni per le cartelle di prove ISO e i questionari degli acquirenti. I controlli di deriva allineano i registri delle licenze con gli stessi cambi di dipendenza che i tuoi controlli di gestione dei cambiamenti già tracciano per SOC 2.

Scopri come funziona la piattaforma

Importa da repository, manifest e SBOM. Ogni riga è una licenza da soddisfare
Barriere di revisione e pubblicazione. I revisori possono campionare le prove rispetto alla produzione
Registro di divulgazione per ogni prodotto. Quello che gli acquirenti chiedono oltre al rapporto SOC
Avvisi di deriva quando le dipendenze o le licenze cambiano tra un ciclo di audit e l'altro

SourceTrust è infrastruttura di conformità, non consulenza legale e non un sostituto della tua società di audit ISO o SOC. Ti aiuta a mettere in pratica gli obblighi di licenza; il tuo legale e i tuoi revisori restano l'autorità sulla progettazione dei tuoi controlli.