Come rivedere un inventario di terze parti prima della pubblicazione

Perché l'importazione ti dice solo cosa c'è, non se i metadati di licenza sono affidabili: i registri dei pacchetti etichettano male le licenze, i fornitori cambiano le condizioni, e le dipendenze transitive introducono copyleft che non ti aspettavi. Un file di inventario di terze parti è un input, non una pagina di conformità finita.

La portata è documentata, ed è esattamente l'insieme di casi che l'importazione automatica non può risolvere da sola.

Le barriere di revisione esistono perché tu non possa pubblicare un URL di conformità delle licenze che dichiara più di quanto il tuo team abbia verificato. Gli acquisti e i revisori trattano la pagina pubblica come la tua dichiarazione degli obblighi di licenza di terze parti.

Parti dagli artefatti legati alla build che rilasci: package-lock.json, pnpm-lock.yaml, yarn.lock, go.mod, Cargo.lock, pom.xml, Gemfile.lock, uno SBOM CycloneDX dalla CI, o esportazioni dal tuo strumento SBOM esistente. Contrassegna ogni riga come da rivedere finché qualcuno non conferma la licenza.

Circoscrivi l'importazione a un prodotto. Le aziende multi-prodotto hanno bisogno di pagine di conformità delle licenze separate, o sezioni chiaramente separate, per ogni prodotto rilasciato. Mescolare gli inventari crea errori di divulgazione.

• Importa lockfile o SBOM dal branch di release, non da main se diverge.
• Includi font, icone, SDK e asset incorporati richiesti dalla tua policy.
• Segnala i duplicati e unisci le voci che si riferiscono allo stesso componente.
• Registra la data di importazione e l'hash del file sorgente per l'audit trail.
• Non pubblicare automaticamente. Ogni voce parte non rivista.

Per ogni riga, conferma che l'identificatore di licenza corrisponda all'uso reale, non solo ai metadati di package.json. Leggi i fattori scatenanti del copyleft. Allega il testo completo della licenza. Documenta esplicitamente le esclusioni.

I revisori si concentrano su GPL, LGPL, AGPL, SDK proprietari e componenti con dati di licenza mancanti o in conflitto. Quelle righe bloccano la pubblicazione finché non vengono risolte.

• Fai corrispondere la licenza alla fonte: file LICENSE del repository, accordo con il fornitore, o identificatore SPDX confermato da un essere umano.
• Aggiungi il testo completo della licenza al registro prima di contrassegnarlo come approvato.
• Segnala copyleft, copyleft di rete (AGPL) e licenze personalizzate per la revisione del legale o dell'ingegneria senior.
• Risolvi i conflitti (il registro dice MIT, il repository dice Apache) prima di approvare.
• Documenta i componenti esclusi dal prodotto rilasciato e il perché.
• Richiedi un secondo approvatore per le licenze ad alto rischio se la tua policy ne definisce uno.

Pubblica solo quando le barriere sono superate: nessuna riga non rivista, testo completo della licenza allegato, ambito del prodotto chiaro, URL stabile. La pagina di conformità delle licenze pubblica è gli stessi dati delle tue esportazioni. Un unico inventario rivisto, output multipli.

Le pagine di divulgazione delle licenze di terze parti dovrebbero caricarsi senza autenticazione, elencare i componenti chiaramente, e includere il testo completo delle licenze che gli acquisti possono cercare e copiare. È questo che cercano le revisioni enterprise.

• Blocca la pubblicazione se un componente in ambito manca del testo di licenza approvato.
• Genera l'URL pubblico e verifica in incognito prima di condividere esternamente.
• Esporta pacchetti JSON, di attribuzione e di divulgazione dalla stessa istantanea approvata.
• Registra chi ha approvato la pubblicazione e a quale tag di release corrisponde.

La conformità delle licenze non è un'operazione da fare una volta sola. Nuove dipendenze, aggiornamenti di versione e cambi di licenza arrivano a ogni sprint. I controlli di deriva confrontano i lockfile o gli SBOM attuali con la tua ultima pubblicazione approvata e segnalano le differenze prima che i clienti se ne accorgano.

Quando l'inventario cambia, riesegui le barriere di revisione. Aggiorna la pagina di conformità delle licenze. Invia gli URL aggiornati agli acquisti solo quando la nuova pubblicazione è approvata, non quando l'importazione termina.

• Esegui controlli della pipeline o CI su pull request, tag o release.
• Segnala i nuovi pacchetti non rivisti prima della release, secondo la tua policy.
• Approva di nuovo i componenti copyleft quando il collegamento o il modello di distribuzione cambia.
• Mantieni un audit trail: eventi di importazione, revisione, pubblicazione, deriva.