SBOM CRA:ssa: tiedosto aloittaa prosessin, ei päätä sitä

Cyber Resilience Act edellyttää valmistajilta digitaalisia elementtejä sisältävien tuotteiden haavoittuvuuksien ja komponenttien tunnistamista ja dokumentointia. Tähän kuuluu ohjelmiston osaluettelon eli Software Bill of Materials (SBOM) -luettelon laatiminen yleisesti käytetyssä, koneellisesti luettavassa muodossa, joka kattaa vähintään ylimmän tason riippuvuudet.

Tiedoston luominen ei päätä työtä. SBOM muuttuu toiminnallisesti hyödylliseksi, kun tiimi pystyy siirtymään komponentista todelliseen tuotejulkaisuun, haavoittuvuuteen, vaikutuspäätökseen, korjaukseen ja todentavaan näyttöön.

Mitä CRA sanoo SBOM-luetteloista

Liitteen I osa II edellyttää valmistajilta haavoittuvuuksien ja tuotekomponenttien tunnistamista ja dokumentointia, myös SBOM-luettelon avulla.

Liite VII yhdistää SBOM-luettelon haavoittuvuuksien käsittelyprosessien tekniseen dokumentaatioon. Markkinavalvontaviranomainen voi myös pyytää asianomaista SBOM-luetteloa, kun sitä tarvitaan olennaisten kyberturvallisuusvaatimusten täyttymisen todentamiseen.

Tärkeä ero: asetus ei sano, että jokaisen valmistajan on julkaistava koko SBOM jokaiselle käyttäjälle. Liite II pyytää tietoa SBOM-luettelon saatavuuspaikasta jos valmistaja päättää asettaa sen käyttäjän saataville.

Tiedostomuoto on vasta ensimmäinen päätös

CycloneDX ja SPDX ovat yleisesti käytettyjä SBOM-muotoja. Muodon valinta ei ratkaise elinkaaren hallintaa.

Kirjaa jokaisesta SBOM-aineistosta vähintään:

• tuote;
• julkaisu/versio;
• luontiaika;
• työkalu ja luontiprosessi;
• skannauksen laajuus;
• tiedostomuodon versio;
• tallennuspaikka;
• aineiston tunniste tai tiiviste;
• validoinnin tila.

Ilman yhteyttä julkaisuun voi myöhemmin olla mahdotonta selvittää, toimitettiinko komponentti todella asiakkaalle.

Arvoa luova työnkulku

komponentti → komponentin versio → tuotejulkaisu → haavoittuvuus → vaikutusten arviointi → päätös → toimi → korjaus → testi → näyttö → viestintä

Esimerkki:

1. työkalut tunnistavat kirjaston X julkaisussa 4.8.1;
2. haavoittuvuus julkistetaan X-kirjaston tietyille versioille;
3. tiimi vahvistaa, sisältyykö kyseinen koodi tuotteeseen ja onko sillä merkitystä tuotteessa;
4. vaikutusten arviointi ja priorisointipäätös kirjataan;
5. korjaus liitetään tiettyyn muutokseen ja tuotejulkaisuun;
6. testi todentaa tuloksen;
7. todentava näyttö liitetään tapaukseen;
8. jos 14 artiklan kriteerit täyttyvät, erillinen CRA-ilmoitustyönkulku käynnistyy.

Ei CVE-merkintä eikä SBOM itsessään ratkaise vaikutusta tuotteeseen tiimin puolesta.

SBOM ja toimittajat

Komponentti voi tulla avoimesta lähdekoodista, kaupalliselta toimittajalta tai toiselta sisäiseltä tiimiltä. Kypsä prosessi yhdistää siksi riippuvuuden seuraaviin:

• toimittaja tai lähde;
• ylläpidon tila;
• haavoittuvuustiedon lähde;
• päivittämisestä vastaava henkilö;
• korvaava vaihtoehto, jos komponentin tuki päättyy.

Tällä on merkitystä myös tukijaksoa koskeville päätöksille. CRA sallii ydintoimintoja tarjoavien integroitujen kolmannen osapuolen komponenttien tukijaksojen huomioimisen.

Älä muuta GRC:tä uudeksi skanneriksi

Pulsarin ei pitäisi kilpailla ohjelmistokoostumuksen analyysityökalujen, riippuvuusskannerien ja SBOM-generaattorien kanssa. Nämä työkalut tunnistavat ja kuvaavat komponentit.

GRC tuo arvoa, kun se käyttää tuloksia hallittujen päätösten tukena:

• liittää aineiston tuotteeseen ja julkaisuun;
• yhdistää riskin ja toimenpiteen;
• määrittää omistajan ja määräajan;
• säilyttää päätöksen;
• liittää korjauksen ja testin näytön;
• tarjoaa historian tarkastusta varten.

Käytä Pulsaria komponenttien käsittelyyn liittyvien riskien, toimien, toimittajien, asiakirjojen, näytön ja raporttien järjestämiseen. Sovi CycloneDX/SPDX-muotojen tuesta palvelusi laajuuden puitteissa ennen SBOM-tuonnin suunnittelua.

Tarkista nykyinen prosessisi

• Pystytkö tunnistamaan tietyn julkaisun SBOM-luettelon?
• Onko sen luominen toistettavissa?
• Onko jokaisella kriittisellä komponentilla omistaja tai lähde?
• Voidaanko haavoittuvuus liittää kyseiseen tuotejulkaisuun?
• Onko riskin hyväksymispäätöksellä hyväksyjä ja tarkistuspäivämäärä?
• Onko korjauksesta todentava näyttö?
• Onko haavoittuvuuksien käsittelystä CRA-ilmoittamisen arviointiin siirtymiselle selkeä sääntö?

Tutustu Pulsar GRC:hen yhden näyttötyönkulun kautta

Aiheeseen liittyvät oppaat

• CRA:n 24/72 tunnin ilmoittaminen
• CRA:n tekninen dokumentaatio
• CRA:n tukijaksot

Kuvitteellinen julkaisu kahdella komponenttiluettelolla

Kehitystiimi luo SBOM:n lähdekoodista, mutta toimitettu paketti sisältää lisäksi suoritusympäristön komponentin. Konttia tarkastava toinen työkalu löytää tämän osan. Molemmat luettelot voivat olla oikein omassa rajauksessaan, mutta vain ensimmäisen säilyttäminen jättää julkaisun kuvauksen puutteelliseksi. Tämä on prosessiesimerkki, ei todellisen asiakkaan tekninen tapahtuma.

Määritä ensin, kuvaako luettelo lähdekoodia, rakennettua artefaktia, konttia, asennuspakettia vai laiteohjelmistoa. Eri kerrokset voivat tarvita eri työkaluja. Yksi tiedosto nimellä ”uusin SBOM” ei näytä yhteyttä asiakkaalle toimitettuun versioon. Säilytä jokaisen artefaktin tuote, julkaisu, rajaus ja luomisen peruste.

Luotettava luominen tarvitsee toistettavan työn

Määritä luettelon luomisen paikka julkaisuprosessissa. Jos se valmistuu ennen lopullista pakettia, sisältö voi olla toinen. Tarkista riippuvuudet, ympäristö ja lisätyt tiedostot. Vertaa tarvittaessa luetteloa toimitettavaan artefaktiin. Tämä on tekninen tarkastus ja kuuluu kehitystyökalujen tehtäviin, vaikka sen tulos käytetään GRC:ssä.

Säilytä työkalu, versio, tärkeät asetukset ja rajaus. Muodon tarkastus löytää virheellisiä kenttiä, mutta se ei osoita komponenttien täydellistä kuvausta. Koneluettava väärän tuotteen luettelo on edelleen väärä näyttö. Organisaation pitää tietää, mitä työkalu näki ja mikä jäi sen ulkopuolelle.

Komponentin tunnistus tukee myöhempää hakua

Nimen, version ja lähteen on oltava riittävän tarkat turvatiedon yhdistämiseen. Sama lyhyt nimi voi tarkoittaa useaa pakettia. Heikko tunniste voi tuottaa väärän hälytyksen tai jättää vaikutuksen havaitsematta. Tekninen tiimi valitsee ympäristöön sopivan tunnistustavan ja kirjaa sen rajoitukset.

Älä muuta skannerin jokaista osumaa vahvistetuksi tuotevaikutukseksi. Tarkista toimitettu versio, käytettävä toiminto ja olemassa oleva suojaus. Säilytä teknisen arvion lähde. Jos vaikutus ei selviä, määritä lisätutkimus ja tarvittava aineisto. Mukavin tila ilman perustetta ei ole hyväksyttävä päätös.

Riippuvuudella tulee olla vastuuhenkilö

Kaupallisen komponentin toimittajalta kysytään ylläpidon, turvatiedon ja päivityksen järjestelyä. Avoimen lähdekoodin osalle määritetään sisäinen omistaja. Avoimuus ei tarkoita, että ulkopuolinen kehittäjä vastaa sinun tuotteen tukijaksosta. Organisaation tulee ratkaista, miten osa ylläpidetään tai tarvittaessa korvataan.

Jos tärkeän osan tuki päättyy ennen tuotteen suunniteltua tuen loppua, arvioi päivitys, korvaaminen tai muu ylläpito. Päätös tarvitsee teknisen vaikutuksen, ajan ja kustannuksen. Merkintä ”toimittajariski” ei osoita, pystyykö yritys täyttämään käyttäjälle annetun tukilupauksen. Tehtävän pitää johtaa todelliseen vaihtoehtojen arvioon.

Haavoittuvuustyö käyttää luetteloa lähtötietona

Kuvitteellisessa tapauksessa julkaistaan kirjaston turvatiedote. Kehittäjä löytää kaksi julkaisua, joissa kirjasto esiintyy, ja yhden, jossa sitä ei enää ole. Tiimi tarkistaa vaikutuksen ja valitsee korjauksen. Ilmoitusvelvollisuuden arvio on erillinen vaihe, jos kriteerit voivat täyttyä. SBOM ei tee tätä oikeudellista ratkaisua.

Korjauksen näyttö yhdistyy uuteen julkaisuun ja testiin. Versionumeron muuttaminen ei osoita, että uusi paketti meni asiakkaalle tai suojaus toimii. Säilytä testit ja käyttäjäohje tarvittaessa. Näytä myös vanhat versiot, joiden käsittely jatkuu. Muuten uusin onnistunut julkaisu voi peittää edelleen käytössä olevan tuotteen ongelman.

Vertaa julkaisuja sisällöllisesti

SBOM-ero näyttää lisätyn, poistetun tai päivitetyn osan. Se ei kerro automaattisesti muutoksen syytä tai riskin vähenemistä. Yhdistä ero kehitysmerkintään ja päätökseen. Uusi kiireellä lisätty komponentti tarvitsee ylläpidon ja turvalähteen järjestelyn siinä missä aiempikin riippuvuus.

Vertailun rajauksen on oltava johdonmukainen. Jos vanha luettelo tulee lähdekoodista ja uusi kontista, ero voi johtua menetelmästä eikä tuotteesta. Kerro tämä ennen riskien priorisointia. Lisää löytyneitä osia ei automaattisesti tarkoita riskin kasvua; työkalu saattoi vain nähdä enemmän kerroksia.

Pääsy ja jakaminen vaativat rajauksen

Komponenttiluettelo voi sisältää tietoa, jota organisaatio ei halua julkaista kaikille. Määritä asiakkaan, arvioijan ja sisäisen käyttäjän aineisto erikseen. Asetuksen ja viranomaispyynnön vaatimukset arvioi pätevä vastuuhenkilö. Tekninen mahdollisuus julkaista tiedosto ei yksin ole julkaisupakko.

Pulsar jäsentää osiin liittyviä riskejä, päätöksiä, tehtäviä ja näyttöä. Se ei korvaa luettelon generaattoria tai ohjelmistokoostumuksen analyysiä. Tarkista tietyn muodon tuonti tai integraatio voimassa olevasta palvelulaajuudesta. Älä rakenna työnkulkua suunnitellun ominaisuuden oletukselle.

Hyväksymistesti kahdella julkaisulla

Valitse kuvitteellinen turvatiedote ja kaksi todellista rakennetta vastaavaa esimerkkijulkaisua. Tiimin pitää löytää osa, vahvistaa versio, perustella vaikutus ja määrätä jatkotoimi. Lisää samanniminen toinen komponentti väärän osuman testaamiseksi. Onnistuminen tarkoittaa perusteltua ratkaisua, ei suurinta mahdollista haavoittuvuuksien määrää.

Anna tulos toiselle arvioijalle. Hänen tulee nähdä lähde, julkaisu, tekninen päätös ja korjauksen testi. Jos yhteys ymmärretään vain tekijän selityksestä, täydennä merkintää. Näin tiedosto muuttuu käytettäväksi tuotetyön lähtötiedoksi. Lopullinen vastuu analyysistä ja tuotteen korjauksesta pysyy teknisellä sekä päätöksen hyväksyvällä tiimillä.

Artefaktin vastaanoton työlehti

Tarkastus	Vahvistettava seikka	Tavallinen puute
Tuote	luettelo kuvaa oikeaa tarjousta	nimi kopioidaan toisesta projektista
Julkaisu	versio ja toimitettu artefakti on yhdistetty	tiedosto luodaan ennen lopullista rakennetta
Rajaus	tarkastetut kerrokset on nimetty	suoritusympäristön osa jää pois
Tunniste	osan lähde ja versio on yksilöity	lyhyt nimi vastaa montaa kirjastoa
Toistettavuus	työkalu ja asetukset on tallennettu	tulos riippuu dokumentoimattomasta käsityöstä
Arvio	ihminen hyväksyy käytön rajat	muodon tarkastus tulkitaan täydellisyydeksi

Tämä työlehti ei korvaa formaatin spesifikaatiota. Se kertoo, sopiiko tiedosto organisaation työn lähtötiedoksi. Puuttuva kohta saa oman korjauksen ennen luotettavan tilan merkintää. Tarkastaja voi hyväksyä rajatun aineiston, jos sen tarkoitus ja rajat ovat selvät. Silloin sitä ei käytetä laajemman johtopäätöksen näyttönä.

Säilytä vanhojen julkaisujen luettelot

Vanha julkaisu voi olla edelleen asiakkaan käytössä. Uusi haavoittuvuustieto voi siksi tarvita sen koostumuksen. Jos yritys säilyttää vain uusimman tiedoston, vaikutusarvio hidastuu tai jää oletukseen. Yhdistä säilytys tuotteen elinkaareen sekä sovellettaviin ehtoihin. Käyttöoikeus ja arkiston käytettävyys tarkastetaan omana työnä.

Testaa arkisto yhdellä aiemmalla julkaisulla. Löytyykö oikea luettelo, tunnistetaanko rajaus ja voidaanko komponentin versio vahvistaa? Pelkkä varmuuskopion olemassaolo ei osoita nopeaa tai oikeaa aineiston palautusta. Jos koe epäonnistuu, määritä palautuksen tai rekisterin korjaus ja kokeile tulosta uudelleen samasta tilanteesta.

Älä korvaa julkaisufaktaa muuttuvalla turvatiedolla

SBOM kertoo tietyn julkaisun koostumuksen. Komponenttia koskeva turvallisuustieto voi muuttua ilman tuotteen muutosta. Pidä nämä erillisinä. Säilytä julkaistun paketin faktat ja lisää myöhempi vaikutusarvio omalla ajallaan. Näin voidaan kertoa sekä tuotteen sisältö että se, mitä yritys myöhemmin oppi siitä.

Uusi analyysi voi kumota aiemman oletuksen. Tallenna muutos ja sen lähde, älä poista alkuperäistä päätöstä huomaamatta. Historiallinen arvio auttaa ymmärtämään, miksi korjaus priorisoitiin aiemmin tietyllä tavalla. Nykyinen tieto ei tarkoita, että sama tieto olisi ollut käytettävissä alusta asti. Tämä ero vaikuttaa päätöksen arviointiin.

Toimittajan luettelo tarvitsee kokoonpanon tarkastuksen

Kysy toimittajalta, mitä ostettua vaihtoehtoa tiedosto kuvaa. Yleinen tuoteperheen luettelo voi sisältää osia, joita ei toimitettu, tai puuttuvia asiakkaan lisäosia. ”SBOM vastaanotettu” ei osoita sopivuutta. Pätevän arvioijan tulee verrata kokoonpanoa ja päättää tarvittava lisäkysymys tai oma tekninen tarkastus riskin mukaan.

Säilytä kysymys ja vastaus. Jos toimittaja ei vahvista osaa, kyseessä on näkyvä tietopuute. Työkalu ei saa täyttää sitä keksityllä versiolla. Määritä sisäinen omistaja ja valittu väliaikainen toiminta. Näin avoin kysymys ei muutu hiljaiseksi hyväksynnäksi seuraavassa koontiraportissa tai automaattisesti laaditussa yhteenvedossa.

Mittaa hakua yhdessä väärien osumien kanssa

Pilotin päämittari voi olla aika vaikuttuneen julkaisun tunnistamiseen. Laske myös väärät osumat ja tutkimatta jäävät vaihtoehdot. Laaja haku voi kuormittaa tiimiä ja kapea haku jättää todellisen vaikutuksen huomaamatta. Molemmat tarvitsevat identiteetin ja analyysin laatua, eivät vain nopeampaa raportin luomista. Mittarin valinta ei todista palvelun tiettyä hyötyä.

Tarkasta, kuka pystyy jatkamaan analyysiä omistajan poissa ollessa. Seuraavan henkilön tulee nähdä lähde, kysymys, arvio ja avoin tehtävä. Henkilökohtainen muistilista voi olla apu, mutta ei ainoa pysyvä päätöksen paikka. Säilytetty tiedosto muuttuu organisaation tiedoksi vasta, kun sen käyttö ja merkitys eivät jää yhden ihmisen muistiin.

Testaa korjauksen yhteys toimitukseen

Valitse komponentin päivitys ja seuraa se lähdemuutoksesta rakennettuun pakettiin sekä testiin. Varmista, ettei uusi luettelo kuvaa vain tavoiteltua sisältöä. Jos asiakkaan jakelu jäi vanhaan pakettiin, tekninen muutos ei vielä ratkaissut hänen tuotettaan. Näytä tämä raja eikä yhtä yleistä tilaa ”korjattu”. Päätöksen omistaja arvioi tarvittavan jatkon.

Arvioi analyysin jatkuvuus

Anna seuraavalle vastuuhenkilölle yksi avoin komponenttikysymys ja normaali käyttöoikeus. Hänen tulee löytää lähde, tunnistaa julkaisu ja kertoa seuraava tehtävä. Jos tulos jää epäselväksi, täydennä juuri puuttuva yhteys. Uusi yleinen raportti ei korvaa tärkeän faktan tai päätöksen puutetta.

Säilytä tämän kokeen rajaus ja tulos. Se voi osoittaa yhden työnkulun käytettävyyden, mutta ei koko portfolion täydellistä komponenttikuvausta. Toisen tuotteen lisääminen tarvitsee saman tarkastuksen oikeilla lähtötiedoilla. Näin rajattu onnistuminen ei muutu perusteettomaksi yleiseksi lupaukseksi, ja tiimi saa selkeän perustan seuraavan parannuksen valintaan.

Lähteet

• Asetus (EU) 2024/2847 — liitteet I, II ja VII
• ENISA — SBOM-käyttöönoton tilanne 2026

Lähteet tarkistettu: 2. lokakuuta 2026.

• Pulsar GRC — pääsy, tietojen eristäminen ja vienti (puolaksi)