Verifica della conformità delle licenze tramite analisi delle dipendenze

La richiesta di due diligence per una fusione o acquisizione arriva di martedì mattina: un report completo sulla conformità delle licenze open source per tutto il software, da consegnare entro venerdì. Il team legale ha tre giorni per redigere un inventario di ogni componente open source presente nell'intero codice sorgente del prodotto, di ogni licenza applicabile e di ogni obbligo da adempiere prima della revisione legale da parte dell'acquirente. Per le organizzazioni che considerano la conformità delle licenze come una verifica manuale periodica, quel martedì mattina segna l'inizio di una delle simulazioni di emergenza più costose nel settore del software aziendale. Per le organizzazioni dotate di un'infrastruttura matura per l'analisi delle dipendenze, tutto inizia con l'esecuzione di un report.

Il software viene per lo più assemblato, non scritto. Il rapporto Black Duck 2026 OSSRA ha rilevato che il 98% dei codebase commerciali contiene componenti open source, l'87% presenta almeno una vulnerabilità nota e il numero medio di vulnerabilità per codebase è più che raddoppiato di anno in anno. L'audit di conformità delle licenze è la disciplina che risponde a una domanda diversa ma correlata: non solo quali componenti contengono vulnerabilità, ma anche quali componenti impongono obblighi legali su come il software può essere distribuito, modificato o commercializzato. Una dipendenza GPL-2.0 non rilevata in un prodotto commerciale proprietario non è un incidente di sicurezza. Si tratta di una violazione della licenza che può richiedere la divulgazione del codice sorgente, un accordo legale o il ritiro del prodotto.

Il fondamento dell'audit di conformità delle licenze è l'analisi delle dipendenze, ovvero l'identificazione sistematica di ogni componente software da cui una codebase dipende direttamente o indirettamente, con la completa attribuzione della licenza che regola ciascun componente. L'analisi delle dipendenze non è una semplice scansione del manifesto del pacchetto. Si tratta di un esame strutturale completo di ciò che il software include effettivamente in fase di compilazione ed esecuzione, indipendentemente dal fatto che tali inclusioni siano dichiarate, transitive, fornite da terze parti o implicite.

Perché l'analisi della dipendenza è il fondamento

La conformità delle licenze è un problema di dipendenze prima ancora di essere un problema legale. Non è possibile valutare gli obblighi di licenza di un prodotto software senza prima conoscerne la composizione, ogni componente, ogni libreria, ogni frammento di codice copiato. L'analisi delle licenze è una fase successiva all'inventario delle dipendenze. Se l'inventario è errato, l'analisi delle licenze si baserà su un quadro incompleto.

Tre domande a cui l'analisi delle dipendenze deve rispondere per garantire la conformità della licenza:

Quali componenti sono inclusi? Non solo le dipendenze dirette dichiarate in package.json or pom.xmlma ogni dipendenza transitiva che introducono, ogni libreria di terze parti copiata nell'albero dei sorgenti, ogni componente collegato staticamente compilato nel binario e ogni modulo caricato dinamicamente chiamato in fase di esecuzione. Un buon motore SCA confronta questi componenti con database di vulnerabilità come NVD, controlla i metadati della licenza e segnala exploit noti o rischi legali prima che abbiano un impatto sulla pipeline di distribuzione. Lo stesso motore deve anche essere accurato a livello di inventario, ovvero a livello di contenuto effettivo del software, prima che l'analisi della licenza possa essere considerata affidabile.

Da quali licenze sono regolati? Un componente può avere una singola licenza dichiarata, una doppia licenza con opzioni, più licenze applicate a file diversi o una licenza che è cambiata tra le varie versioni. Il motore di rilevamento delle licenze di FOSSA dichiara un'accuratezza del 99.8%, un dato importante quando il team legale deve verificare gli obblighi open source insieme all'inventario di sicurezza. L'identificazione della licenza a livello di componente è necessaria ma non sufficiente; è necessaria l'identificazione a livello di file o snippet per i componenti in cui file diversi hanno licenze diverse.

Quali obblighi impongono queste licenze? Una licenza permissiva (MIT, Apache-2.0) impone requisiti di attribuzione. Una licenza copyleft debole (LGPL) impone obblighi diversi a seconda che il componente sia collegato dinamicamente o staticamente. Una licenza copyleft forte (GPL-2.0, GPL-3.0) può richiedere la distribuzione del codice sorgente dell'intera opera combinata. Comprendere gli obblighi richiede la comprensione dei termini della licenza, non solo dell'identificativo della licenza.

I quattro tipi di dipendenze che creano rischi legati alla licenza

Non tutte le dipendenze sono ugualmente visibili o gestite allo stesso modo dagli strumenti esistenti. L'esposizione delle licenze deriva da quattro tipologie di dipendenza distinte, ognuna delle quali richiede metodi di individuazione differenti:

1. Dipendenze del gestore di pacchetti (dichiarate e transitive)

Lo strato più visibile: le dipendenze dichiarate nei file manifest (package.json, pom.xml, requirements.txt, go.mod, Cargo.toml) e le dipendenze transitive che risolvono in fase di compilazione. Le dipendenze del gestore di pacchetti sono la categoria meglio coperta; gli strumenti SCA analizzano manifest, file di blocco e artefatti di compilazione per enumerarle.

La distinzione fondamentale è tra dipendenza diretta e transitiva. Una dipendenza diretta è quella scelta dallo sviluppatore. Una dipendenza transitiva è quella richiesta dalla dipendenza diretta. Uno sviluppatore che aggiunge una singola dipendenza diretta react-data-grid L'aggiunta di un pacchetto a un progetto Node.js può includere decine di dipendenze transitive, ognuna con la propria licenza. Lo sviluppatore non ha scelto queste licenze, che sono comunque presenti nell'albero delle dipendenze.

json

// package.json: 1 direct dependency declared
{
  "dependencies": {
    "react-data-grid": "^7.0.0"
  }
}

// npm lockfile resolves to 47 transitive dependencies, including:
// - react@18.2.0 (MIT)
// - clsx@1.2.1 (MIT)
// - scheduler@0.23.0 (MIT)
// - tslib@2.6.0 (0BSD)
// - ...43 more, each with its own license
// The developer declared 1 license obligation; they shipped 47.

La trappola della licenza transitiva: il rischio legato alla licenza non risiede in ciò che hai dichiarato, bensì in ciò che hanno dichiarato le tue dipendenze e le dipendenze di queste ultime. Un albero di dipendenze dirette pulito, con licenze permissive, può nascondere una dipendenza transitiva con licenza GPL, profonda tre livelli, che impone obblighi di copyleft all'intera distribuzione.

2. Codice sorgente fornito e copiato

Il codice sorgente di progetti esterni è stato copiato direttamente nel repository, una pratica comune nei progetti C/C++, nei progetti Go senza moduli e nelle codebase legacy. Il codice di terze parti non compare nei manifest dei gestori di pacchetti perché è stato aggiunto tramite copia-incolla anziché tramite un gestore di dipendenze.

La scansione a livello di snippet di SCANOSS va ben oltre il rilevamento basato sul manifest, confrontando i frammenti di codice sorgente con oltre 100 milioni di file open source presenti nell'OSSKB. La scansione a livello di snippet è necessaria per identificare il codice di terze parti e le funzioni copiate, approcci che non dichiarano alcuna dipendenza nel manifest ma comportano obblighi di licenza completi come se il componente fosse stato incluso esplicitamente.

Una funzione di utilità di terze parti copiata da una risposta di Stack Overflow, originariamente presente in codice con licenza GPL, è soggetta agli stessi obblighi di copyleft di una dipendenza GPL diretta, ma non compare da nessuna parte nel manifesto del pacchetto, nel file di blocco o in qualsiasi scansione automatizzata che legga solo le dipendenze dichiarate.

3. Librerie collegate staticamente

Le librerie vengono compilate direttamente nel binario dell'applicazione in fase di compilazione. A differenza delle librerie collegate dinamicamente che esistono come file separati in fase di esecuzione, le librerie collegate staticamente sono incorporate nell'eseguibile. Non sono visibili nei manifest del gestore di pacchetti, ma appaiono nelle configurazioni di compilazione.Makefile, CMakeLists.txt, script del linker) e nel binario compilato stesso.

Nello specifico, per le librerie con licenza LGPL, la distinzione tra collegamento statico e dinamico determina gli obblighi di licenza. La LGPL consente il collegamento dinamico senza propagazione del copyleft; il collegamento statico può comportare l'applicazione di obblighi copyleft all'opera combinata. È necessario uno strumento di analisi binaria che esamini l'artefatto compilato, anziché solo il manifesto del codice sorgente, per identificare i componenti collegati staticamente e le relative licenze.

4. Dipendenze caricate in fase di esecuzione

Le librerie vengono caricate dinamicamente in fase di esecuzione tramite architetture a plugin, binding dinamico o integrazioni con motori di scripting. Queste dipendenze potrebbero non essere risolvibili solo tramite l'analisi del codice sorgente, poiché dipendono dall'ambiente di runtime, dalla configurazione e dal percorso di esecuzione. I driver di database caricati tramite reflection, i plugin del parser scoperti tramite meccanismi di caricamento dei servizi e le estensioni di scripting caricate da percorsi del filesystem all'avvio sono tutte dipendenze di runtime con potenziali implicazioni di licenza.

Categorie di rischio delle licenze e relativi obblighi

Le licenze open source si collocano lungo uno spettro che va da permissive a restrittive. Comprendere la posizione di ciascuna licenza su questo spettro permette di determinare gli obblighi di conformità che essa comporta:

Licenze permissive (MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC)

Obbligo: Attribuzione, inclusione del testo della licenza e dell'avviso di copyright nelle distribuzioni. La divulgazione del codice sorgente non è richiesta. L'uso commerciale è consentito senza restrizioni. L'integrazione in prodotti proprietari è consentita.

Livello di rischio per il software commerciale: basso. L'attribuzione è facile da effettuare automaticamente.

Licenze copyleft deboli (LGPL-2.0, LGPL-2.1, LGPL-3.0, MPL-2.0, EUPL-1.2)

Obbligo: l'attribuzione e le modifiche al componente concesso in licenza devono essere condivise. Nello specifico, per la licenza LGPL: il collegamento dinamico generalmente soddisfa i requisiti della licenza senza attivare il copyleft sul codice chiamante; il collegamento statico potrebbe non farlo.

Livello di rischio per il software commerciale: Medio. Dipende dal metodo di collegamento. Il collegamento dinamico è generalmente sicuro; il collegamento statico richiede un'attenta valutazione legale.

Licenze copyleft forti (GPL-2.0, GPL-3.0, AGPL-3.0)

Obbligo: l'attribuzione e l'intera opera combinata, che include la componente GPL, devono essere rese disponibili secondo i termini della GPL (divulgazione del codice sorgente). La AGPL estende questo obbligo al software accessibile tramite rete.

Livello di rischio per il software commerciale: Alto. Un componente con licenza GPL collegato staticamente a un prodotto commerciale proprietario o derivato da esso potrebbe richiedere la divulgazione del codice sorgente proprietario. Questo è il rischio di licenza che genera i maggiori risarcimenti legali.

Copyleft di rete (AGPL-3.0)

Obbligo: Tutti gli obblighi della GPL-3.0, più: gli utenti che interagiscono con il software tramite una rete sono considerati come se ricevessero il software, il che fa scattare l'obbligo di divulgazione del codice sorgente anche per i prodotti SaaS che non distribuiscono mai file binari.

Livello di rischio per i prodotti SaaS: Molto alto. La licenza AGPL è specificamente progettata per colmare la "lacuna" della GPL relativa ai prodotti SaaS. Un prodotto SaaS commerciale che include un componente AGPL deve rivelarne la fonte a qualsiasi utente che interagisca con esso tramite una rete.

Licenze proprietarie e commerciali

Obbligo: definito dal contratto di licenza, varia da "nessuna ridistribuzione" a "royalties per unità" fino a "licenza per postazione aziendale". Questi non sono open source, ma compaiono negli alberi delle dipendenze quando vengono utilizzati componenti commerciali.

Livello di rischio: variabile a seconda dei termini. Spesso emerge durante la due diligence in operazioni di fusione e acquisizione, quando vengono elencati gli obblighi relativi alle commissioni di licenza dei prodotti acquisiti.

Compatibilità delle licenze: la matrice che conta

Quando si combinano componenti con licenze diverse in un unico prodotto software, le licenze devono essere compatibili. Le combinazioni di licenze incompatibili creano un rischio legale che non può essere risolto con la sola attribuzione; la combinazione stessa potrebbe violare una o entrambe le licenze.

Combinato con	CON	Apache-2.0	LGPL-2.1	GPL-2.0	GPL-3.0	PLFA-3.0
CON	Compatibile	Compatibile	Compatibile	Compatibile	Compatibile	Compatibile
Apache-2.0	Compatibile	Compatibile	Compatibile	Incompatibile	Compatibile	Compatibile
LGPL-2.1	Compatibile	Compatibile	Compatibile	Compatibile	Incompatibile	Incompatibile
GPL-2.0	Compatibile	Incompatibile	Compatibile	Compatibile	Incompatibile	Incompatibile
GPL-3.0	Compatibile	Compatibile	Incompatibile	Incompatibile	Compatibile	Compatibile
Proprietary	Compatibile	Compatibile	Attenzione	Incompatibile	Incompatibile	Incompatibile

La più grave incompatibilità per il software commerciale è quella tra Apache-2.0 e GPL-2.0. Una libreria con licenza Apache-2.0 non può essere combinata con un componente con licenza GPL-2.0 nella stessa opera. Poiché molti componenti open source fondamentali (moduli del kernel Linux, alcune librerie Java meno recenti) sono rilasciati sotto licenza GPL-2.0 anziché GPL-3.0, questa incompatibilità crea un reale rischio di non conformità in presenza di alberi di dipendenze miste.

La riga AGPL-3.0 è la più restrittiva per il SaaS: praticamente nulla si combina senza problemi con AGPL-3.0 in un prodotto commerciale senza far scattare l'obbligo di copyleft di rete.

Applicazione delle politiche di licenza in CI/CD

La conformità delle licenze che si basa su audit periodici fallisce nel momento stesso dell'introduzione: la dipendenza GPL aggiunta da qualcuno nello sprint precedente è in produzione da tre settimane prima che l'audit trimestrale la rilevi. L'applicazione continua al momento della fusione del codice è l'unico approccio che impedisce alle dipendenze non conformi di entrare nella codebase.

YAML

# GitHub Actions: license compliance gate on every PR
name: License Compliance Check

on:
  pull_request:

jobs:
  license-audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install license checker
        run: npm install -g license-checker fossa-cli

      - name: Scan dependency licenses
        run: |
          license-checker --summary --excludePrivatePackages \
            --out license-report.json

      - name: Enforce license policy
        run: |
          # Block GPL-2.0, GPL-3.0, AGPL-3.0, SSPL in commercial product
          FORBIDDEN=$(license-checker --failOn \
            "GPL-2.0;GPL-3.0;AGPL-3.0;SSPL" \
            --excludePrivatePackages 2>&1 || true)

          if echo "$FORBIDDEN" | grep -q "FAIL"; then
            echo "Forbidden license detected in dependencies"
            echo "$FORBIDDEN"
            exit 1
          fi

      - name: Generate SBOM artifact
        run: |
          # Generate CycloneDX SBOM for audit trail
          npx @cyclonedx/cyclonedx-npm \
            --output-file sbom-$(date +%Y%m%d).json

      - name: Upload SBOM as artifact
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom-*.json

Attenzione: la politica sulle licenze è specifica per ogni organizzazione. L'elenco delle licenze proibite nell'esempio precedente riflette una politica commerciale comune, ma il team legale della vostra organizzazione deve definire quali licenze sono consentite, segnalate per la revisione e proibite per il vostro specifico tipo di prodotto, modello di distribuzione e accordi con i clienti. Una libreria consentita in uno strumento interno potrebbe essere proibita in un prodotto distribuito ai clienti.

Standard di generazione e formato SBOM

La distinta base del software (SBOM, Software Bill of Materials) è l'artefatto strutturato che rende la conformità delle licenze verificabile, condivisibile e controllabile automaticamente. I team addetti alla conformità possono confermare gli obblighi di licenza senza audit manuali quando la SBOM fornisce questi dati. Due formati dominano il mercato:

CycloneDX , sviluppato da OWASP, è progettato per casi d'uso relativi alla sicurezza e alla catena di fornitura. Supporta componenti, servizi, vulnerabilità (VEX), formule e distinte base basate su modelli di machine learning. È il formato preferito per le distinte base incentrate sulla sicurezza e il formato richiesto dalla maggior parte delle moderne integrazioni con strumenti SCA.

SPDX, gestito dalla Linux Foundation, lo standard ISO/IEC (ISO 5962:2021). Richiesto da alcuni standard di appalto governativi, inclusi aspetti dell'EO 14028. Più focalizzato sulla conformità delle licenze che sulla sicurezza, con un linguaggio di espressione delle licenze più ricco (le espressioni SPDX possono catturare scenari complessi multi-licenza: GPL-2.0-only AND MIT OR Apache-2.0).

L'Ordine Esecutivo 14028 impedisce già ai fornitori non certificati SBOM di partecipare agli appalti federali, l'Agenzia delle Entrate canadese (CRA) inizierà a far rispettare l'obbligo di segnalazione delle vulnerabilità a settembre 2026 e lo standard PCI DSS 4.0 è già nelle mani dei revisori. O si forniscono certificati SBOM o si perdono i contratti.

Per i prodotti software aziendali, la produzione di entrambi i formati comporta costi minimi, a parte la generazione a partire dalla stessa analisi delle dipendenze. Il pubblico di riferimento è diverso per ciascun formato: i team di sicurezza e i flussi di lavoro di gestione delle vulnerabilità utilizzano CycloneDX; i team legali, gli acquisti e i flussi di lavoro di conformità normativa in genere preferiscono SPDX.

Il problema del codice sorgente legacy: nessun gestore di pacchetti, nessun manifesto

Gli strumenti di analisi delle dipendenze descritti in precedenza, ovvero gli scanner SCA, i parser di file di blocco e i generatori di SBOM, si basano sul presupposto che le dipendenze software siano gestite tramite gestori di pacchetti e dichiarate nei file manifest. Questo presupposto è valido per i moderni progetti Java, JavaScript, Python, Go e Rust. Non è invece valido per gli ambienti aziendali legacy basati su COBOL, JCL e piattaforme mainframe.

In un ambiente mainframe, la dipendenza da software di terze parti si manifesta in tre modi che gli strumenti SCA standard non sono in grado di rilevare:

Prodotti di smistamento e utilità su licenza. I flussi di lavoro JCL chiamano programmi di utilità, prodotti di ordinamento (DFSORT, SyncSort/Syncsort ora noto come Precisely, CA Sort), strumenti di creazione di report (SAS, EASYTRIEVE) e strumenti di conversione dati, che sono software commerciali con licenza e con i propri termini di licenza, contratti di manutenzione e requisiti di conformità. Questi appaiono in JCL come PGM=SORT, PGM=IEBGENER, PGM=ICETOOL, nomi dei programmi, non identificatori di pacchetto. Nessuno strumento SCA che legge package.json or pom.xml li troveranno.

Copybook COBOL forniti dal fornitore. I fornitori di software di terze parti forniscono copybook COBOL che sono software con licenza. Un fornitore di software fintech che fornisce programmi COBOL per l'elaborazione dei pagamenti può fornire copybook che definiscono le proprie strutture dati proprietarie. Ogni programma COBOL che include tali copybook utilizza software con licenza. Gli obblighi di licenza sono reali; la voce nel gestore dei pacchetti non esiste.

Algoritmi incorporati da fonti con licenza. Gli istituti finanziari che utilizzano sistemi COBOL potrebbero aver incorporato algoritmi con licenza, routine di calcolo attuariale, implementazioni crittografiche e librerie di analisi numerica direttamente nel codice sorgente COBOL. Questi potrebbero provenire da fonti con licenza compilate nel codice sorgente e non essere identificabili tramite i gestori di pacchetti.

Per questi componenti, il metodo di individuazione consiste nell'analisi del codice sorgente: tracciamento delle istruzioni CALL per identificare i programmi chiamati, esame delle istruzioni COPY per identificare i membri inclusi e confronto dei nomi dei programmi con un registro di componenti di terze parti noti. L'output alimenta lo stesso flusso di lavoro di conformità delle licenze, ma richiede uno strumento in grado di comprendere la semantica COBOL e JCL, non solo i moderni formati dei manifesti dei pacchetti.

Creazione del pacchetto di conformità pronto per l'audit.

Quando l'ufficio legale, l'ufficio di conformità o un revisore esterno richiedono prove di conformità della licenza, un rapporto di scansione è necessario ma non sufficiente. Il pacchetto di conformità pronto per la verifica contiene:

• Inventario completo delle persone a carico, ogni componente, versione e licenza, comprese le dipendenze transitive, organizzate per prodotto e versione
• matrice degli obblighi di licenza, per ogni categoria di licenza presente, gli obblighi specifici (attribuzione, divulgazione della fonte, avviso di modifica) e le modalità di adempimento di ciascuno
• File delle note di attribuzioneSono state compilate le note legali per tutti i componenti che richiedono l'attribuzione, nel formato richiesto da ciascuna licenza (file NOTICE per Apache-2.0, file LICENSE per MIT, ecc.).
• Analisi di incompatibilitàdocumentazione che attesti l'assenza di combinazioni di licenze incompatibili nel prodotto combinato, con giustificazione legale per eventuali casi limite
• SBOMartifact, file CycloneDX o SPDX corrente, firmato e con timestamp, che copre tutti i componenti in ambito
• Documentazione della politicala politica scritta dell'organizzazione in materia di licenze open source, incluso il processo di approvazione per le nuove licenze
• Registri di approvazione, per qualsiasi licenza che richieda una revisione legale prima dell'inclusione, l'approvazione documentata e la giustificazione aziendale
• Storia degli interventi di bonificadocumentazione di eventuali violazioni precedentemente identificate e delle azioni intraprese per risolverle

Nello specifico, per la due diligence in ambito M&A: gli acquirenti richiedono sempre più spesso questo pacchetto come parte della due diligence tecnica. Un pacchetto di conformità impeccabile, senza violazioni irrisolte, accelera il processo di due diligence. Un pacchetto che rivela violazioni irrisolte della licenza GPL in un prodotto proprietario in genere comporta un adeguamento del prezzo, requisiti di deposito a garanzia o interventi correttivi come condizione per la chiusura dell'operazione, tutte opzioni più costose rispetto al programma di conformità che le avrebbe prevenute.

Come SMART TS XL Garantisce la conformità delle licenze nei codebase aziendali

SMART TS XL'S mappatura delle dipendenze delle applicazioni Fornisce il livello di analisi delle dipendenze strutturali per le codebase aziendali, in particolare negli ambienti legacy dove gli strumenti SCA standard raggiungono i loro limiti.

Negli ambienti mainframe, la mappa delle dipendenze identifica ogni programma chiamato da ogni altro programma (mettendo in evidenza le chiamate di utilità di terze parti incorporate in JCL e COBOL), ogni copybook incluso da ogni programma (mettendo in evidenza le dipendenze dei copybook forniti dal fornitore) e ogni dataset a cui accede ogni programma (mettendo in evidenza le dipendenze a livello di dati da prodotti di database con licenza). Questa analisi produce l'inventario dei componenti che costituisce il prerequisito per la verifica della conformità delle licenze in ambienti in cui non è presente un gestore di pacchetti.

La funzionalità di analisi statica del codice identifica modelli di codice associati a specifici componenti di terze parti: firme di chiamate API proprietarie, convenzioni di struttura dati specifiche del fornitore e implementazioni di algoritmi con licenza incorporate nel codice sorgente COBOL personalizzato. Questi risultati integrano l'inventario basato sul manifest con le dipendenze a livello di codice che la scansione del manifest non è in grado di rilevare.

La funzionalità di analisi d'impatto rende attuabili le modifiche alle politiche di licenza: se la licenza di un componente cambia, se una dipendenza passa da MIT ad AGPL-3.0 o se un fornitore modifica i propri termini, l'analisi d'impatto identifica ogni programma nel portfolio che dipende da quel componente, direttamente o indirettamente. Questo trasforma un evento di modifica della licenza da un rischio sconosciuto in un ambito di intervento definito.

La funzionalità di ricerca aziendale rende l'inventario delle dipendenze interrogabile a fini di conformità: trova ogni programma che richiama una specifica utility, ogni copybook che include un membro fornito da un fornitore specifico, ogni programma che dipende da un componente con licenza specifico, in pochi secondi, nell'intero portfolio legacy. Questa funzionalità di ricerca è lo strumento pratico per la richiesta di audit post-fusione e acquisizione del martedì mattina: una query anziché una revisione manuale.

Per le organizzazioni che creano una copertura SBOM completa che si estende sia ai sistemi moderni che a quelli legacy, SMART TS XL Fornisce l'inventario dei componenti legacy che i generatori SBOM standard non sono in grado di produrre, integrando strumenti come Syft, FOSSA e Dependency-Track per lo stack moderno.

La revisione contabile che non dovrebbe mai essere una sorpresa

La verifica della conformità delle licenze è una delle poche discipline regolamentari in cui la sanzione per la non conformità viene spesso scoperta non da un ente regolatore, bensì da un partner commerciale, un acquirente, il team legale di un cliente o un distributore che legge i termini della licenza e richiede prove di conformità. Il costo di tale scoperta può variare da un semplice imbarazzo a conseguenze esistenziali, a seconda della gravità della violazione e della fase della transazione.

Il programma di analisi delle dipendenze che impedisce che questa scoperta sia una sorpresa non è costoso rispetto al rischio che mitiga. Richiede la conoscenza di cosa contiene il software, ogni componente, ogni dipendenza transitiva, ogni frammento di codice fornito da terzi, ogni utility legacy, e la verifica continua, anziché periodica, di ciascuno di essi rispetto alla politica di licenza dell'organizzazione. Gli strumenti esistono. Gli standard (SBOM, SPDX, CycloneDX) esistono. Il mandato normativo (EO 14028, CRA, PCI-DSS 4.0) esiste. L'unico elemento mancante, per la maggior parte delle organizzazioni, è la disciplina di trattare l'analisi delle dipendenze come un'infrastruttura piuttosto che come un'attività di audit.

Il martedì mattina che inizia con un rapporto anziché con un'esercitazione antincendio è il martedì mattina reso possibile dall'infrastruttura di analisi delle dipendenze.