SBOM:n kattavuus

SBOM on kattava, kun se listaa jokaisen komponentin, joka meni sen kuvaamaan ohjelmistoon, riippuvuuspuun jokaisella syvyydellä, myös komponentit, joita mikään lukitustiedosto (lockfile) tai manifesti ei listaa. SBOM:n kattavuus on juuri tämä ominaisuus. CISA:n 2026 Minimum Elements pyytää SBOM:ien laatijoita ilmoittamaan erikseen, kun tieto on tuntematon, ja toteaa, että vastaanottajat voivat pitää SBOM:ia puutteellisena, jos olennaisia komponenttitietoja jätetään pois.

Kattavuus, kelpoisuus ja laatu ovat eri asioita

Kysymys	Mitä se tarkoittaa	Mikä sen tarkistaa	Mitä se ei voi kertoa
Kelvollinen	Tiedosto noudattaa CycloneDX- tai SPDX-skeemaa	Skeemavalidaattori	Puuttuuko komponentteja
Kenttien laatu	Jokaisella komponentilla on nimi, versio, toimittaja, tunniste, lisenssi ja tiiviste	Laadun pisteytystyökalu	Puuttuuko komponentteja
Kattava	Mitään ohjelmistoon mennyttä ei puutu	Vertailu siihen, mitä buildi todella otti sisään	Syötteet, joita vertailu ei nähnyt

Toisen rivin tunniste on yleensä package URL tai CPE. Tiedosto voi läpäistä kaksi ensimmäistä tarkistusta täydellisesti ja silti jättää puolet ohjelmistosta pois.

Miksi kattavuutta on vaikea mitata jälkikäteen

Skanneri työskentelee lukitustiedostojen, manifestien tai valmiin tuotoksen pohjalta. Se ei voi tietää paketista, jonka asennuksen jälkeinen skripti latasi, binääriin käännetystä cratesta tai peruskuvan kerroksesta, jota sille ei koskaan näytetty. Jokainen näistä on piilotettu riippuvuus.

Otetaan Node.js-palvelu, jonka lukitustiedosto listaa 400 pakettia. Yhdellä niistä on postinstall-skripti, joka lataa valmiiksi käännetyn binäärin npm ci -ajon aikana. package-lock.json-tiedostosta generoitu SBOM on kelvollinen, jokaisella komponentilla on versio ja package URL, eikä binääri ole siinä. Mikään laatupistemäärä ei nosta sitä esiin, koska mikään tiedostossa ei viittaa siihen, mitä puuttuu.

Myöhempi uudelleenbuildaus ei myöskään ratkaise kysymystä: ellei buildi ole toistettava buildi, toinen buildi voi ottaa sisään jotain muuta kuin ensimmäinen.

Miten kattavuus raportoidaan rehellisesti

• Kerro generointikonteksti: tehtiinkö SBOM lähdekoodista ennen buildia, tallennettiinko se buildin aikana vai tuotettiinko se analysoimalla tuotos jälkikäteen.
• Listaa tunnetut aukot: ohjelmiston osat, joita työkalu ei nähnyt, kuten mukaan vendoroitu koodi, valmiiksi käännetyt binäärit tai paketinhallinnan ulkopuolella asennetut komponentit.
• Suosi perusteltua tilaa pistemäärän sijaan. Kattavuusprosentti tarvitsee kokonaismäärän, ja kokonaismäärä on juuri se, mitä kukaan ei tiedä. Lausuntoon, kuten "puutteellinen: jobi salli valvomattoman liikenteen", voi reagoida.

SBOM:n parhaat käytännöt käsittelee laajemmin sitä, miten kerrotaan, mitä SBOM ei nähnyt.

Kattavuustilat CRACI:ssa

CRACI antaa jokaisen jobin SBOM:lle kattavuustilan, ja myös välimuistit saavat sellaisen. Tilat CRACI:n dokumentaation määritelminä:

• Complete: "CRACI havaitsi jobista kattavan näytön, ja jokainen palautettu välimuisti oli kattava."
• Complete with connections: "Vaatimukset täyttyivät, mutta jobi käytti yhtä tai useampaa mukautettua verkkoyhteyttä."
• Incomplete: "CRACI tunnisti tilanteen, joka voi jättää riippuvuuksia pois SBOM:sta."
• Unavailable: "CRACI ei pystynyt viemään näytön arviointia loppuun."
• Not recorded: "Jobi on ajettu ennen kattavuusraportoinnin käyttöönottoa."

CRACI pystyy kertomaan tämän, koska se näkee jokaisen jobin liikenteen pakettilähteisiin ja tietää siksi, milloin jokin on voinut kiertää sen: liikenne, jota se ei valvonut, tai palautettu välimuisti, jonka oma SBOM oli puutteellinen. Kun jobi on puutteellinen, jobi näyttää syyn, esimerkiksi "Unmonitored traffic was allowed". Lue lisää: SBOM-generointi.

Nämä tilat koskevat buildeja, jotka ajetaan CRACI:n runnereilla. Toimittajalta saatuun SBOM:iin tai SBOM:iin putkesta, jota ei ajeta CRACI:lla, käytä yllä olevia vertailuja ja raportointisääntöjä.