Cosa questa scansione può e non può dirti

Risponde a una domanda circoscritta: questo URL pubblico mostra segni evidenti di divulgazione delle licenze di terze parti, o lacune evidenti? Aiuta i team che non hanno mai controllato il proprio sito di marketing a trovare link mancanti, redirect verso la homepage o pagine delle licenze vuote.

Per i fornitori SaaS, il sito di marketing è spesso il primo posto in cui gli acquirenti guardano prima di chiedere la vera pagina di conformità delle licenze del prodotto rilasciato.

• Risposte HTTP sui percorsi comuni di licenza e avviso (/license, /legal, /oss, ecc.).
• Se quelle pagine contengono un testo di licenza o avviso di terze parti plausibile, non gusci vuoti.
• Alcuni URL di script di terze parti visibili nell'HTML della homepage.
• Redirect evidenti che inviano i percorsi di licenza verso pagine non correlate.
• Link mancanti: nessun footer di licenza, nessuna menzione di open source, nessun URL di conformità nella site map.

Non può vedere quello che non è sulla pagina pubblica: la conformità delle licenze per un prodotto rilasciato vive negli input di build (lockfile, SBOM, bundle di release), non sulla tua homepage. Una scansione pulita non significa che la tua app mobile, il tuo installer desktop o il tuo backend API siano documentati.

La scansione non legge le dipendenze npm transitive, non verifica gli identificatori SPDX, non conferma il testo completo delle licenze per ogni componente, e non sa se un essere umano ha approvato la pubblicazione. Quella lacuna è ampia: il report OSSRA 2025 di Black Duck riporta che le dipendenze transitive hanno causato quasi il 30% dei conflitti di licenza rilevati, e nessuno di questi è visibile da una homepage. Non può sostituire la divulgazione delle licenze di terze parti legata a quello che rilasci.

• Dipendenze incluse in prodotti iOS, Android, desktop o embedded, non sul web pubblico.
• Pacchetti transitivi mai caricati nel JavaScript lato browser.
• Se le licenze elencate corrispondono a quello che viene davvero rilasciato nel prodotto in esame.
• Stato di approvazione di revisione e pubblicazione: barriere, approvazioni, audit trail.
• Conformità copyleft: offerte di codice sorgente, codice sorgente corrispondente, fattori scatenanti della distribuzione.
• Font, SDK e icone non referenziati nell'URL scansionato.
• Componenti solo interni o modelli di distribuzione air-gapped.

La scansione è un assaggio che trova lacune visibili su un singolo URL pubblico; una pagina di conformità delle licenze è il registro operativo: inventario rivisto, testo completo delle licenze, attribuzione, un URL stabile per gli acquisti ed esportazioni allineate alle release.

I team superano una scansione di superficie aggiungendo un link nel footer verso una pagina di avviso scarna. I team superano la due diligence enterprise mantenendo la documentazione di conformità delle licenze per ogni prodotto, aggiornata quando le dipendenze cambiano.

Se la scansione trova lacune, considerale uno spunto, non un fallimento. Costruisci l'inventario da lockfile o SBOM per quello che rilasci davvero. Rivedi le licenze. Pubblica una divulgazione mantenuta che puoi condividere in qualsiasi formato richiesto dalla due diligence.

Se la scansione appare pulita, chiediti comunque se la pagina visibile copre il prodotto oggetto del contratto. I footer di licenza del sito di marketing e le pagine di conformità delle licenze di prodotto sono spesso artefatti diversi. Potrebbero servire entrambi; solo uno soddisfa una richiesta di divulgazione delle licenze di terze parti sul prodotto rilasciato.