SBOM:n parhaat käytännöt

Käytäntöjen viemisestä useisiin tiimeihin kerrotaan sivulla SBOM-generointi kehitystiimeissä.

SBOM:ien generointi

1. Generoi CI:ssä, jokaiselle julkaisulle

Käsin tehty SBOM vanhenee ennen kuin kukaan ehtii lukea sen. Tee siitä vaihe putkeen, joka buildaa julkaisun, tai käytä runneria, joka tuottaa sen ilman erillistä vaihetta, jotta mikään julkaisu ei lähde ilman sitä. GitHub Actionsista: näin generoit SBOM:n GitHub Actionsissa.

2. Kuvaa se buildi, joka toimitettiin

Buildit eivät ole oletuksena toistettavia. Saman commitin buildaaminen kahdesti ei takaa samoja riippuvuuksia, koska versiot ratkaistaan buildin aikana ja vaiheet voivat vaihdella. Kannettavalla tehty tai myöhemmin skannattu SBOM kuvaa samankaltaista buildia, ei sitä, jonka toimitit. Vain julkaisun tuottaneen CI-buildin SBOM todistaa, mitä julkaisussa on. Katso buildin aikana tallennetut SBOM:t.

3. Kata enemmän kuin lukitustiedosto

Lukitustiedosto (lockfile) ei ole tallenne siitä, mitä toimitettiin. Asennusskriptit lataavat koodia, Rustin build-skriptit hakevat tiedostoja, ja konttibuildit tuovat mukanaan peruskuvan omine käyttöjärjestelmäpaketteineen. Päätä, mitä SBOM:n on katettava, ja testaa se: etsi SBOM:stasi peruskuvasi paketti ja build-työkalu.

4. Ota mukaan transitiiviset riippuvuudet ja suhteet

Haavoittuvuudet ovat yleensä suorien riippuvuuksiesi alapuolella. Litteä luettelo näyttää, että komponentti on mukana, mutta ei sitä, mitä pitää päivittää. Säilytä riippuvuusgraafi SBOM:ssa, jotta löydöksen mukana tulee paketti, joka tuo sen mukaan.

5. Kerro, mitä et nähnyt

2026 Minimum Elements -ohjeistus pyytää SBOM:n laatijoita ilmoittamaan tuntemattomat tiedot erikseen. Osittainen SBOM, joka kertoo olevansa osittainen, on arvokkaampi kuin osittainen SBOM, joka näyttää valmiilta. Tallenna myös työkalu, sen versio ja generointiympäristö, jotta lukija voi arvioida, mitä tiedosto kattaa. Katso SBOM:n kattavuus.

SBOM:ien säilyttäminen

6. Säilytä yksi SBOM per julkaisu, sidottuna artefaktiin

Kun vanhaa versiota käyttävä asiakas kysyy, koskeeko haavoittuvuus häntä, tarvitset kyseisen version SBOM:n etkä uusinta. Säilytä jokainen SBOM sen buildin ja artefaktin kanssa, jota se kuvaa, ja päätä säilytysaika sen mukaan, kuinka kauan tuet julkaisua. SBOM:n tiivisteet auttavat sitomaan sen täsmälleen oikeaan artefaktiin.

7. Valitse formaatti ja tunniste ja pysy niissä

Standardoi CycloneDX tai SPDX, formaatin versio ja package URL -tunnisteet. Suurin osa SBOM:ien vertailun vaivasta johtuu siitä, että työkalut nimeävät saman asian eri tavoin. Validoi jokainen tiedosto putkessa ja pyydä toimittajilta samaa formaattia. SBOM:n laadun tarkistuslista näyttää, mitä tarkistaa ja millä työkaluilla.

SBOM:ien käyttäminen

8. Valvo toimitettua, ei vain sitä, mitä buildaat nyt

SBOM on arvokkaimmillaan päivänä, jona viime vuonna julkaistusta ohjelmistosta tulee tietoturvatiedote. Pull requestin skannaus ei silloin auta. Arvioi tuettujen julkaisujen tallennetut SBOM:t uudelleen uutta haavoittuvuustietoa vasten, jotta uusi tiedote muuttuu luetteloksi julkaisuista, joita se koskee.

9. Ohjaa löydökset omistajalle ja kirjaa päätös

SBOM, jossa on tuhat vastaavuutta haavoittuvuuksiin, on luettelo, ei suunnitelma. Järjestä löydökset priorisointimenetelmällä, lähetä kukin korjauksesta vastaavalle tiimille ja kirjaa, miksi et toiminut lopuissa, esimerkiksi VEX-lausunnossa.

10. Käytä samaa SBOM:ia asiakkaille ja auditoijille

Asiakkaat, auditoijat ja viranomaiset kysyvät samankaltaisia kysymyksiä. Vastaa niihin siitä SBOM:sta, jota omat tiimisi käyttävät, äläkä tuota erillistä dokumenttia, joka erkanee todellisuudesta. Jos jaat SBOM:eja, päätä, kuka saa nähdä ne ja miten päivitykset toimitetaan, ja pyydä samaa toimittajiltasi.

Yleiset virheet

Virhe	Miksi se haittaa	Sen sijaan
Yksi SBOM per repositorio	Se ei kerro mitään yksittäisestä julkaisusta	Yksi per julkaisu, sidottuna artefaktiin
Generointi vain auditoinnin aikaan	Se kuvaa buildia, jota kukaan ei toimittanut	Jokainen julkaisu, CI:ssä
SBOM:n pitäminen valmiina	Uusia tiedotteita tulee julkaisun jälkeen	Jatka sen valvontaa
Vain komponenttimäärän vertailu	Enemmän ei ole parempi, jos merkinnät ovat vääriä	Tarkista tietyt paketit, joiden tiedät olevan mukana

Näin CRACI hoitaa tämän

CRACI kattaa käytännöt, jotka riippuvat buildista. Se on GitHub Actions -runneri, joka tallentaa jokaisen paketin, jonka kukin jobi hakee, myös piilossa olevat riippuvuudet, joita mikään lukitustiedosto ei luettele, CycloneDX- tai SPDX-muotoiseen SBOM:iin kattavuustilan kanssa. Se säilyttää jokaisen aiemman buildin ja sen SBOM:n tilauksesi säilytysajan puitteissa, arvioi valvotut SBOM:t uudelleen uusien haavoittuvuuksien ilmaantuessa ja näyttää, missä buildeissa oli haavoittuva riippuvuus. Tietoturvatiimit priorisoivat löydökset ja lähettävät ne korjauksesta vastaaville tiimeille. Katso SBOM-hallinta hallintatyökalujen vertailua varten tai parhaat SBOM-työkalut.

SBOM:n parhaat käytännöt: usein kysytyt kysymykset

Milloin SBOM kannattaa generoida?

Julkaisun tuottavan CI-buildin aikana, joka kerta. Silloin tehty SBOM kuvaa sitä, mitä toimitettiin, kun taas myöhemmin tehty kuvaa uutta buildia tai skannausta.

Kuinka kauan SBOM:eja pitää säilyttää?

Vähintään niin kauan kuin tuet julkaisua, sekä sen ajan, jonka viranomaiset tai sopimukset edellyttävät. Vanhan version SBOM:ia tarvitaan, jotta tiedät, koskeeko uusi haavoittuvuus sen käyttäjiä.

Pitäisikö SBOM:t automatisoida?

Kyllä. Käsin tehty SBOM on vanhentunut jo seuraavassa julkaisussa. Generoi SBOM:t putkessa, validoi ne siellä ja säilytä ne buildin kanssa.

Pitäisikö SBOM jakaa asiakkaille?

Jaa se, kun asiakas tai viranomainen pyytää, sinulle sopivin ehdoin. SBOM paljastaa, mitä käytät, joten moni yritys jakaa sen pyynnöstä eikä julkaise sitä.

Mitä eroa on SBOM:lla ja SBOM-hallinnalla?

SBOM on yksi tiedosto. SBOM-hallinta on jatkuvaa työtä: SBOM:ien säilyttämistä julkaisuittain, niiden valvomista uusien haavoittuvuuksien varalta ja niiden saattamista niitä tarvitsevien saataville.