SBOM vaatimustenmukaisuuden näyttönä: ISO 27001, SOC 2 ja NIS2

Näyttö ei ole vaatimustenmukaisuutta

Kontrolli täyttyy prosessilla, joka toimii. Näyttö osoittaa, että se toimii. SBOM osoittaa yhden tietyn asian: mitä tietty julkaisu sisälsi. Se ei kerro mitään pääsynhallinnasta, poikkeamiin reagoinnista tai siitä, toimiko kukaan löydöksen perusteella.

Se voi myös olla virheellinen tavalla, jota kukaan ei huomaa. Väärät tiedostot lukenut generaattori tuottaa kelvollisen SBOM:n, josta puuttuu puolet tuotteesta. Tuon SBOM:n haavoittuvuusskannaus on puhdas, compliance-alusta näkee, että skannaus ajettiin, ja jokainen tarkistus näyttää vihreää. Mitä vihreä SOC 2 -SBOM-tarkistus varmentaa käy tämän virheen läpi yksityiskohtaisesti.

SBOM:sta saatava näyttö on pätevää, kun se on:

1. Sidottu julkaisuun. Yksi SBOM jokaista toimittamaasi versiota kohden, ei yksi koko repositoriolle.
2. Kattava, tai kertoo, mitä siitä puuttuu. SBOM:iin, joka kertoo puutteensa, voi luottaa siltä osin kuin se listaa.
3. Säilytetty auditoinnin kattaman ajanjakson ajan. Viime maaliskuuta otantana tarkasteleva auditoija tarvitsee viime maaliskuun SBOM:n.
4. Tarkistettu uudelleen, kun uusia haavoittuvuuksia ilmenee. Luettelo, jota kukaan ei vertaa uusiin tietoturvatiedotteisiin, todistaa vähän haavoittuvuuksien hallinnasta.

Mitä SBOM sisältää, kerrotaan sivulla mikä on SBOM. Teollisuustuotteiden ja Yhdysvaltain liittovaltion ohjelmistojen turvallisen kehityksen viitekehyksistä kerrotaan sivuilla IEC 62443-4-1 ja NIST SSDF.

ISO/IEC 27001:2022

ISO/IEC 27001 on standardi, jonka mukaan tietoturvallisuuden hallintajärjestelmä sertifioidaan (sanasto). Liitteessä A on 93 kontrollia; organisaatio valitsee ne, joita sen riskinarviointi edellyttää, ja kirjaa ne soveltamislausumaansa (Statement of Applicability). ISO/IEC 27002:2022 antaa toteutusohjeet. Kumpikaan ei mainitse SBOM:ia. Taulukko lainaa vain kontrollien nimet ja kertoo lyhyesti, mistä kussakin kontrollissa on kyse.

Kontrolli	Mistä siinä on kyse	Miten SBOM tai build-kirjaus toimii näyttönä	Mitä se ei kata
5.9 "Inventory of information and other associated assets"	Sen tietäminen, mitä omaisuutta sinulla on ja kuka sen omistaa	Toimittamasi ja ajamasi ohjelmisto on omaisuutta. Julkaisukohtainen komponenttiluettelo on inventaario sen sisällöstä.	Laitteistoa, tietoja, ihmisiä ja palveluja
5.19 "Information security in supplier relationships", 5.20 "Addressing information security within supplier agreements", 5.21 "Managing information security in the ICT supply chain", 5.22 "Monitoring, review and change management of supplier services"	Toimittajiin ja TVT-toimitusketjuun liittyvän riskin hallinta	Kaksi suuntaa. Ostajana voit vaatia toimittajilta SBOM:ja ja valvoa niitä. Toimittajana SBOM:si on se, mitä sertifioidun asiakkaasi toimitusketjuprosessi sinulta pyytää. Avoimen lähdekoodin komponentit ovat osa TVT-toimitusketjua, mutta niihin ei liity toimittajasopimusta, ja juuri siksi niiden inventaario on tärkeä.	Sopimuksia, toimittaja-arviointeja ja katselmuksia
8.8 "Management of technical vulnerabilities"	Tiedon hankkiminen haavoittuvuuksista, oman altistumisen arviointi ja toimiminen sen mukaan	Ajantasainen komponenttiluettelo, jota verrataan tietoturvatiedotteisiin ja joka arvioidaan uudelleen uusien ilmestyessä, sekä kirjaus siitä, mitkä julkaisut sisälsivät haavoittuvan version ja mistä lähtien	Infrastruktuurisi paikkaamista, palvelinten skannausta eikä itse päätöksiä
8.25 "Secure development life cycle"	Säännöt ohjelmistojen ja järjestelmien turvalliselle kehittämiselle	Kirjattu, toistettava julkaisuprosessi: jokainen julkaisu rakennetaan samassa putkessa, ja sillä on oma SBOM	Suurinta osaa kontrollista: koulutusta, ympäristöjä, suunnittelua ja katselmointia
8.26 "Application security requirements", 8.27 "Secure system architecture and engineering principles", 8.28 "Secure coding"	Vaatimukset, suunnittelu ja koodi	Ei suoraan. Nämä koskevat sitä, mitä kirjoitat, eivät sitä, mitä tuot mukaan.	Ei mitään siitä: näyttönä ovat koodikatselmoinnit, SAST ja suunnitteludokumentit
8.29 "Security testing in development and acceptance"	Tietoturvan testaaminen ennen julkaisua	Käytäntöportti, joka estää buildin haavoittuvuuslöydöksen perusteella, on kirjattu testi tuloksineen	Toiminnallista tietoturvatestausta, penetraatiotestejä
8.30 "Outsourced development"	Ulkoistetun kehityksen ohjaus ja valvonta	Putkessasi rakennettu ulkoistettu koodi saa saman SBOM:n ja samat tarkistukset kuin oma koodisi	Sopimusta, toimittajan omia käytäntöjä

Ole rehellinen kontrollien 8.25–8.30 suhteen: suurin osa siitä, mitä ne edellyttävät, on SBOM:n ulkopuolella. Liioittelu on nopein tapa menettää auditoijan luottamus kaikkeen muuhunkin.

Esimerkki: auditoija kysyy kontrollista 8.8

"Mistä tiedätte, kun uusi haavoittuvuus koskee jo toimittamaanne tuotetta?" Tässä on näyttöketju yhdelle tietoturvatiedotteelle ja tieto siitä, mistä kukin lenkki tulee.

Vaihe	Näyttö	Lähde
1. Julkaisun sisältö	Version 4.2 SBOM, jonka sen tuottanut buildi kirjasi	Build-työkalusi
2. Osuma tietoturvatiedotteeseen	Uusi CVE, joka julkaistiin SBOM:ssa olevalle kirjastolle ja jota verrataan sen paketti-URL:n perusteella	Haavoittuvuusvalvontasi
3. Altistumisikkuna	Jokainen buildi, joka sisälsi haavoittuvan version, ja ensimmäisen päivämäärä	Build-historiasi
4. Päätös	Kuka sen arvioi, milloin ja millä tuloksella: korjaus, lievennys tai ei koske, perusteineen	Prosessisi ja sen kirjaukset
5. Korjaus	Versio 4.2.1, jonka SBOM ei enää sisällä haavoittuvaa versiota	Build-työkalusi

Työkalut voivat tuottaa vaiheet 1, 2, 3 ja 5. Vaihe 4 on prosessisi, ja juuri sitä auditoijat lukevat tarkimmin.

SOC 2

SOC 2 -raportti kertoo, täyttävätkö kontrollit AICPA:n Trust Services Criteria -kriteerit (2017, painopisteitä tarkistettu 2022). Kriteerit ovat lopputulosta kuvaavia lausumia. Ne eivät mainitse SBOM:ia, ja kahdessa niistä SBOM:sta on apua.

• CC7.1 edellyttää, että organisaatio käyttää havaitsemis- ja valvontamenettelyjä tunnistaakseen (1) konfiguraatiomuutokset, joiden seurauksena syntyy uusia haavoittuvuuksia, ja (2) alttiuden äskettäin löydetyille haavoittuvuuksille. Näyttö: julkaisukohtainen SBOM, joka arvioidaan uudelleen uusia tietoturvatiedotteita vasten, ja kirjaus siitä, miten kukin löydös käsiteltiin.
• CC8.1 kattaa muutostenhallinnan: miten infrastruktuurin, tietojen, ohjelmistojen ja menettelyjen muutokset valtuutetaan, kehitetään tai hankitaan, testataan, hyväksytään ja toteutetaan. Näyttö: jokainen julkaisu rakennetaan kirjatussa putkessa, riippuvuuksien muutos näkyy buildista toiseen, ja käytäntöportit toimivat kontrollina sille, mitä saa toimittaa.

Kriteerejä uudistetaan. Lokakuussa 2026 AICPA julkaisi vuoden 2027 Trust Services Criteria -kriteerien lausuntoluonnoksen, jossa kriteerit rakennetaan kohdennetusti uudelleen. Kommentit on jätettävä 15.1.2027 mennessä, ja ehdotettu voimaantulo koskee toimeksiantoja, jotka alkavat 31.12.2027 tai sen jälkeen. Kyse on luonnoksesta, ja kriteerien numerot voivat muuttua: tarkista lopullinen teksti ennen kuin kohdistat näyttöä uusiin numeroihin.

Jos käytät jo SOC 2 -alustaa, pidä se. Kysymys on siitä, mitä sen tarkistusten taustalla oleva SBOM osoittaa: SOC 2 -SBOM-tarkistukset vertailussa.

NIS2

NIS2-direktiiviä (EU) 2022/2555 sovelletaan sen luettelemien alojen keskeisiin ja tärkeisiin toimijoihin. Jos luet tätä ohjelmisto- tai laitetoimittajana, et yleensä itse kuulu sen soveltamisalaan. Asiakkaasi kuuluu, ja sen velvoitteet tavoittavat sinut kysymyksinä. 21 artiklassa säädetään kyberturvallisuusriskien hallintatoimenpiteistä, ja kolmesta kohdasta syntyy suurin osa näistä kysymyksistä:

• 21 artiklan 2 kohdan d alakohta: "toimitusketjun turvallisuus, mukaan lukien kunkin toimijan ja sen välittömien toimittajien tai palveluntarjoajien välisten suhteiden turvallisuusnäkökohdat".
• 21 artiklan 2 kohdan e alakohta: "verkko- ja tietojärjestelmien hankinnan, kehittämisen ja ylläpidon turvallisuus, mukaan lukien haavoittuvuuksien käsittely ja julkistaminen".
• 21 artiklan 3 kohta: toimijat ottavat huomioon "kullekin välittömälle toimittajalle ja palveluntarjoajalle ominaiset haavoittuvuudet, niiden tuotteiden yleisen laadun sekä toimittajiensa ja palveluntarjoajiensa kyberturvallisuuskäytännöt, mukaan lukien tuotekehityksen suojausmenettelyt". Juuri tästä virkkeestä tulee pöydällesi päätyvä kyselylomake.

Täytäntöönpanoasetus (EU) 2024/2690

Komission täytäntöönpanoasetuksessa (EU) 2024/2690, annettu 17.10.2024, vahvistetaan 21 artiklan 2 kohdan toimenpiteiden tekniset ja menetelmiä koskevat vaatimukset DNS-palveluntarjoajille, aluetunnusrekistereille, pilvipalvelujen tarjoajille, datakeskuspalvelujen tarjoajille, sisällönjakeluverkkojen tarjoajille, hallintapalvelun tarjoajille, tietoturvapalveluntarjoajille, verkossa toimiville markkinapaikoille, verkossa toimiville hakukoneille, sosiaalisen verkostoitumisen palvelualustoille ja luottamuspalvelujen tarjoajille. Se ei sido muita NIS2-aloja, mutta se on yksityiskohtaisin julkinen kuvaus siitä, mitä "toimitusketjun turvallisuus" tarkoittaa, ja muut ostajat lainaavat siitä. Toimittajiin ulottuvat kohdat:

Liitteen kohta	Mitä siinä sanotaan	Mitä toimittajalta kysytään
5.1.2(a)	Toimittajien valintakriteereissä käsitellään "tavarantoimittajien ja palveluntarjoajien kyberturvallisuuskäytännöt, mukaan lukien niiden turvallista kehittämistä koskevat menettelyt"	Miten kehitätte turvallisesti, ja mistä tiedätte, mitä tuotteeseenne menee?
5.1.4(e) ja (f)	Sopimuksissa täsmennetään soveltuvin osin "oikeus suorittaa tarkastuksia tai saada tarkastuskertomuksia" sekä "tavarantoimittajien ja palveluntarjoajien velvollisuus korjata haavoittuvuudet, jotka aiheuttavat riskin" toimijalle	Käsittelettekö toimittamienne tuotteiden haavoittuvuudet, ja voimmeko nähdä näytön?
5.2	Rekisteri suorista toimittajista, joka sisältää "luettelon TVT-tuotteista, -palveluista ja -prosesseista", joita kukin tarjoaa	Mitä tuotteita ja versioita toimitatte meille?
6.1.2(c)	TVT-palvelujen tai -tuotteiden hankinnassa: "TVT-palveluissa tai -tuotteissa käytettäviä laitteisto- ja ohjelmistokomponentteja kuvaavat tiedot"	Mitä laitteisto- ja ohjelmistokomponentteja tuotteenne sisältää? Lähimpänä SBOM:ia mikään tämän sivun teksteistä, eikä sekään mainitse sitä nimeltä.
6.10	Haavoittuvuuksien käsittely: haavoittuvuustilannetta seurataan esimerkiksi CSIRT-yksiköiden tiedotteiden tai "tavarantoimittajien tai palveluntarjoajien toimittamien tietojen" avulla (6.10.2(a)), ja jos haavoittuvuus ei vaadi korjaavia toimenpiteitä, toimijan on "dokumentoitava ja perusteltava syy" siihen (6.10.3)	Miten kerrotte meille haavoittuvuuksista, ja miksi tämä ei ole ongelma?

Viimeinen kohta kuvaa ei koske -lausuman perusteineen. Juuri sen VEX-dokumentti sisältää, vaikka asetus ei nimeä mitään muotoa.

Esimerkki: NIS2-asiakkaan kyselylomake

Viisi kysymystä, joita asiakas johtaa näistä kohdista, ja näyttö, jonka toimittaja voi liittää vastaukseen. Osa vastauksista tulee työkalujesi säilyttämistä kirjauksista; toiset ovat kirjoittamiasi käytäntöjä.

Kysymys	Liitettävä näyttö	Kirjaus vai käytäntö
"Luetelkaa meille toimittamanne tuoteversion ohjelmistokomponentit." (6.1.2(c))	Kyseisen version SBOM CycloneDX- tai SPDX-muodossa, kattavuus ilmoitettuna	Kirjaus
"Kuvatkaa haavoittuvuuksien käsittelynne ja sen aikataulut." (5.1.4(f))	Haavoittuvuuksien käsittelymenettelysi vakavuustasoineen ja tavoiteaikoineen	Käytäntö
"Mitkä käyttämistämme versioista sisälsivät haavoittuvan kirjaston, ja mistä lähtien?" (6.10)	Build-historia, joka näyttää päivämäärineen jokaisen buildin, joka sisälsi komponentin	Kirjaus
"Miksi tämä CVE ei koske meitä?" (6.10)	Ei koske -lausuma perusteluineen, kuten "haavoittuvaa koodia ei ole mukana"	Kirjaus, joka perustuu arvioosi
"Miten tutkijat voivat ilmoittaa tuotteidenne haavoittuvuuksista?" (5.1.2(a))	Koordinoidun haavoittuvuuksien julkistamisen käytäntösi	Käytäntö

Yksi ero on hyvä pitää mielessä: EU:ssa myytävien digitaalisia elementtejä sisältävien tuotteiden osalta EU:n kyberkestävyyssäädös (Cyber Resilience Act) vaatii SBOM:n. NIS2 ei vaadi.

DORA, jos myyt rahoitusalan toimijoille

Digitaalista häiriönsietokykyä koskevaa asetusta (DORA), asetus (EU) 2022/2554, sovelletaan rahoitusalan toimijoihin, ei suoraan niiden toimittajiin. Rahoitusalan toimijoiden on tunnistettava ja dokumentoitava TVT-omaisuutensa ja niiden keskinäiset riippuvuudet ja pidettävä niistä inventaarioita (8 artiklan 1, 4 ja 6 kohta), hallittava kolmansiin osapuoliin liittyvää TVT-riskiä osana TVT-riskiään (28 artiklan 1 kohta), pidettävä tietorekisteriä kaikista TVT-palveluja koskevista sopimuksistaan (28 artiklan 3 kohta) ja sisällytettävä näihin sopimuksiin vähimmäisehdot (30 artikla). DORA ei mainitse SBOM:ia. Pankille ohjelmistoja toimittavalle julkaisukohtainen komponenttiluettelo auttaa asiakasta täyttämään 8 artiklan vaatimukset.

Yksi näyttökartta kaikille

Rivit ovat näytön osia; kukin solu kertoo kontrollin, kriteerin tai kohdan, jota näyttö tukee, tai "ei suoraan".

Näyttö	ISO/IEC 27001:2022	SOC 2	NIS2 ja 2024/2690	DORA
1. Julkaisukohtainen SBOM, kattavuus ilmoitettuna	5.9, 5.21, 8.8	CC7.1	21 art. 2 k. d; 6.1.2(c)	8 art. (asiakkaan inventaario)
2. Jatkuva uudelleenarviointi uusia tietoturvatiedotteita vasten	8.8	CC7.1	21 art. 2 k. e; 6.10	Ei suoraan
3. Build-historia: mitkä julkaisut sisälsivät komponentin ja mistä lähtien	8.8	CC7.1, CC8.1	6.10	Ei suoraan
4. Triage- ja ohjauskirjaukset	8.8	CC7.1	21 art. 2 k. e; 6.10	Ei suoraan
5. Ei koske -lausumat perusteineen	8.8	CC7.1	6.10	Ei suoraan
6. Käytäntöportit, jotka estävät buildin	8.25, 8.29	CC8.1	21 art. 2 k. e	Ei suoraan
7. Toimittajien SBOM:t valvottuina omiesi rinnalla	5.19, 5.21, 5.22	CC7.1	21 art. 2 k. d ja 3 k.; 5.2, 6.10	28 art. 1 k.
8. Buildin egress-käytäntö ja verkkokirjaukset	8.25	CC8.1	21 art. 2 k. d	Ei suoraan

Mitä SBOM ei todista

• Pääsynhallintaasi, poikkeamiin reagointia, liiketoiminnan jatkuvuutta, henkilöstöturvallisuutta, kryptografiaa tai fyysistä turvallisuutta.
• Että kukaan korjasi mitään. Se on prosessisi ja sen kirjaukset.
• Että oma koodisi on virheetöntä. Siitä näyttönä ovat koodikatselmoinnit, SAST ja testaus.
• Mitä on sellaisten binäärien sisällä, jotka sait ilman SBOM:ia.
• Että olet sertifioitu. SBOM ei ole sertifikaatti, ja työkalutoimittajasi sertifikaatti sertifioi toimittajan oman hallintajärjestelmän, ei sinua.

Miten CRACI sopii kuvaan

CRACI korvaa GitHubin ylläpitämät runnerisi ja kirjaa, mitä kukin buildi haki, joten SBOM tulee itse julkaisu­buildista, ja jokaisella jobilla on kattavuustila.

• Valvotut SBOM:t arvioidaan jatkuvasti uudelleen, kun uusia haavoittuvuuksia julkaistaan (haavoittuvuuksien seuranta).
• Build-historia näyttää säilytysaikasi puitteissa, mitkä buildit sisälsivät haavoittuvan riippuvuuden ja siten ajanjakson, jolloin olit altis. Jos auditointisi kattaa pidemmän ajanjakson, vie jokaisen julkaisun SBOM ja säilytä se julkaisun yhteydessä.
• Tietoturvatiimit tekevät löydettyjen haavoittuvuuksien triagen ja lähettävät ne korjauksesta vastaaville tiimeille, ja CRACI tukee VEX:iä sen kirjaamiseen, mihin tuotteisiin haavoittuvuus ei vaikuta.
• Käytäntöportit voivat estää buildin löydösten perusteella, myös buildin, joka sisältää tietyn CVE:n.
• Kolmansien osapuolten SBOM:ja voi lisätä, jotta ostettuja komponentteja valvotaan omien buildiesi rinnalla.
• SBOM:t viedään CycloneDX- tai SPDX-muodossa, ja API palauttaa SBOM:t, verkkojäljet ja alkuperätiedot. Egress-käytäntö kirjaa ja rajoittaa, mihin kukin buildi saa ottaa yhteyttä.

CRACI tuottaa näyttöä näistä kontrolleista. Se ei tee sinusta ISO 27001- tai SOC 2 -vaatimustenmukaista eikä valmista NIS2:een, eikä se ole compliance-automaatioalusta. CRACI:n oma sertifikaatti on erillinen asia: CRACI Corporation Oy:n CRACI-alustan kehitystä ja käyttöä koskeva tietoturvallisuuden hallintajärjestelmä on ISO/IEC 27001 -sertifioitu, ja sertifikaatin on myöntänyt Into Certification. Se kattaa sen, miten CRACI pyörittää palveluaan, ei organisaatiotasi tai tuotteitasi. Katso tietoturva CRACI:ssa ja koko alustan osalta miten CRACI toimii.

Milloin CRACI ei ole vastaus

• Buildisi eivät aja GitHub Actionsissa. Se on ainoa CI, jota CRACI tukee tällä hetkellä; muut CI-järjestelmät ovat tiekartalla.
• Tarvitset compliance-automaatioalustan käytännöille, käyttöoikeuksien katselmoinneille ja auditoijan työnkululle. Pidä tai osta sellainen; katso SOC 2 -SBOM-tarkistukset vertailussa.
• Näyttöpuutteesi ovat enimmäkseen organisatorisia: käytännöt, koulutus, poikkeamiin reagointi.
• Suurin toimittajariskisi ovat binäärit, jotka saat ilman SBOM:ia. Siihen vastaa binäärianalyysi.

Vastaatko yhden asiakkaan pyyntöön? Katso miten vastata asiakkaan SBOM-pyyntöön, opas komponenttitoimittajille ja tarkistuslista, jonka asiakkaasi käy läpi.

SBOM vaatimustenmukaisuuden näyttönä: usein kysytyt kysymykset

Vaatiiko ISO 27001 SBOM:n?

Ei. ISO/IEC 27001:2022 ei mainitse SBOM:ia. Liitteen A kontrollit 5.9 (inventaario), 5.21 (TVT-toimitusketju) ja 8.8 (tekniset haavoittuvuudet) edellyttävät lopputuloksia, joita SBOM tukee, ja organisaatio ja sen auditoija päättävät, mikä näyttö riittää.

Vaatiiko SOC 2 SBOM:n?

Ei. Trust Services Criteria -kriteerit ovat lopputulosta kuvaavia lausumia eivätkä mainitse SBOM:ia. Julkaisukohtainen SBOM, joka arvioidaan uudelleen uusia tietoturvatiedotteita vasten, on näyttöä kriteeristä CC7.1, ja kirjattu build-putki tukee muutostenhallintaa koskevaa kriteeriä CC8.1.

Vaatiiko NIS2 SBOM:n?

Ei. 21 artiklan 2 kohdan d alakohta edellyttää toimitusketjun turvallisuutta ja e alakohta haavoittuvuuksien käsittelyä mainitsematta SBOM:ia. Tiettyjä digitaalisten palvelujen tarjoajia koskeva täytäntöönpanoasetus (EU) 2024/2690 edellyttää kohdassa 6.1.2(c) tietoja TVT-tuotteiden laitteisto- ja ohjelmistokomponenteista, mutta ei sekään käytä sanaa SBOM.

Mitä ISO 27001:n liitteen A kontrolleja SBOM tukee?

Pääasiassa kontrolleja 5.9 (tietojen ja muun niihin liittyvän omaisuuden inventaario), 5.19–5.22 (toimittajat ja TVT-toimitusketju) ja 8.8 (teknisten haavoittuvuuksien hallinta). Build-kirjaus koskettaa osittain kontrolleja 8.25, 8.29 ja 8.30. Kontrollit 8.26–8.28 koskevat vaatimuksia, suunnittelua ja koodia, ja ne ovat SBOM:n ulkopuolella.

Mitä NIS2-asiakkaat pyytävät ohjelmistotoimittajiltaan?

Yleensä kuvauksen turvallisesta kehityksestä, toimitetun version komponentit, sitoumuksen haavoittuvuuksien käsittelyyn, tavan vastaanottaa haavoittuvuustietoja ja perustelut silloin, kun haavoittuvuus ei koske tuotetta. Nämä kysymykset tulevat 21 artiklan 3 kohdasta ja joillakin aloilla täytäntöönpanoasetuksen 2024/2690 toimittajia koskevista kohdista.

Riittääkö SBOM näytöksi ISO 27001:n kontrollista 8.8?

Ei. Se osoittaa, mitä kukin julkaisu sisältää. Kontrolli 8.8 edellyttää myös näyttöä siitä, että hankit haavoittuvuustietoja, arvioit altistumisesi ja toimit sen mukaan. Yhdistä SBOM jatkuvaan uudelleenarviointiin, kirjaukseen haavoittuvista julkaisuista ja tekemiisi päätöksiin.

Mitä eroa on vaatimustenmukaisuudella ja näytöllä?

Vaatimustenmukaisuus tarkoittaa, että prosessisi täyttävät viitekehyksen vaatimukset auditoijan tai asiakkaan arvion mukaan. Näyttö on se, mikä osoittaa prosessien toimivan. SBOM on näyttöä muutamasta kontrollista. Se ei tee sinusta minkään viitekehyksen mukaista.