SBOM-generointi kehitystiimeissä: yksi käytäntö, jokainen putki

Miksi tiimikohtaiset skannerit eivät muodosta SBOM-ohjelmaa

Osoita viisi työkalua samaan tuotteeseen, niin saat viisi SBOM:ia. Erot ovat rakenteellisia, eivät bugeja:

• Eri syötteet, luettuina eri aikaan. Yksi työkalu lukee lukitustiedoston (lockfile), toinen asennetun riippuvuuspuun, kolmas konttikuvan, neljäs binäärin. Kukin näkee tuotteesta eri osan.
• Eri nimet samalle asialle. Yksi tunnistaa komponentit package URL:n perusteella, toinen CPE:n, kolmas pelkän tiedostonimen. Kahta saman kirjaston kuvaavaa SBOM:ia ei voi yhdistää yhteisen avaimen kautta.
• Eri syvyys. Osa luettelee vain suorat riippuvuudet, osa koko transitiivisen puun ja osa myös build-työkalut. Miksi generaattorit ovat eri mieltä samasta repositoriosta, näytetään sivulla avoimen lähdekoodin SBOM-generaattorit.
• Osa työkaluista vastaa eri kysymykseen. Infrastruktuurin haavoittuvuusskannerit raportoivat, mitä käynnissä oleviin palvelimiin on asennettu. Se on hyödyllistä operoinnille, mutta se ei kuvaa toimittamaasi tuotetta.

Seuraus: SBOM:eja ei voi yhdistää, deduplikoida tai verrata tuotteiden välillä, etkä voi näyttää auditoijalle yhtä prosessia, koska sellaista ei ole.

Menetelmä	Mitä se lukee	Milloin	Mitä siltä jää näkemättä	Tyypillinen tunniste
Lukitustiedosto- tai manifestiskanneri	Checkoutin lukitustiedostot ja manifestit	Ennen buildia tai sen jälkeen	Kaikki, mitä mikään lukitustiedosto ei luettele: asennuskoukut, build-skriptien lataukset, pohjakuvat	Package URL
Konttikuvaskanneri	Kuvan pakettitietokannat ja tiedostot	Buildin jälkeen	Vain buildissa käytetyt työkalut, sisään käännetty koodi, kaikki, millä ei ole pakettitietuetta	Package URL käyttöjärjestelmän ja kielten paketeille
Binääri- tai laiteohjelmistoskanneri	Binäärin merkkijonot ja tunnisteet	Buildin jälkeen	Varmuus: versiot ja komponentit päätellään	CPE tai päätelty nimi
Palvelinten haavoittuvuusskanneri	Käynnissä oleviin palvelimiin asennetut ohjelmistot	Käytön aikana	Tuote sellaisena kuin se toimitettiin asiakkaille	CPE tai toimittajan tuotenimi
Tallennus buildin aikana	Mitä julkaisubuildi haki	Buildin aikana	Ohjelmistot, joita et itse buildannut; se, mitä tallennus ei nähnyt, merkitään puutteelliseksi	Package URL

SBOM-käytäntö: mitä yhtenäistää

Yhtenäistä SBOM, älä skanneria. Käytäntö lukitsee lopputuloksen ja prosessin; kukin putki täyttää sen parhaalla generaattorilla, jota se voi ajaa. Jokainen alla oleva rivi on jotain, minkä voit tarkistaa.

Vaatimus	Sääntö	Miksi	Miten se tarkistetaan
Laajuus	Jokainen asiakkaalle toimitettava tuotejulkaisu, laiteohjelmistot ja konttikuvat mukaan lukien. Sisäiset työkalut valinnaisia.	Asiakkaat ja sääntelijät kysyvät siitä, mitä toimitat.	Jokaisella julkaisurekisterin julkaisulla on SBOM.
Formaatti ja versio	Yksi ensisijainen formaatti, CycloneDX tai SPDX, ja vähimmäisversio. Hyväksy toinen pyynnöstä.	Yksi formaatti tarkoittaa yhtä jäsennintä, yhtä validoijaa ja yhtä säilytyspaikkaa. BSI TR-03183-2 edellyttää CycloneDX 1.6:ta tai uudempaa tai SPDX 3.0.1:tä tai uudempaa, mikä on järkevä alaraja EU-asiakkaille.	Skeemavalidointi raportoi formaatin ja version.
Vähimmäiskentät	Package URL jokaiselle komponentille, jolla sellainen on, CPE vain jos sitä ei ole, toimittaja, versio, ilmoitettu lisenssi, riippuvuussuhteet, työkalun nimi ja versio, aikaleima ja generointikonteksti.	Näitä käytetään vertailussa, lisenssitarkastuksessa ja auditoinneissa. Sovita ne sivun mikä on SBOM vähimmäiselementteihin.	Putken kenttätarkistus laskee puuttuvat arvot.
Milloin generoidaan	Julkaisun tuottavassa CI-buildissa, joka kerta. Ei auditointihetkellä, ei läppärillä.	Uudelleenbuildi ei ole sama buildi; katso buildin aikana tallennetut SBOM:t.	SBOM:n build-tunniste vastaa julkaisun build-tunnistetta.
Syvyys	Koko transitiivinen puu, ei vain ylin taso.	CRA:n vähimmäisvaatimus on ylimmän tason riippuvuudet; haavoittuvuudet ja asiakkaat menevät syvemmälle.	Riippuvuussuhteita on ensimmäisen tason alapuolella.
Säilytyspaikka	Julkaisuartefaktin yhteydessä, haettavissa tuotteen ja version perusteella.	SBOM, jota kukaan ei löydä tietoturvatiedotteen saapuessa, ei ole näyttöä.	Hae satunnaisen julkaisun SBOM tuotteen ja version perusteella.
Säilytysaika	Vähintään tuotteen tukiaika sekä sääntelysi edellyttämä dokumentaation säilytysaika.	CRA asettaa teknisen dokumentaation säilytysajan, ja SBOM on osa sitä.	Vertaa käytännön säilytysaikaa kunkin työkalun säilytysaikaan.
Validointi	Jokainen SBOM validoidaan skeemaa vasten putkessa; virheellinen SBOM kaataa buildin tai julkaisuportin.	Virheelliset SBOM:t epäonnistuvat huomaamatta asiakkaan työkaluissa.	Julkaisuportin lokissa näkyy validointivaihe.
Omistajuus	Tuotetiimi omistaa generoinnin; tuoteturvallisuus omistaa käytännön, validointisäännöt ja kattavuusraportoinnin.	Generointi tarvitsee putken omistajan; johdonmukaisuus tarvitsee sääntöjen yhden omistajan.	Jokaiselle putkelle on nimetty omistaja.
Poikkeukset	Nimetty, määräaikainen poikkeusrekisteri: tiimi, syy, päättymispäivä.	Käytäntö kestää tiimit, jotka eivät vielä pysty noudattamaan sitä.	Yksikään poikkeus ei ole ylittänyt päättymispäiväänsä.

Sivun SBOM:n parhaat käytännöt tarkistuslista kattaa yksittäisen SBOM:n säännöt; tämä käytäntö on niiden yläpuolella oleva taso. Kukin tiimi ilmoittaa, miten sen putki täyttää käytännön, putken vieressä olevassa tiedostossa:

# sbom-policy.yaml, one per release pipeline
product: gateway-firmware
owner: team-gateway
format: cyclonedx
spec_version: "1.6"
generated_in: release-build
generator: build-time-recording
store: artifact-registry
validation: schema, fail-on-errors
exception: none

Generoi buildissa, älä tiimikohtaisesti jälkikäteen

Buildin aikainen generointi on tavoiteltava standardi. Se kuvaa toimitetun buildin, se sisältää piilevät riippuvuudet, joita mikään lukitustiedosto ei luettele, ja yksi mekanismi tuottaa samanmuotoisen SBOM:n jokaiselle tiimille kyseisessä putkessa. Eron selittää helpoimmin keittiöllä: skanneri maistaa keittoa ja arvaa reseptin; tallentaja katsoo, mitä keittiöön tuodaan.

Skanneri on edelleen oikea työkalu kuville, joita et itse buildannut, kolmansien osapuolten binääreille ja vanhoille tuotteille, joilla ei ole CI:tä. Kirjaa tämä käytäntöön ja tallenna generointikonteksti, jotta lukija tietää, mitä kukin SBOM näki.

Tilanne	Generointitapa	Tallennettava generointikonteksti
Julkaisu buildataan hallitsemassasi CI:ssä	Tallenna buildi tai aja generaattori julkaisujobin sisällä	"Tallennettu buildin aikana" tai "asennuksen jälkeen, tiedostoista"
Konttikuva buildataan CI:ssä	Tallenna kuvan buildi; skannaa tulos sen käyttöjärjestelmäpakettien osalta, jos tallentaja ei kata niitä	Build-tunniste ja kuvan digest
Kolmannen osapuolen kuva tai laite	Kuvaskanneri sekä toimittajan SBOM, jos sellainen on	"Skannattu tulos, ei meidän buildaamamme"
Toimittajan binääri	Pyydä toimittajan build-SBOM; binäärianalyysi tarkistuksena	Toimittaja, versio, miten se on hankittu
Vanha tuote ilman putkea	Skannaa toimitettu artefakti; suunnittele putki	"Skannattu tulos" ja poikkeus päättymispäivineen

Sekalainen CI: GitHub Actions, GitLab ja Jenkins samassa organisaatiossa

Käytäntö on tarkoituksella CI-riippumaton: se määrittelee lopputuloksen, joten GitLab- tai Jenkins-putki voi täyttää sen generaattorivaiheella ja GitHub Actions -putki voi käyttää buildin aikaista tallennusta. Generaattorivaiheen säännöt:

• Aja se julkaisujobissa asennusvaiheen jälkeen, ei erillisessä jobissa, joka asentaa uudelleen.
• Kiinnitä generaattorin versio ja kiinnitä CI-actionit committiin, ei tagiin. Miksi tämä on tärkeää juuri skannereille, kerrotaan sivulla avoimen lähdekoodin SBOM-generaattorit.
• Kirjaa generointikontekstiksi "asennuksen jälkeen, tiedostoista", jotta lukijat tietävät, mitä se näki.
• Validoi tulos samaa skeemaa vasten kuin kaikissa muissa putkissa.

Avoimen lähdekoodin generaattorit, kuten Syft, Trivy ja cdxgen, osaavat kaikki kirjoittaa CycloneDX:ää ja SPDX:ää, joten formaattisääntö ei pakota valitsemaan tiettyä työkalua. Vertailu löytyy sivulta SBOM-työkalut vertailussa.

CRACI tukee tällä hetkellä GitHub Actionsia; GitLab CI ja Jenkins ovat tiekartalla ilman päivämäärää. Käyttöönoton kannalta tämä tarkoittaa: aloita buildin aikainen tallennus siellä, missä käytetään GitHub Actionsia, pidä generaattorivaiheet muualla ja seuraa molempia samassa kattavuusraportissa.

Kun asiakas haluaa tietyn formaattiversion

Asiakas pyytää CycloneDX 1.6:ta, ja työkalusi kirjoittavat 1.7:ää. Näin käy, koska asiakkaan tuontityökalu tai oma käytäntö on sidottu tiettyyn versioon; BSI:n alaraja on 1.6, joten EU-asiakkaat mainitsevat sen usein. Vaihtoehtosi:

1. Kysy, kelpaako uudempi versio. Usein kelpaa.
2. Muunna CycloneDX CLI:llä, validoi sitten kohdeversiota vasten ja tarkista, mitä menetettiin: kentät, jotka ovat olemassa vain uudemmassa spesifikaatiossa, pudotetaan pois.
3. SPDX-pyynnössä sama CLI muuntaa SPDX JSON 2.3 -muotoon ja siitä pois. Sen dokumentaatio varoittaa, että SPDX:n ja CycloneDX:n välinen muunnos "can result in the loss of some information" eli voi johtaa joidenkin tietojen menetykseen.

cyclonedx convert --input-file bom.cdx.json --input-format json \
  --output-file bom-1.6.cdx.json --output-format json --output-version v1_6

cyclonedx validate --input-file bom-1.6.cdx.json --input-format json \
  --input-version v1_6 --fail-on-errors

Validoija tarkistaa CycloneDX 1.7:ää vasten, ellet anna parametria --input-version. Käytännön sääntö: pidä alkuperäinen SBOM tallenteena. Muunnettu kopio on johdettu toimitus; tallenna sen johtamistiedot (työkalu, versio, päivämäärä) sen mukana. Lisää tällaisiin pyyntöihin vastaamisesta sivulla asiakkaiden SBOM-pyynnöt ja kahdesta formaatista sivulla CycloneDX vs. SPDX.

Lisenssitiedot lakitiimille

Sama SBOM voi palvella lakitiimiä, jos käytäntö vaatii oikeat kentät. Lakitiimi tarvitsee jokaisen komponentin lisenssin, eron ilmoitetun lisenssin (mitä paketti sanoo) ja todetun lisenssin (minkä joku on varmistanut) välillä, copyleft-velvoitteet sekä luettelon komponenteista, joilla ei ole lisenssiä. CycloneDX 1.6 merkitsee lisenssit ilmoitetuiksi tai todetuiksi, ja SPDX:ssä on molemmille omat kenttänsä.

• Vaadi SPDX-lisenssitunnisteita tai -lausekkeita, kuten MIT tai Apache-2.0 OR MIT.
• Merkitse NOASSERTION ja puuttuvat lisenssit tarkastettaviksi. SPDX:ssä NOASSERTION tarkoittaa, ettei määritystä tehty tai tietoa ei annettu; se ei ole lisenssi.
• Ohjaa copyleft-lisenssit lakitiimille ennen julkaisua, ei sen jälkeen.

SBOM sisältää ilmoitetut lisenssit. Lisenssien noudattamisen tarkastus, jossa käsitellään todetut lisenssit, ilmoitukset ja velvoitteet, on lakityötä tai erikoistyökalun tehtävä; katso avoimen lähdekoodin lisenssien noudattaminen.

Käyttöönotto tiimi kerrallaan

Vaihe	Omistaja	Valmis, kun	Tyypillinen este
1. Inventaario: tuotteet, putket, CI-järjestelmät ja nykyiset generaattorit, yksi rivi julkaisuputkea kohden	Tuoteturvallisuus	Jokaisella toimitetulla tuotteella on rivi	Kukaan ei tiedä, mikä putki buildaa julkaisun
2. Julkaise käytäntö poikkeusrekistereineen	Tuoteturvallisuus	Käytäntö hyväksytty ja julkaistu	Väittely siitä, mikä työkalu määrätään (käytäntö ei määrää mitään)
3. Pilotoi yhden tai kahden tiimin kanssa, joilla on syy: asiakaspyyntö, määräaika tai tuote, jota nykyinen työkalu ei pysty käsittelemään	Pilottitiimit	Pilottijulkaisut toimitetaan vaatimukset täyttävine SBOM:eineen	Tiimit, joilla ei ole polttavaa syytä, priorisoivat sen alas
4. Lisää validointiportit pilottiputkiin	Pilottitiimit	Virheellinen SBOM kaataa julkaisun	Pelko julkaisujen estämisestä; aloita varoituksella
5. Laajenna CI-järjestelmä kerrallaan; poista tiimikohtainen skanneri vasta, kun korvaaja täyttää käytännön	Tuotetiimit	Kattavuustavoite saavutettu kussakin CI-järjestelmässä	Putket, joita kukaan ei omista
6. Raportoi kattavuus kuukausittain	Tuoteturvallisuus	Raportti menee johdolle joka kuukausi	Käsin lasketut mittarit

Vaiheen 1 inventaariotaulukon pitäisi olla viimeinen laatuaan; taulukkolaskennasta luopumista käsitellään sivulla SBOM-automaatio. Yocto-pohjainen tuote on yleinen pilotti, koska yleiskäyttöiset skannerit kompastelevat sen kanssa; katso miksi SBOM-skannerit eivät näe Yocto-buildeja.

Kattavuuden mittaaminen

Luvut, joita johto ja auditoijat kysyvät, kukin määriteltynä suhdelukuna:

• Julkaisukattavuus: käytännön mukaisella SBOM:lla toimitetut julkaisut ÷ toimitetut julkaisut.
• Tuotekattavuus: tuotteet, joilla on vähintään yksi vaatimukset täyttävä SBOM nykyisellä tukiajalla ÷ tuetut tuotteet.
• Validoinnin läpäisyaste: validoinnin läpäisevät SBOM:t ÷ generoidut SBOM:t.
• Tunnistekattavuus: komponentit, joilla on package URL (tai CPE) ÷ komponentit.
• Lisenssikattavuus: komponentit, joilla on ilmoitettu lisenssi ÷ komponentit.
• Kattavuustila: SBOM:t, joiden generaattori ilmoittaa ne kattaviksi ÷ SBOM:t. Mahdollinen vain, jos työkalu raportoi sen.
• Aika SBOM:iin: aika julkaisusta siihen, että SBOM on saatavilla.

Esimerkki kuukausiraportista (havainnollistavat luvut):

Mittari	GitHub Actions -putket	GitLab- ja Jenkins-putket	Kaikki
Julkaisukattavuus	46 / 48	19 / 27	65 / 75
Validoinnin läpäisyaste	100 %	92 %	97 %
Tunnistekattavuus	99 %	88 %	95 %
Avoimet poikkeukset	1	4	5

Näyttönä sääntelijälle tai auditoijalle kokonaisuus on käytäntö, poikkeusrekisteri, kattavuusraportti ja muutama esimerkki-SBOM. Se osoittaa yhden prosessin, jota sovelletaan ja mitataan. CRA:n osalta katso CRA-opas.

Miten CRACI sopii kuvaan

GitHub Actions -putkissa CRACI on runneri: asetat runs-on: craci, ja jokainen jobi saa tallennetun SBOM:n ilman generaattorivaihetta. Jokaisessa SBOM:ssa on kattavuustila, transitiiviset riippuvuudet, package URL jokaiselle paketille ja kunkin komponentin ilmoitettu lisenssi, ja sen voi viedä CycloneDX- tai SPDX-muodossa. Lisenssikäytännön säännöt voivat estää buildin, valvottuja SBOM:eja arvioidaan jatkuvasti uudelleen, ja buildihistoria näyttää, mitkä buildit sisälsivät haavoittuvan riippuvuuden. Näin nämä tiimit täyttävät käytännön rivit "generoidaan julkaisubuildissa", "tunniste" ja "lisenssi" oletuksena. Kolmansien osapuolten SBOM:eja voi lisätä, joten ostettuja komponentteja valvotaan omien buildiesi rinnalla.

Katso SBOM-generointi CRACI:lla ja SBOM:t GitHub Actionsissa.

Kun CRACI ei ole oikea vastaus

• GitLab CI:tä tai Jenkinsiä käyttävät tiimit: ei tänään, se on tiekartalla. Käytä generaattorivaihetta, joka täyttää käytännön.
• GitHub Enterprise Server: ei tuettu tänään.
• Infrastruktuurin ja palvelinten skannaus eli se, mitä palvelimille on asennettu, ja virheelliset konfiguraatiot: eri tehtävä; pidä ne työkalut.
• Binääri- tai laiteohjelmistoanalyysi toimittajan kuvista, joita et itse buildaa: CRACI tallentaa buildeja eikä skannaa binäärejä.
• Pitkä säilytys: CRACI säilyttää buildidataa oletuksena 180 päivää, ja Enterprise-tasolla säilytysajan voi räätälöidä. Jos käytäntösi edellyttää SBOM:eja pidempään, vie ne omaan säilytyspaikkaasi.

SBOM-generointi tiimeissä: usein kysytyt kysymykset

Miten yhtenäistämme SBOM-generoinnin tiimeissä, jotka käyttävät eri työkaluja?

Yhtenäistä lopputulos, älä työkalua. Kirjoita yksi käytäntö, joka lukitsee formaatin ja version, vähimmäiskentät, SBOM:n generointihetken, säilytyspaikan, säilytysajan ja sen, kuka validoi. Anna kunkin putken täyttää se parhaalla generaattorilla, jota se voi ajaa, ja mittaa kattavuutta käytäntöä vasten.

Mitä SBOM-käytännön pitäisi sisältää?

Laajuus, formaatti ja vähimmäisversio, vähimmäiskentät (package URL, toimittaja, versio, ilmoitettu lisenssi, riippuvuudet, työkalu, aikaleima, generointikonteksti), generointi julkaisubuildissa, koko transitiivinen syvyys, säilytys julkaisun yhteydessä, säilytysaika, validointi putkessa, omistajuus ja määräaikainen poikkeusrekisteri.

Pitäisikö jokaisen tiimin ajaa omaa skanneriaan, vai pitäisikö SBOM:ien tulla buildista?

Buildista, missä se on mahdollista. Buildin aikana tallennettu SBOM kuvaa toimitetun buildin ja antaa jokaiselle tiimille kyseisessä putkessa samanmuotoisen SBOM:n. Pidä skannerit sitä varten, mitä et itse buildannut: kolmansien osapuolten kuvat, toimittajien binäärit ja vanhat tuotteet ilman putkea.

Asiakas haluaa SBOM:mme vanhemmassa CycloneDX-versiossa. Mitä teemme?

Kysy ensin, kelpaako uudempi versio. Jos ei, muunna kopio CycloneDX CLI:llä (cyclonedx convert ja --output-version v1_6), validoi se kyseistä versiota vasten ja tarkista, mitkä kentät pudotettiin. Pidä alkuperäinen tallenteena ja tallenna, miten kopio johdettiin.

Miten saamme lisenssitiedot SBOM:eista lakitiimille?

Vaadi käytännössä SPDX-lisenssitunnisteita tai -lausekkeita, merkitse NOASSERTION ja puuttuvat lisenssit tarkastettaviksi ja ohjaa copyleft-lisenssit lakitiimille ennen julkaisua. SBOM sisältää ilmoitetut lisenssit; todetut lisenssit, ilmoitukset ja velvoitteet edellyttävät lisenssitarkastusta.

Miten mittaamme SBOM-kattavuutta tuotteiden välillä?

Suhdelukuina: vaatimukset täyttävällä SBOM:lla toimitetut julkaisut, tuetut tuotteet, joilla on vaatimukset täyttävä SBOM, validoinnin läpäisyaste, komponentit, joilla on package URL, komponentit, joilla on ilmoitettu lisenssi, kattavat SBOM:t siellä, missä työkalu raportoi sen, ja aika julkaisusta SBOM:iin. Raportoi ne kuukausittain CI-järjestelmittäin.

Mitä näyttöä tarvitsemme osoittaaksemme auditoijalle, että SBOM-generointi on johdonmukaista?

Käytännön, poikkeusrekisterin, kuukausittaisen kattavuusraportin ja muutaman esimerkki-SBOM:n generointikonteksteineen. Yhdessä ne osoittavat yhden prosessin, jota sovelletaan jokaiseen julkaisuun ja mitataan, ja juuri sen auditoija tai asiakas tarkistaa.