Ohjelmiston materiaalilista (SBOM) siirtyi valinnaisesta artefaktista sopimusvelvoitteeksi nopeammin kuin useimmat puolustusurakoitsijat odottivat. Vuonna 2021 se oli suositus toimeenpanomääräyksen 14028 sisälle hautautuneena. Vuoteen 2026 mennessä siitä on tullut porttitesti — jokainen yhdysvaltalaiselle tai NATO-asiakkaalle toimitettu binääri on varustettava ajantasaisella, allekirjoitetulla, koneluettavalla SBOM:lla, ja binäärin tuottaneen putken on kyettävä todistamaan auditointihetkellä, että SBOM generoitiin samoista lähteistä, samassa rakennuksessa, joka tuotti artefaktin. Tässä artikkelissa käydään läpi insinöörityöpäätökset, jotka määrittävät, selviääkö CI/CD-putkesi tuosta auditoinneista.

1. Miksi SBOM:sta tuli puolustuksessa pakollinen

Neljä sääntelylankaa sulautui yhteen. Toimeenpanomääräys 14028 (toukokuu 2021) vaati liittovaltio-ohjelmistotoimittajia toimittamaan SBOM:eja ja loi perustan NTIA:n "vähimmäiselementeille." NDAA Section 1655 (vuoden 2023 NDAA, tarkennettu vuoden 2026 tarkistuksiin asti) laajensi SBOM-vaatimukset puolustushankintoihin, velvoittaen DoD:n pääurakoitsijat ja alihankkijat toimittamaan SBOM:eja kaikelle osastolle toimitetulle ohjelmistolle, erityisillä säännöksillä kiinalaisperäisistä komponenteista ja vastustajamaan toimittajista. NIS2 kohdisti rinnakkaista painetta koko EU:n puolustuspohjaan, vaatien dokumentoitua toimitusketjun riskienhallintaa olennaisille ja tärkeille toimijoille. NIST SP 800-218 — Secure Software Development Framework (SSDF) — kodifioi SBOM-generoinnin odotettuna käytäntönä kaikille toimittajille, jotka itsearviointivat OMB M-22-18:n ja M-23-16:n mukaisesti.

Käytännön vaikutus on, että puolustusohjelmistotoimittaja ilman SBOM-työkaluja vuonna 2026 ei ole kilpailukykyinen toimittaja. RFP:t sisältävät SBOM-lausekkeita. Auditoinnit sisältävät SBOM-tarkastuksia. Ja puuttuva SBOM käsitellään samoin kuin puuttuva testiraportti — todisteena siitä, että toimittajan insinöörityöprosessi on keskeneräinen. Hyvä uutinen insinööritiimeille on, että SBOM-generointi, kun se on kertaalleen instrumentoitu oikein, on halpa ylläpitää. Huono uutinen on, että "instrumentoitu oikein" kätkee pitkän luettelon arkkitehtuuripäätöksistä, joista useimmat tehdään väärin ensimmäisellä kerralla.

2. CycloneDX vs SPDX

Kaksi SBOM-formaattia on tärkeä: CycloneDX (alkuperä OWASP:issa, nykyään Ecma-standardi) ja SPDX (alkuperä Linux Foundationissa, ISO/IEC 5962:2021). Ne kattavat saman käsitteellisen alueen — komponentit, versiot, lisenssit, tiivisteet, suhteet — mutta murteet eroavat tavoilla, jotka ovat tärkeitä työkalujen kannalta.

CycloneDX on optimoitu turvallisuuskäyttötapauksiin: natiiviVEX-tuki, ensimmäisen luokan haavoittuvuuskentät, kevyt JSON, tiukka integrointi OWASP-ekosysteemiin (Dependency-Track, dependency-check). Se on formaatti, jonka useimmat tietoturvatiimit tuottavat oletusarvoisesti. SPDX on optimoitu lisenssi- ja alkuperäkäyttötapauksiin: rikkaampi lisenssiekspressionkieli, pidempää jalansijaa avoimen lähdekoodin vaatimustenmukaisuusauditoinneissa, ISO-leima, jota laki- ja hankintatiimit pyytävät säännellyillä toimialoilla.

Puolustusasiakkaat pyytävät molempia. NDAA-linjatut sopimukset yhä useammin määrittelevät "SPDX 2.3 tai uudempi tai CycloneDX 1.5 tai uudempi," jättäen formaattivalinnan toimittajalle — kunnes asiakkaan alavirran työkalut pakottavat yhden tai toisen. Pragmaattinen malli on kaksoisemissio: generoi CycloneDX SBOM rakennuksessa sisäiseen haavoittuvuustyökaluun, ja muunna sitten SPDX:ksi toimitushetkellä muuntimella (avoimen lähdekoodin cyclonedx-py, cdx2spdx tai SPDX-työkaluketju). Käsittele yksi totuuden lähteenä ja toinen johdettuna artefaktina; pidä molemmat versioiduina binäärin rinnalla.

3. Rakennusaikainen vs rakennuksen jälkeinen SBOM-generointi

Yksittäisin suurin SBOM-uskottavuuden määrittäjä on se, milloin putkessa SBOM tuotetaan. Leirejä on kaksi. Rakennuksen jälkeiset skannerit (Trivy, Snyk, GitHubin natiivi riippuvuusgraafi skannaustilassa) ottavat valmiin kontaineri-imagon tai binäärin ja käänteissuunnittelevat sen komponentit. Rakennusaikaiset generaattorit (Syft kun kytketty rakennukseen, cdxgen, kielikohtaiset työkalut kuten cargo cyclonedx, mvn cyclonedx, npm sbom) tarkkailevat varsinaista rakennusprosessia ja emittivat SBOM:n rakennuksen käyttämästä ratkaisturiippuvuusgraafista.

Vain rakennusaikainen generointi on uskottavaa auditoinneissa. Syy on yksinkertainen: rakennuksen jälkeinen skanneri tunnistaa sen, mitä se voi nähdä — se ei pysty erottamaan kirjastoa, joka on staattisesti linkitetty binääriin, kirjastosta, joka tuotiin rakennusaikaista työkalua varten mutta ei koskaan toimitettu. Se ei näe yksityisiä rekisterejä, joihin skannerilla ei ole tunnistietoja. Se ei näe käännösaikaista koodingenerointia. Tarkistaja, joka kysyy "mistä tiedät, että tämä SBOM on täydellinen?" saa käyttökelpoisen vastauksen vain silloin, kun SBOM on tuotettu itse rakennuksen toimesta, provenienssilla takaisin lukitustiedostoihin. Rakennuksen jälkeinen skannaus on hyödyllinen toinen mielipide. Se ei ole ensisijainen artefakti.

Käytännössä tiimit kokoontuvat pinolle Syft käyttöjärjestelmä- ja kontainerikerroksille, kielinatiivit generaattorit (cargo, npm, pip, mvn, go-licenses CycloneDX-tulostuksella) lähdekoodikomponenteille, cdxgen kun monikielirepos tarvitsevat yhden läpikäynnin, ja Trivy tai GitHubin natiivi SBOM-vienti rakennuksen jälkeisenä ristiintarkastuksena. Rakennusputki yhdistää kielinatiivit tulosteet yhdeksi CycloneDX-dokumentiksi, allekirjoittaa sen ja liittää sen julkaistuun artefaktiin.

4. SBOM-allekirjoittaminen ja todistukset

Allekirjoittamaton SBOM ei ole todiste. Tarkistaja ei voi varmistaa, että se on tuotettu binäärin tuottaneessa rakennuksessa; hän ei voi varmistaa, ettei sitä ole muokattu; hän ei voi todistaa, että rakennusympäristö oli luotettu. Korjaus on todistus — allekirjoitettu lausuma, jonka rakennusjärjestelmä tuottaa, sitoen SBOM:n tiettyyn artefaktitiivisteeseen.

Hallitsevat primitiivit ovat sigstore/cosign avaimettomaan allekirjoittamiseen (OIDC-sidotut sertifikaatit, läpinäkyvyysloki Rekorissa) ja in-toto-todistukset lausumaformaatille. In-toto-todistuksella on kolme osaa: kohde (todistettava artefaktitiivis), predikaattityyppi (esim. https://cyclonedx.org/bom tai SLSA-provenienssityyppi) ja predikaattirunko (itse SBOM tai rakennusprovenanssi). Cosign allekirjoittaa todistuksen, liittää sen OCI-artefaktina kontaineri-imagon rinnalle ja työntää allekirjoituksen Rekor-läpinäkyvyyslokiin.

SLSA-viitekehys (Supply-chain Levels for Software Artifacts) on kypsyysmalli, johon puolustusasiakkaat viittaavat halutessaan yksittäisen luvun vaatimustensa ankkurointiin. SLSA 1 tarkoittaa, että provenanssi on olemassa. SLSA 2 tarkoittaa, että se on allekirjoitettu ja rakennuspalvelu on isännöity. SLSA 3 tarkoittaa, että rakennukset ovat eristettyjä ja provenanssi on itse projektin väärentämätön. SLSA 4 tarkoittaa kahden osapuolen katselmusta ja hermeettistä, toistettavaa rakennusta. Useimmat puolustussopimukset vuonna 2026 pyytävät SLSA 3:a pohjatasoksi operatiivisiin ympäristöihin toimitetulle ohjelmistolle; SLSA 2 on hyväksyttävä ei-julkistetulle työkalulle. SLSA 4 pysyy harvinaisena korkeimman luokituksen työkuormien ulkopuolella.

5. Haavoittuvuuskorrelaatiokerros

SBOM on komponenttilista; se ei itsessään ole haavoittuvuusraportti. Korrelaatiokerros liittää SBOM:n haavoittuvuustietokantoihin (NVD, OSV, GitHub Advisory Database) tuottamaan artefaktikohtaisen haavoittuvuuslistan. Tässä useimmat tiimit huomaavat, että 80 % SBOM:ssaan raportoiduista haavoittuvuuksista ei ole hyödynnettävissä heidän kontekstissaan — haavoittuvainen funktio ei koskaan kutsuta, kyseessä olevaa konfiguraatiota ei koskaan oteta käyttöön tai polku on saavuttamaton mistään ulkoiselta pinnalta.

Standardoitu tapa kommunikoida tämä on VEX (Vulnerability Exploitability eXchange). VEX-lausuma ilmoittaa, tiettyä CVE:tä vastaan tietystä tuoteversiosta, yhden neljästä tilaarvosta: not_affected, affected, fixed tai under_investigation, perusteluineen (esim. vulnerable_code_not_in_execute_path). CycloneDX tukee VEX:ää natiivisti; SPDX tukee sitä CSAF-liitteen (Common Security Advisory Framework) kautta. Puolustusasiakas, joka tarkistaa SBOM:iasi, odottaa näkevänsä VEX-lausumia avoimia CVE:itä selittämässä — ei hiljaisuutta.

Operatiivinen työnkulku näyttää tältä: SBOM generoidaan rakennuksessa → haavoittuvuusskannaus OSV/NVD:tä vastaan → triage työkalussa kuten Dependency-Track → insinööri tekee VEX-lausuman perusteluineen → VEX liitetään allekirjoitettuna in-toto-todistuksena SBOM:n rinnalle. Asiakkaan tarkistaja näkee johdonmukaisen tarinan jokaiselle CVE:lle.

Keskeinen havainto: Puolustusputki, joka toimittaa SBOM:eja ilman VEX-lausumia, hukkuttaa asiakkaan meluun. Kuuden kuukauden sisällä asiakas lopettaa SBOM:ien lukemisen, koska hän ei pysty erottamaan signaalia taustasta. Toimittaja, joka toimittaa SBOM + VEX:n, saa akkreditoinnin; toimittaja, joka toimittaa pelkän SBOM:n, saa korjauspyynnön jokaiselle "korkean" CVE:n transitiivisessa Go-moduulissa. Triage omat haavoittuvuutesi — DevSecOps- ja zero-trust-asentosi arvioidaan sen perusteella, kuinka hyvin korreloit, ei kuinka monta CVE:tä nostat esiin.

6. CI-porttlogiikka

SBOM:t ja VEX-lausumat valvovat toimitusketjuhygieniaa vain silloin, kun putki estää niiden perusteella. Portti sijaitsee "rakennuksen onnistuminen" ja "julkaisun artefaktin edistäminen" välissä. Nykyaikaiset tiimit kirjoittavat portin politiikkana Regossa (Open Policy Agent) tai Kyverno:ssa, arvioituna SBOM:n ja VEX-syötteiden suhteen.

Toimiva politiikka valvoo neljää sääntöä. Yksi: ei kriittisiä CVE:itä ilman VEX-perustetta. Kaksi: ei komponentteja kiellettyjä lisenssiperheitä koskevalta kiellolistalta (AGPL omistusoikeudellisissa toimituksissa, mitä tahansa Yhdysvaltain vientirajoitetulla alkuperälausekkeella). Kolme: ei komponentteja sanktioitujen maiden rekistereistä (tässä asuu NDAA 1655 — kiinalaisperäiset paketit merkitään automaattisesti). Neljä: SBOM:n on oltava allekirjoitettu, rakennusprovenanssin on väitettävä SLSA 3 tai korkeampi, ja Rekor-läpinäkyvyyslokikirjauksen on oltava olemassa.

Poikkeukset ovat paikka, jossa useimmat politiikat epäonnistuvat käytännössä. Yleinen "ohita tämä CVE ikuisesti" -ohitus on auditointiepäonnistumismalli. Auditoinneissa selviävä malli on poikkeus perusteluineen ja vanhentumisaikoineen: poikkeustiedosto sijaitsee repossa, se katselmoidaan pull requestissa, nimeää CVE:n ja artefaktin, sisältää kirjallisen perustelun (samat VEX-perustelu-kentät) ja sillä on vanhentumispäivämäärä. Putki hyväksyy poikkeuksen vain sen ollessa voimassa. Tarkistajat rakastavat tätä mallia, koska se tuottaa kirjallisen jäljen riskipäätöksistä; insinöörit sietävät sitä, koska se on rajallinen työ.

7. Asiakastoimitukset

SBOM ei ole vain rakennusartefakti — se on sopimustoimitettava. Puolustussopimukset vuonna 2026 sisältävät rutiininomaisesti lausekkeita SBOM-formaatista, allekirjoittamisesta, toimitusmenetelmästä ja päivitystahdista. Formaattineuvottelu tapahtuu tyypillisesti sopimuksen laadintavaiheessa: toimittaja ehdottaa CycloneDX 1.5 JSON:ia, asiakas pyytää SPDX 2.3:a, koska heidän alavirran työkalu sitä vaatii, ja toimittaja sitoutuu kaksoisemissioon. Toimitus tapahtuu yleensä asiakkaan hallitseman rekisterin tai portaalin kautta — ei koskaan sähköpostin liitetiedostoina, jotka asiakkaan tietoturvapolitiikka kieltää.

Toistuva päivitysvelvoite on lauseke, jota useimmat toimittajat aliarvioivat. NDAA-linjatut sopimukset vaativat tyypillisesti päivitetyn SBOM:n jokaisen korjausjulkaisun, jokaisen neljännesvuosittaisen huoltodropin yhteydessä ja 72 tunnin sisällä minkä tahansa soveltuvuusalueen CVE-julkistamisen jälkeen. Jos julkaisuprosessisi kestää viikon, et pysty täyttämään 72 tunnin määräaikaa. Korjaus on SBOM-emission tekeminen automaattiseksi jokaisen julkaisun yhteydessä, mukaan lukien korjausjulkaisut, jotta SBOM on aina ajan tasalla asiakkaan käyttämän binäärin kanssa. Toimittajat, jotka yrittävät regeneroida SBOM:eja manuaalisesti julkaisun jälkeen, päätyvät selittämään aukkoja akkreditointitarkistajille.

8. Auditoinneista selviäminen

Akkreditointitarkistaja saapuu. He esittävät kolme kysymystä. Näytä minulle SBOM versiosta 2.4.1, jota ajamme tuotannossa. Rekisterisi palauttaa allekirjoitetun CycloneDX-dokumentin in-toto-todistuksella, joka osoittaa asiakkaan asentamaan binääritiivisteeseen. Näytä minulle VEX-lausumat jokaiselle SBOM:n "korkean" CVE:lle. Rekisterisi palauttaa VEX-nippupaketin perusteluineen ja päivämäärineen. Näytä minulle, miten tietäisit tänään, jos tämän SBOM:n komponenttia vastaan julkistettaisiin uusi CVE. Näytät heille jatkuvan skannauksen, joka ajetaan SBOM-korpusta vastaan, ja SLA:n asiakasnotifikaatiolle.

Putki, joka vastaa niihin kolmeen kysymykseen puhtaasti, on putki, joka selviää. Putki, joka ei pysty — koska SBOM generoitiin jälkikäteen, tai VEX-lausumat sijaitsevat laskentataulukossa, tai kukaan ei seuraa CVE-julkistuksia julkaistujen SBOM:ien suhteen — on putki, joka menettää sopimuksen uusimisessa. Investointi on rajallinen; seuraus sen tekemättä jättämisestä ei ole.