Fra SBOM eller lockfile til en licensside

En SBOM er en maskinlæsbar oversigt optimeret til sårbarhedsmatching og værktøjer til forsyningskæden. En licensside er en menneskelæsbar oplysning om tredjepartslicenser, der er lavet til indkøbsansvarlige under leverandørens due diligence. De besvarer forskellige spørgsmål og kan sjældent erstatte hinanden.

Købere beder om begge dele i forskellige afsnit af spørgeskemaet. At indsende kun en SBOM, når de beder om en open source-licensside, tvinger dem til manuelt at jagte fuld licenstekst, eller til at give jer et minus for ufuldstændig oplysning.

Bring CycloneDX, SPDX eller pakke-lockfiles ind i jeres oplysningsproces. Kortlæg SBOM-komponenter til rækker i jeres gennemgangskø. Hver række starter som skal gennemgås. SBOM'ens licensfelter er fingerpeg, ikke godkendelser.

Én SBOM pr. produkt pr. udgivelse. Flet ikke urelaterede produkter ind i én samlet licensside, medmindre jeres oplysningsmodel tydeligt afgrænser afsnittene. Indkøb forventer klarhed.

• Importér fra CI-artefakt, release-tag eller eksport fra et SBOM-værktøj.
• Bevar komponentnavn, version og PURL eller tilsvarende id.
• Betragt SBOM'ens licensfelt som udgangspunkt, ikke det endelige svar.
• Flag komponenter med manglende, modstridende eller NOASSERTION-licensdata.
• Genimportér ved hver udgivelse. Lap ikke forældet JSON manuelt i det uendelige.

SBOM'er inkluderer ofte SPDX-licens-id'er uden fuld licenstekst. Oplysning om tredjepartslicenser kræver tekst, indkøb kan læse. Berig hver godkendt komponent med fuldt licensindhold, kildeangivelsestekster og copyleft-flag fra jeres gennemgangspolitik.

Afklar konflikter mellem registrets og repoets licens. Eskalér specialtilpassede og copyleft-licenser. Compliance svigter, når SBOM-metadata kopieres til en offentlig side uden menneskelig verificering.

• Vedhæft fuld licenstekst for hver godkendt komponent.
• Bekræft licensen mod repoets LICENSE, leverandørens PDF eller juridisk vejledning.
• Anvend regler for gennemgang af copyleft og distribution, før godkendelse.
• Tilføj blokke med licensmeddelelse og kildeangivelse, hvor det kræves.
• Dokumentér udelukkelser: Dev-afhængigheder, der ikke leveres, test-only-pakker osv.
• Spær udgivelse, indtil der er nul ikke-gennemgåede, omfattede rækker.

Fra den samme godkendte oversigt, udgiv vedligeholdt oplysning og release-eksporter. Del det format, due diligence beder om: URL, PDF eller pakke. Eksporter kan vedhæftes tickets, release notes eller leverandørportaler.

Når SBOM'en ændrer sig ved den næste udgivelse (nye pakker, versionsopdateringer, licensændringer), så genimportér, gennemgå igen, genudgiv. Afvigelsestjek automatiserer diffen, så I ikke bliver overraskede ved en kunderevision.

• Udgiv delbart bevis pr. produkt (hostet side og/eller eksporter).
• Verificér, at oplysningen indlæses, den fulde tekst vises, og produktomfanget er klart.
• Eksportér JSON, kildeangivelsesfiler og oplysningspakker fra det samme snapshot.
• Sæt CI op til at flage, når SBOM'en afviger fra jeres sidst godkendte udgivelse.
• Del gennemgået oplysning med indkøb, ikke en rå SBOM, når de beder om dokumentation for licensoverholdelse.

FOSSA, Snyk, Mend, Syft, GitHub dependency graph og interne CI-pipelines producerer SBOM'er og licensfingerpeg. SourceTrust og lignende oplysningsprocesser ligger i den anden ende: Gennemgået udgivelsesregistrering, URL til compliance-siden, eksporter på linje med det, der leveres.

I erstatter ikke jeres SBOM-værktøj. I omdanner resultatet til en oplysning om tredjepartslicenser, som jeres kunder og revisorer kan bruge. Gør licensoverholdelse til et vedligeholdt produktartefakt, ikke en engangsdeling af filer.