SBOM-er som samsvarsbevis: ISO 27001, SOC 2 og NIS2

Bevis er ikke samsvar

En kontroll oppfylles av en prosess som virker. Bevis viser at den virker. En SBOM viser én bestemt ting: hva en gitt utgivelse inneholdt. Den viser ingenting om tilgangskontroll, hendelseshåndtering eller om noen fulgte opp et funn.

Den kan også være feil uten at noen merker det. En generator som leste feil filer, lager en gyldig SBOM som mangler halve produktet. Sårbarhetsskanningen av den SBOM-en er ren, samsvarsplattformen ser at en skanning har kjørt, og hver sjekk lyser grønt. Hva en grønn SBOM-sjekk for SOC 2 verifiserer går gjennom den feilen i detalj.

Bevis fra en SBOM teller når den er:

1. Knyttet til en utgivelse. Én SBOM per versjon du leverte, ikke én for repositoriet.
2. Fullstendig, eller sier hva den mangler. En SBOM som oppgir hullene sine, kan stoles på for det den lister.
3. Oppbevart for perioden revisjonen dekker. En revisor som tar stikkprøver fra mars i fjor, trenger SBOM-en fra mars i fjor.
4. Sjekket på nytt når nye sårbarheter dukker opp. En liste ingen sammenligner med nye advisories, beviser lite om sårbarhetshåndtering.

For hva en SBOM inneholder, se hva er en SBOM. For rammeverkene for sikker utvikling av industriprodukter og amerikansk føderal programvare, se IEC 62443-4-1 og NIST SSDF.

ISO/IEC 27001:2022

ISO/IEC 27001 er standarden et styringssystem for informasjonssikkerhet sertifiseres mot (ordliste). Vedlegg A lister 93 kontroller; en organisasjon velger dem risikovurderingen tilsier og registrerer dem i sin Statement of Applicability. ISO/IEC 27002:2022 gir veiledning om implementering. Ingen av dem nevner en SBOM. Tabellen siterer bare kontrolltitlene, på engelsk, og sier kort hva hver kontroll handler om.

Kontroll	Hva den handler om	Hvordan en SBOM eller byggeregistrering fungerer som bevis	Hva den ikke dekker
5.9 «Inventory of information and other associated assets»	Å vite hvilke eiendeler du har, og hvem som eier dem	Programvaren du leverer og kjører, er en eiendel. En komponentliste per utgivelse er oversikten over hva som er inni den.	Maskinvare, data, personer og tjenester
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»	Å styre risikoen som følger med leverandører og IKT-leverandørkjeden	To retninger. Som kjøper kan du kreve SBOM-er fra leverandører og overvåke dem. Som leverandør er SBOM-en din det den sertifiserte kundens leverandørkjedeprosess ber deg om. Komponenter med åpen kildekode er en del av IKT-leverandørkjeden, men kommer uten leverandøravtale, og nettopp derfor betyr en oversikt over dem noe.	Kontrakter, leverandørvurderinger og gjennomganger
8.8 «Management of technical vulnerabilities»	Å skaffe informasjon om sårbarheter, vurdere eksponeringen og handle på den	En oppdatert komponentliste matchet mot advisories og vurdert på nytt når nye kommer, pluss en oversikt over hvilke utgivelser som inneholdt en sårbar versjon, og siden når	Patching av infrastrukturen, skanning av verter, og selve beslutningene
8.25 «Secure development life cycle»	Regler for sikker utvikling av programvare og systemer	En registrert, repeterbar utgivelsesprosess: hver utgivelse bygget i samme pipeline, med sin SBOM	Det meste av kontrollen: opplæring, miljøer, design og gjennomgang
8.26 «Application security requirements», 8.27 «Secure system architecture and engineering principles», 8.28 «Secure coding»	Krav, design og kode	Ikke direkte. Disse handler om det du skriver, ikke det du trekker inn.	Alt sammen: kodegjennomgang, SAST og designdokumentasjon er bevisene her
8.29 «Security testing in development and acceptance»	Å teste sikkerheten før utgivelse	En policy-port som blokkerer et bygg ved et sårbarhetsfunn, er en registrert test med et resultat	Funksjonell sikkerhetstesting, penetrasjonstester
8.30 «Outsourced development»	Å styre og overvåke utvikling du setter ut	Utsatt kode som bygges i pipelinen din, får samme SBOM og sjekker som din egen	Kontrakten, leverandørens egen praksis

Vær ærlig om 8.25 til 8.30: det meste av det disse kontrollene ber om, ligger utenfor en SBOM. Å påstå mer er den raskeste måten å miste revisorens tillit til resten på.

Eksempel: en revisor spør om 8.8

«Hvordan vet dere når en ny sårbarhet berører et produkt dere allerede har levert?» Her er beviskjeden for én advisory, og hvem som leverer hvert ledd.

Steg	Bevis	Kommer fra
1. Innholdet i utgivelsen	SBOM-en for versjon 4.2, registrert av bygget som produserte den	Byggeverktøyene dine
2. Treffet i advisoryen	En ny CVE publisert for et bibliotek i den SBOM-en, matchet via package URL-en	Sårbarhetsovervåkingen din
3. Eksponeringsvinduet	Hvert bygg som inneholdt den sårbare versjonen, og datoen for det første	Byggehistorikken din
4. Beslutningen	Hvem som vurderte den, når, og utfallet: rette, avbøte eller ikke berørt, med begrunnelse	Prosessen din og dokumentasjonen av den
5. Rettelsen	Versjon 4.2.1, der SBOM-en ikke lenger inneholder den sårbare versjonen	Byggeverktøyene dine

Verktøy kan levere steg 1, 2, 3 og 5. Steg 4 er prosessen din, og det er steget revisorer leser nøyest.

SOC 2

En SOC 2-rapport sier om kontroller oppfyller AICPAs Trust Services Criteria (2017, med points of focus revidert i 2022). Kriteriene er resultatbeskrivelser. De nevner ikke SBOM-er, og to av dem er der SBOM-er hjelper.

• CC7.1 ber om at virksomheten bruker deteksjons- og overvåkingsprosedyrer for å identifisere (1) endringer i konfigurasjoner som fører til nye sårbarheter, og (2) mottakelighet for nylig oppdagede sårbarheter. Bevis: en SBOM per utgivelse, vurdert på nytt mot nye advisories, og en oversikt over hvordan hvert funn ble håndtert.
• CC8.1 dekker endringshåndtering: hvordan endringer i infrastruktur, data, programvare og prosedyrer blir godkjent, utviklet eller anskaffet, testet, godkjent og implementert. Bevis: hver utgivelse bygget i en registrert pipeline, endringen i avhengighetene synlig fra ett bygg til det neste, og policy-porter som en kontroll av hva som kan leveres.

Kriteriene revideres. I oktober 2026 publiserte AICPA et høringsutkast til Trust Services Criteria for 2027, med en målrettet omstrukturering av kriteriene, høringsfrist 15. januar 2027 og foreslått ikrafttredelse for oppdrag som starter 31. desember 2027 eller senere. Det er et utkast, og kriterienumrene kan endres: sjekk den endelige teksten før du kobler bevis til de nye numrene.

Hvis du allerede bruker en SOC 2-plattform, behold den. Spørsmålet er hva SBOM-en bak sjekkene viser: SBOM-sjekker for SOC 2 sammenlignet.

NIS2

NIS2-direktivet (EU) 2022/2555 gjelder vesentlige og viktige enheter i sektorene det lister. Leser du dette som leverandør av programvare eller enheter, er du vanligvis ikke selv omfattet. Kunden din er det, og forpliktelsene når deg som spørsmål. Artikkel 21 fastsetter tiltakene for styring av cybersikkerhetsrisiko, og tre passasjer gir de fleste av disse spørsmålene. Det finnes ingen offisiell norsk tekst; gjengivelsene nedenfor er tro parafraser:

• Artikkel 21(2)(d): sikkerhet i leverandørkjeden, inkludert sikkerhetsrelaterte aspekter ved forholdet mellom hver enhet og dens direkte leverandører eller tjenesteleverandører.
• Artikkel 21(2)(e): sikkerhet ved anskaffelse, utvikling og vedlikehold av nettverks- og informasjonssystemer, inkludert håndtering og offentliggjøring av sårbarheter.
• Artikkel 21(3): enhetene må ta hensyn til sårbarhetene som er spesifikke for hver direkte leverandør og tjenesteleverandør, og den samlede kvaliteten på produktene og cybersikkerhetspraksisen til leverandørene og tjenesteleverandørene, inkludert deres prosedyrer for sikker utvikling. Det er denne setningen som blir til et spørreskjema på pulten din.

Gjennomføringsforordning (EU) 2024/2690

Kommisjonens gjennomføringsforordning (EU) 2024/2690 av 17. oktober 2024 fastsetter de tekniske og metodiske kravene til tiltakene i artikkel 21(2) for DNS-tjenesteleverandører, registre for toppdomenenavn, leverandører av skytjenester, leverandører av datasentertjenester, leverandører av innholdsleveringsnettverk, leverandører av administrerte tjenester, leverandører av administrerte sikkerhetstjenester, nettbaserte markedsplasser, nettbaserte søkemotorer, plattformer for sosiale nettverkstjenester og tillitstjenesteytere. Den binder ikke de andre NIS2-sektorene, men den er den mest detaljerte offentlige beskrivelsen av hva «sikkerhet i leverandørkjeden» betyr, og andre kjøpere låner fra den. Punktene som når leverandører, gjengitt som parafraser:

Punkt i vedlegget	Hva det sier	Hva en leverandør blir spurt om
5.1.2(a)	Valg av leverandører tar hensyn til cybersikkerhetspraksisen til leverandørene og tjenesteleverandørene, inkludert deres prosedyrer for sikker utvikling	Hvordan utvikler dere sikkert, og hvordan vet dere hva som går inn i produktet?
5.1.4(e) og (f)	Kontrakter fastsetter, der det er hensiktsmessig, retten til revisjon eller til å motta revisjonsrapporter, og en plikt for leverandører og tjenesteleverandører til å håndtere sårbarheter som utgjør en risiko for enheten	Vil dere håndtere sårbarheter i det dere leverer, og kan vi se bevisene?
5.2	Et register over direkte leverandører, med en liste over IKT-produktene, IKT-tjenestene og IKT-prosessene hver av dem leverer	Hvilke produkter og versjoner leverer dere til oss?
6.1.2(c)	Ved anskaffelse av IKT-tjenester eller IKT-produkter: informasjon som beskriver maskinvare- og programvarekomponentene som brukes i IKT-tjenestene eller IKT-produktene	Hvilke maskinvare- og programvarekomponenter inneholder produktet deres? Det nærmeste noen tekst på denne siden kommer en SBOM, og den nevner fortsatt ingen.
6.10	Sårbarhetshåndtering: overvåk informasjon om sårbarheter gjennom kanaler som CSIRT-kunngjøringer eller informasjon fra leverandører eller tjenesteleverandører (6.10.2(a)), og der en sårbarhet ikke trenger utbedring, dokumenter og begrunn hvorfor (6.10.3)	Hvordan vil dere informere oss om sårbarheter, og hvorfor er ikke denne et problem?

Det siste punktet beskriver en ikke-berørt-erklæring med begrunnelse. Det er det et VEX-dokument inneholder, selv om forordningen ikke nevner noe format.

Eksempel: et spørreskjema fra en NIS2-kunde

Fem spørsmål av typen en kunde utleder fra disse punktene, med beviset en leverandør kan legge ved. Noen svar kommer fra data verktøyene dine registrerer; andre er retningslinjer du skriver.

Spørsmål	Bevis å legge ved	Registrering eller retningslinje
«List programvarekomponentene i produktversjonen dere leverer til oss.» (6.1.2(c))	SBOM-en for den versjonen, i CycloneDX eller SPDX, med fullstendigheten oppgitt	Registrering
«Beskriv sårbarhetshåndteringen deres og tidsfristene.» (5.1.4(f))	Prosedyren for sårbarhetshåndtering, med alvorlighetsnivåer og måltider	Retningslinje
«Hvilke av versjonene vi kjører, inneholdt det sårbare biblioteket, og siden når?» (6.10)	Byggehistorikk som viser hvert bygg som inneholdt komponenten, med datoer	Registrering
«Hvorfor berører ikke denne CVE-en oss?» (6.10)	En ikke-berørt-erklæring med begrunnelse, for eksempel «den sårbare koden finnes ikke»	Registrering, basert på vurderingen din
«Hvordan kan forskere rapportere sårbarheter i produktene deres?» (5.1.2(a))	Retningslinjen din for koordinert offentliggjøring av sårbarheter	Retningslinje

Ett skille å holde fast ved: for produkter med digitale elementer som selges i EU, krever Cyber Resilience Act en SBOM. Det gjør ikke NIS2.

DORA, hvis du selger til finansforetak

Digital Operational Resilience Act, forordning (EU) 2022/2554, gjelder finansforetak, ikke leverandørene deres direkte. Finansforetak må identifisere og dokumentere IKT-eiendelene sine og avhengighetene mellom dem og føre oversikter over dem (artikkel 8(1), 8(4) og 8(6)), styre IKT-tredjepartsrisiko som en del av IKT-risikoen (artikkel 28(1)), føre et informasjonsregister over alle kontraktene sine om IKT-tjenester (artikkel 28(3)) og ta inn minimumsbestemmelser i disse kontraktene (artikkel 30). DORA nevner ikke SBOM-er. For en leverandør av programvare til en bank hjelper en komponentliste per utgivelse kunden å oppfylle artikkel 8.

Én beviskartlegging for alle

Radene er bevis; hver celle oppgir kontrollen, kriteriet eller punktet beviset støtter, eller «ikke direkte».

Bevis	ISO/IEC 27001:2022	SOC 2	NIS2 og 2024/2690	DORA
1. En SBOM per utgivelse, med fullstendigheten oppgitt	5.9, 5.21, 8.8	CC7.1	Art. 21(2)(d); 6.1.2(c)	Art. 8 (kundens oversikt)
2. Fortløpende ny vurdering mot nye advisories	8.8	CC7.1	Art. 21(2)(e); 6.10	Ikke direkte
3. Byggehistorikk: hvilke utgivelser som inneholdt en komponent, og siden når	8.8	CC7.1, CC8.1	6.10	Ikke direkte
4. Dokumentasjon av triage og ruting	8.8	CC7.1	Art. 21(2)(e); 6.10	Ikke direkte
5. Ikke-berørt-erklæringer med begrunnelse	8.8	CC7.1	6.10	Ikke direkte
6. Policy-porter som blokkerer et bygg	8.25, 8.29	CC8.1	Art. 21(2)(e)	Ikke direkte
7. Leverandør-SBOM-er overvåket sammen med dine egne	5.19, 5.21, 5.22	CC7.1	Art. 21(2)(d), 21(3); 5.2, 6.10	Art. 28(1)
8. Egress-policy og nettverksregistreringer for bygget	8.25	CC8.1	Art. 21(2)(d)	Ikke direkte

Hva en SBOM ikke beviser

• Tilgangskontrollen, hendelseshåndteringen, kontinuiteten, personalsikkerheten, kryptografien eller den fysiske sikkerheten din.
• At noen har rettet noe. Det er prosessen din, og dokumentasjonen av den.
• At din egen kode er uten feil. Kodegjennomgang, SAST og testing er bevisene for det.
• Hva som er inni binærfiler du har mottatt uten SBOM.
• At du er sertifisert. En SBOM er ikke et sertifikat, og et sertifikat som verktøyleverandøren din har, sertifiserer leverandørens eget styringssystem, ikke deg.

Hvor CRACI passer inn

CRACI erstatter de GitHub-hostede runnerne dine og registrerer det hvert bygg trakk inn, så SBOM-en kommer fra selve utgivelsesbygget, med en fullstendighetsstatus for hver jobb.

• Overvåkede SBOM-er vurderes fortløpende på nytt når nye sårbarheter publiseres (sårbarhetssporing).
• Byggehistorikken viser hvilke bygg som inneholdt en sårbar avhengighet, og dermed perioden du var eksponert, innenfor oppbevaringstiden din. Dekker revisjonen en lengre periode, eksporterer du SBOM-en for hver utgivelse og oppbevarer den sammen med utgivelsen.
• Sikkerhetsteam triagerer sårbarhetene som blir funnet, og sender dem til teamene som eier rettelsen, og CRACI støtter VEX for å registrere hvilke produkter en sårbarhet ikke berører.
• Policy-porter kan blokkere et bygg ved funn, inkludert et bygg som inneholder en bestemt CVE.
• SBOM-er fra tredjeparter kan legges til, så innkjøpte komponenter overvåkes sammen med dine egne bygg.
• SBOM-er eksporteres som CycloneDX eller SPDX, og API-et returnerer SBOM-er, nettverksspor og opprinnelsesdata. Egress-policyen registrerer og begrenser hvor hvert bygg kan koble seg til.

CRACI leverer bevis for disse kontrollene. Det gjør deg ikke ISO 27001- eller SOC 2-samsvarende eller klar for NIS2, og det er ikke en plattform for automatisering av samsvar. CRACIs eget sertifikat er et eget faktum: styringssystemet for informasjonssikkerhet hos CRACI Corporation Oy for utvikling og drift av CRACI-plattformen er sertifisert etter ISO/IEC 27001, utstedt av Into Certification. Det dekker hvordan CRACI driver tjenesten sin, ikke organisasjonen eller produktene dine. Se sikkerhet hos CRACI, og slik fungerer CRACI for hele plattformen.

Når CRACI ikke er svaret

• Byggene dine kjører ikke på GitHub Actions. Det er den eneste CI-en CRACI støtter i dag; andre CI-systemer er på veikartet.
• Du trenger en plattform for automatisering av samsvar for retningslinjer, tilgangsgjennomganger og arbeidsflyt med revisor. Behold eller kjøp en; se SBOM-sjekker for SOC 2 sammenlignet.
• Bevishullet ditt er for det meste organisatorisk: retningslinjer, opplæring, hendelseshåndtering.
• Den største leverandørrisikoen din er binærfiler du mottar uten SBOM-er. Det besvarer binæranalyse.

Svarer du på én kundes forespørsel? Se slik svarer du på en SBOM-forespørsel fra en kunde, guiden for komponentleverandører og sjekklisten kunden din vil bruke.

SBOM-er som samsvarsbevis: ofte stilte spørsmål

Krever ISO 27001 en SBOM?

Nei. ISO/IEC 27001:2022 nevner ikke SBOM-er. Kontrollene 5.9 (oversikt over eiendeler), 5.21 (IKT-leverandørkjeden) og 8.8 (tekniske sårbarheter) i vedlegg A ber om resultater en SBOM støtter, og organisasjonen og revisoren avgjør hvilke bevis som er nok.

Krever SOC 2 en SBOM?

Nei. Trust Services Criteria er resultatbeskrivelser og nevner ikke SBOM-er. En SBOM per utgivelse, vurdert på nytt mot nye advisories, er bevis for CC7.1, og en registrert byggepipeline støtter CC8.1 om endringshåndtering.

Krever NIS2 en SBOM?

Nei. Artikkel 21(2)(d) ber om sikkerhet i leverandørkjeden og 21(2)(e) om sårbarhetshåndtering, uten å nevne SBOM-er. Gjennomføringsforordning (EU) 2024/2690, som dekker visse digitale tjenesteleverandører, ber om informasjon om maskinvare- og programvarekomponentene i IKT-produkter i punkt 6.1.2(c), fortsatt uten ordet SBOM.

Hvilke kontroller i vedlegg A til ISO 27001 støtter en SBOM?

Hovedsakelig 5.9 (oversikt over informasjon og andre tilknyttede eiendeler), 5.19 til 5.22 (leverandører og IKT-leverandørkjeden) og 8.8 (håndtering av tekniske sårbarheter). En byggeregistrering berører 8.25, 8.29 og 8.30 delvis. 8.26 til 8.28 handler om krav, design og kode, utenfor en SBOM.

Hva ber NIS2-kunder programvareleverandørene sine om?

Vanligvis en beskrivelse av sikker utvikling, komponentene i den leverte versjonen, en forpliktelse til å håndtere sårbarheter, en måte å motta sårbarhetsinformasjon på, og begrunnelser når en sårbarhet ikke gjelder. Spørsmålene kommer fra artikkel 21(3) og, for noen sektorer, leverandørpunktene i gjennomføringsforordning 2024/2690.

Er en SBOM nok bevis for ISO 27001-kontroll 8.8?

Nei. Den viser hva hver utgivelse inneholder. Kontroll 8.8 trenger også bevis for at du skaffer informasjon om sårbarheter, vurderer eksponeringen og handler på den. Kombiner SBOM-en med fortløpende ny vurdering, en oversikt over berørte utgivelser og beslutningene du tok.

Hva er forskjellen på å være i samsvar og å ha bevis?

Samsvar betyr at prosessene dine oppfyller kravene i rammeverket, slik en revisor eller en kunde vurderer det. Bevis er det som viser at prosessene virker. En SBOM er bevis for noen få kontroller. Den gjør deg ikke i samsvar med noe rammeverk.