SBOM'er som compliance-dokumentation: ISO 27001, SOC 2 og NIS2

Dokumentation er ikke compliance

En kontrol opfyldes af en proces, der virker. Dokumentation viser, at den virker. En SBOM viser én bestemt ting: hvad en given release indeholdt. Den viser intet om adgangskontrol, hændelseshåndtering eller om nogen handlede på et fund.

Den kan også være forkert, uden at nogen opdager det. En generator, der læste de forkerte filer, producerer en gyldig SBOM, der mangler halvdelen af produktet. Sårbarhedsscanningen af den SBOM er ren, compliance-platformen ser, at der er kørt en scanning, og alle tjek lyser grønt. Hvad et grønt SOC 2-SBOM-tjek verificerer gennemgår den fejl i detaljer.

Dokumentation fra en SBOM tæller, når den er:

1. Knyttet til en release. Én SBOM pr. version, du har leveret, ikke én for repositoryet.
2. Komplet, eller siger, hvad den mangler. En SBOM, der angiver sine huller, er til at stole på for det, den opfører.
3. Gemt i den periode, revisionen dækker. En revisor, der tager stikprøver fra marts sidste år, skal bruge SBOM'en fra marts sidste år.
4. Tjekket igen, når nye sårbarheder dukker op. En liste, som ingen sammenligner med nye advisories, beviser ikke meget om sårbarhedsstyring.

Hvad en SBOM indeholder, kan du læse i hvad er en SBOM. For rammeværkerne for sikker udvikling af industriprodukter og amerikansk føderal software, se IEC 62443-4-1 og NIST SSDF.

ISO/IEC 27001:2022

ISO/IEC 27001 er den standard, et ledelsessystem for informationssikkerhed certificeres efter (ordliste). Annex A opregner 93 kontroller; en organisation vælger dem, dens risikovurdering kræver, og fører dem i sin Statement of Applicability. ISO/IEC 27002:2022 giver vejledningen til implementeringen. Ingen af dem nævner en SBOM. Tabellen citerer kun kontrollernes titler (på engelsk) og siger kort, hvad hver kontrol handler om.

Kontrol	Hvad den handler om	Hvordan en SBOM eller build-registrering tjener som dokumentation	Hvad den ikke dækker
5.9 "Inventory of information and other associated assets"	At vide, hvilke aktiver du har, og hvem der ejer dem	Den software, du leverer og kører, er et aktiv. En komponentliste pr. release er fortegnelsen over, hvad der er i den.	Hardware, data, mennesker 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"	Styring af den risiko, der følger med leverandører og IKT-forsyningskæden	To retninger. Som køber kan du kræve SBOM'er fra leverandører og overvåge dem. Som leverandør er din SBOM det, din certificerede kundes forsyningskædeproces beder dig om. Open source-komponenter er en del af IKT-forsyningskæden, men kommer uden leverandøraftale, og netop derfor er en fortegnelse over dem vigtig.	Kontrakter, leverandørvurderinger og gennemgange
8.8 "Management of technical vulnerabilities"	At få information om sårbarheder, vurdere din eksponering og handle på den	En aktuel komponentliste, der matches mod advisories og vurderes igen, når nye kommer, plus en registrering af, hvilke releases der indeholdt en sårbar version, og siden hvornår	Patching af din infrastruktur, scanning af hosts og selve beslutningerne
8.25 "Secure development life cycle"	Regler for sikker udvikling af software og systemer	En registreret, gentagelig releaseproces: hver release bygget i den samme pipeline med sin SBOM	Det meste af kontrollen: træning, miljøer, design og review
8.26 "Application security requirements", 8.27 "Secure system architecture and engineering principles", 8.28 "Secure coding"	Krav, design og kode	Ikke direkte. De handler om det, du skriver, ikke det, du henter ind.	Det hele: kodereview, SAST og designdokumenter er dokumentationen her
8.29 "Security testing in development and acceptance"	Sikkerhedstest før release	En policy gate, der blokerer et build ved et sårbarhedsfund, er en registreret test med et resultat	Funktionel sikkerhedstest, penetrationstest
8.30 "Outsourced development"	Styring og overvågning af udvikling, du outsourcer	Outsourcet kode, der bygges i din pipeline, får den samme SBOM og de samme tjek som din egen	Kontrakten, leverandørens egen praksis

Vær ærlig om 8.25 til 8.30: Det meste af det, de kontroller kræver, ligger uden for en SBOM. At påstå mere er den hurtigste måde at miste revisorens tillid til resten.

Eksempel: En revisor spørger til 8.8

"Hvordan ved I, hvornår en ny sårbarhed berører et produkt, I allerede har leveret?" Her er dokumentationskæden for én advisory, og hvem der leverer hvert led.

Trin	Dokumentation	Kommer fra
1. Releasens indhold	SBOM'en for version 4.2, registreret af det build, der producerede den	Dine build-værktøjer
2. Match med advisoryen	En ny CVE offentliggjort for et bibliotek i den SBOM, matchet via dets package URL	Din sårbarhedsovervågning
3. Eksponeringsvinduet	Hvert build, der indeholdt den sårbare version, og datoen for det første	Din build-historik
4. Beslutningen	Hvem der vurderede den, hvornår, og resultatet: rette, afbøde eller not affected, med begrundelsen	Din proces og dens registreringer
5. Rettelsen	Version 4.2.1, hvis SBOM ikke længere indeholder den sårbare version	Dine build-værktøjer

Værktøjer kan levere trin 1, 2, 3 og 5. Trin 4 er din proces, og det er det trin, revisorer læser grundigst.

SOC 2

En SOC 2-rapport siger, om kontrollerne opfylder AICPA's Trust Services Criteria (2017, med points of focus revideret i 2022). Kriterierne er formuleret som resultater. De nævner ikke SBOM'er, og der er to af dem, hvor SBOM'er hjælper.

• CC7.1 kræver, at organisationen bruger detektions- og overvågningsprocedurer til at identificere (1) ændringer i konfigurationer, der fører til nye sårbarheder, og (2) modtagelighed for nyopdagede sårbarheder. Dokumentation: en SBOM pr. release, vurderet igen mod nye advisories, og en registrering af, hvordan hvert fund blev håndteret.
• CC8.1 dækker change management: hvordan ændringer i infrastruktur, data, software og procedurer godkendes, udvikles eller anskaffes, testes, accepteres og implementeres. Dokumentation: hver release bygget i en registreret pipeline, ændringen i dens afhængigheder synlig fra det ene build til det næste og policy gates som kontrol af, hvad der må leveres.

Kriterierne er ved at blive revideret. I oktober 2026 offentliggjorde AICPA et høringsudkast (exposure draft) til Trust Services Criteria 2027 med en målrettet omstrukturering af kriterierne, frist for kommentarer den 15. januar 2027 og foreslået ikrafttræden for opgaver, der begynder den 31. december 2027 eller senere. Det er et udkast, og kriteriernes numre kan ændre sig: Tjek den endelige tekst, før du kobler dokumentation til de nye numre.

Hvis du allerede bruger en SOC 2-platform, så behold den. Spørgsmålet er, hvad SBOM'en bag dens tjek viser: SOC 2-SBOM-tjek sammenlignet.

NIS2

NIS 2-direktivet (EU) 2022/2555 gælder for væsentlige og vigtige enheder i de sektorer, det opregner. Læser du dette som software- eller enhedsleverandør, er du som regel ikke selv omfattet. Det er din kunde, og kundens forpligtelser når dig som spørgsmål. Artikel 21 fastsætter foranstaltningerne til styring af cybersikkerhedsrisici, og tre passager står bag de fleste af de spørgsmål:

• Artikel 21, stk. 2, litra d): sikkerhed i forsyningskæden, herunder sikkerhedsrelaterede aspekter af forholdet mellem den enkelte enhed og dens direkte leverandører eller tjenesteudbydere.
• Artikel 21, stk. 2, litra e): sikkerhed i forbindelse med erhvervelse, udvikling og vedligeholdelse af net- og informationssystemer, herunder håndtering og offentliggørelse af sårbarheder.
• Artikel 21, stk. 3: enhederne skal tage hensyn til de sårbarheder, der er specifikke for hver direkte leverandør og tjenesteudbyder, og til den overordnede kvalitet af deres leverandørers og tjenesteudbyderes produkter og cybersikkerhedspraksis, herunder deres procedurer for sikker udvikling. Det er den sætning, der bliver til et spørgeskema på dit bord.

Gennemførelsesforordning (EU) 2024/2690

Kommissionens gennemførelsesforordning (EU) 2024/2690 af 17. oktober 2024 fastsætter de tekniske og metodiske krav til foranstaltningerne i artikel 21, stk. 2, for udbydere af DNS-tjenester, TLD-navneadministratorer, udbydere af cloudcomputingtjenester, udbydere af datacentertjenester, udbydere af indholdsleveringsnetværk, udbydere af administrerede tjenester, udbydere af administrerede sikkerhedstjenester, onlinemarkedspladser, onlinesøgemaskiner, platforme for sociale netværkstjenester og tillidstjenesteudbydere. Den binder ikke de øvrige NIS2-sektorer, men den er den mest detaljerede offentlige beskrivelse af, hvad sikkerhed i forsyningskæden betyder, og andre købere låner fra den. De punkter, der når leverandørerne:

Punkt i bilaget	Hvad det siger	Hvad en leverandør bliver spurgt om
5.1.2(a)	Ved valg af leverandører tages der hensyn til leverandørernes og tjenesteudbydernes cybersikkerhedspraksis, herunder deres procedurer for sikker udvikling	Hvordan udvikler I sikkert, og hvordan ved I, hvad der indgår i jeres produkt?
5.1.4(e) og (f)	Kontrakter fastsætter, hvor det er relevant, retten til at foretage revision eller modtage revisionsrapporter og en forpligtelse for leverandører og tjenesteudbydere til at håndtere sårbarheder, der udgør en risiko for enheden	Vil I håndtere sårbarheder i det, I leverer, og kan vi se dokumentationen?
5.2	Et register over direkte leverandører med en liste over de IKT-produkter, IKT-tjenester og IKT-processer, hver af dem leverer	Hvilke produkter og versioner leverer I til os?
6.1.2(c)	Ved erhvervelse af IKT-tjenester eller IKT-produkter: oplysninger, der beskriver de hardware- og softwarekomponenter, der anvendes i IKT-tjenesterne eller IKT-produkterne	Hvilke hardware- og softwarekomponenter indeholder jeres produkt? Det nærmeste, nogen tekst på denne side kommer en SBOM, og den nævner stadig ikke ordet.
6.10	Håndtering af sårbarheder: overvåg information om sårbarheder via kanaler som meddelelser fra CSIRT'er eller oplysninger fra leverandører eller tjenesteudbydere (6.10.2(a)), og når en sårbarhed ikke kræver afhjælpning, dokumentér og begrund årsagen (6.10.3)	Hvordan vil I fortælle os om sårbarheder, og hvorfor er netop denne ikke et problem?

Det sidste punkt beskriver en not affected-erklæring med begrundelse. Det er det, et VEX-dokument indeholder, selv om forordningen ikke nævner noget format.

Eksempel: et spørgeskema fra en NIS2-kunde

Fem spørgsmål af den slags, en kunde udleder af de punkter, med den dokumentation, en leverandør kan vedlægge. Nogle svar kommer fra registreringer, dine værktøjer gemmer; andre er politikker, du skriver.

Spørgsmål	Dokumentation, der vedlægges	Registrering eller politik
"Opregn softwarekomponenterne i den produktversion, I leverer til os." (6.1.2(c))	SBOM'en for den version, i CycloneDX eller SPDX, med angivelse af fuldstændighed	Registrering
"Beskriv jeres håndtering af sårbarheder og tidsfristerne for den." (5.1.4(f))	Din procedure for håndtering af sårbarheder med alvorlighedsgrader og måltider	Politik
"Hvilke af de versioner, vi kører, indeholdt det sårbare bibliotek, og siden hvornår?" (6.10)	Build-historik, der viser hvert build, der indeholdt komponenten, med datoer	Registrering
"Hvorfor berører denne CVE ikke os?" (6.10)	En not affected-erklæring med begrundelse, for eksempel "den sårbare kode er ikke til stede"	Registrering, baseret på din vurdering
"Hvordan kan forskere rapportere sårbarheder i jeres produkter?" (5.1.2(a))	Din politik for koordineret offentliggørelse af sårbarheder	Politik

Én skelnen at holde fast i: For produkter med digitale elementer, der sælges i EU, kræver Cyber Resilience Act en SBOM. Det gør NIS2 ikke.

DORA, hvis du sælger til finansielle enheder

Digital Operational Resilience Act, forordning (EU) 2022/2554, gælder for finansielle enheder, ikke direkte for deres leverandører. Finansielle enheder skal identificere og dokumentere deres IKT-aktiver og deres indbyrdes afhængigheder og føre fortegnelser over dem (artikel 8, stk. 1, 4 og 6), styre IKT-tredjepartsrisiko som en del af deres IKT-risiko (artikel 28, stk. 1), føre et register med oplysninger om alle deres kontrakter om IKT-tjenester (artikel 28, stk. 3) og indsætte minimumsbestemmelser i de kontrakter (artikel 30). DORA nævner ikke SBOM'er. For en leverandør af software til en bank hjælper en komponentliste pr. release kunden med at opfylde artikel 8.

Ét dokumentationskort på tværs af dem alle

Rækkerne er dokumentation; hver celle angiver den kontrol, det kriterium eller det punkt, den understøtter, eller "ikke direkte".

Dokumentation	ISO/IEC 27001:2022	SOC 2	NIS2 og 2024/2690	DORA
1. En SBOM pr. release med angivelse af fuldstændighed	5.9, 5.21, 8.8	CC7.1	Art. 21(2)(d); 6.1.2(c)	Art. 8 (kundens fortegnelse)
2. Løbende genvurdering mod nye advisories	8.8	CC7.1	Art. 21(2)(e); 6.10	Ikke direkte
3. Build-historik: hvilke releases der indeholdt en komponent, og siden hvornår	8.8	CC7.1, CC8.1	6.10	Ikke direkte
4. Registreringer af triage og routing	8.8	CC7.1	Art. 21(2)(e); 6.10	Ikke direkte
5. Not affected-erklæringer med begrundelse	8.8	CC7.1	6.10	Ikke direkte
6. Policy gates, der blokerer et build	8.25, 8.29	CC8.1	Art. 21(2)(e)	Ikke direkte
7. Leverandørers SBOM'er overvåget 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-politik og netværksregistreringer for buildet	8.25	CC8.1	Art. 21(2)(d)	Ikke direkte

Hvad en SBOM ikke beviser

• Din adgangskontrol, hændelseshåndtering, forretningskontinuitet, HR-sikkerhed, kryptografi eller fysiske sikkerhed.
• At nogen har rettet noget. Det er din proces og dens registreringer.
• At din egen kode er fri for fejl. Kodereview, SAST og test er dokumentationen for det.
• Hvad der er i binærfiler, du har modtaget uden en SBOM.
• At du er certificeret. En SBOM er ikke et certifikat, og et certifikat, som din værktøjsleverandør har, certificerer leverandørens eget ledelsessystem, ikke dig.

Hvor CRACI passer ind

CRACI erstatter dine GitHub-hostede runners og registrerer, hvad hvert build hentede ind, så SBOM'en kommer fra selve release-buildet med en fuldstændighedsstatus for hvert job.

• Overvågede SBOM'er genvurderes løbende, efterhånden som nye sårbarheder offentliggøres (sårbarhedssporing).
• Build-historikken viser, hvilke builds der indeholdt en sårbar afhængighed, og dermed den periode, du var eksponeret, inden for din opbevaringsperiode. Dækker din revision en længere periode, så eksportér hver releases SBOM, og gem den sammen med releasen.
• Sikkerhedsteams triagerer de fundne sårbarheder og sender dem til de teams, der ejer rettelsen, og CRACI understøtter VEX til at registrere, hvilke produkter en sårbarhed ikke påvirker.
• Policy gates kan blokere et build ved fund, også et build, der indeholder en bestemt CVE.
• Tredjeparts-SBOM'er kan tilføjes, så indkøbte komponenter overvåges side om side med dine egne builds.
• SBOM'er eksporteres som CycloneDX eller SPDX, og API'et returnerer SBOM'er, netværkstraces og provenance-data. Egress-politikken registrerer og begrænser, hvor hvert build må forbinde til.

CRACI leverer dokumentation for disse kontroller. Det gør dig ikke ISO 27001- eller SOC 2-compliant eller klar til NIS2, og det er ikke en platform til compliance-automatisering. CRACI's eget certifikat er en separat sag: CRACI Corporation Oy's ledelsessystem for informationssikkerhed for udvikling og drift af CRACI-platformen er certificeret efter ISO/IEC 27001, udstedt af Into Certification. Det dækker, hvordan CRACI driver sin tjeneste, ikke din organisation eller dine produkter. Se sikkerhed hos CRACI og sådan fungerer CRACI for hele platformen.

Når CRACI ikke er svaret

• Dine builds kører ikke på GitHub Actions. Det er det eneste CI, CRACI understøtter i dag; andre CI-systemer er på roadmappen.
• Du har brug for en platform til compliance-automatisering til politikker, adgangsgennemgange og revisorens workflow. Behold eller køb en; se SOC 2-SBOM-tjek sammenlignet.
• Dit dokumentationshul er mest organisatorisk: politikker, træning, hændelseshåndtering.
• Din største leverandørrisiko er binærfiler, du modtager uden SBOM'er. Det svarer binær analyse på.

Skal du svare på én kundes anmodning? Se sådan svarer du på en kundes SBOM-anmodning, guiden for komponentleverandører og den tjekliste, din kunde vil køre.

SBOM'er som compliance-dokumentation: ofte stillede spørgsmål

Kræver ISO 27001 en SBOM?

Nej. ISO/IEC 27001:2022 nævner ikke SBOM'er. Annex A-kontrollerne 5.9 (fortegnelse), 5.21 (IKT-forsyningskæden) og 8.8 (tekniske sårbarheder) beder om resultater, som en SBOM understøtter, og organisationen og dens revisor afgør, hvilken dokumentation der er nok.

Kræver SOC 2 en SBOM?

Nej. Trust Services Criteria er formuleret som resultater og nævner ikke SBOM'er. En SBOM pr. release, vurderet igen mod nye advisories, er dokumentation for CC7.1, og en registreret build-pipeline understøtter CC8.1 om change management.

Kræver NIS2 en SBOM?

Nej. Artikel 21, stk. 2, litra d), beder om sikkerhed i forsyningskæden og litra e) om håndtering af sårbarheder uden at nævne SBOM'er. Gennemførelsesforordning (EU) 2024/2690, der dækker visse udbydere af digitale tjenester, beder i punkt 6.1.2(c) om oplysninger om IKT-produkters hardware- og softwarekomponenter, stadig uden ordet SBOM.

Hvilke kontroller i ISO 27001 Annex A understøtter en SBOM?

Primært 5.9 (fortegnelse over information og andre tilknyttede aktiver), 5.19 til 5.22 (leverandører og IKT-forsyningskæden) og 8.8 (styring af tekniske sårbarheder). En build-registrering berører delvist 8.25, 8.29 og 8.30. 8.26 til 8.28 handler om krav, design og kode, uden for en SBOM.

Hvad beder NIS2-kunder deres softwareleverandører om?

Som regel en beskrivelse af sikker udvikling, komponenterne i den leverede version, en forpligtelse til at håndtere sårbarheder, en måde at modtage sårbarhedsinformation på og begrundelser, når en sårbarhed ikke er relevant. Spørgsmålene kommer fra artikel 21, stk. 3, og for nogle sektorer fra leverandørpunkterne i gennemførelsesforordning 2024/2690.

Er en SBOM nok dokumentation for ISO 27001-kontrol 8.8?

Nej. Den viser, hvad hver release indeholder. Kontrol 8.8 kræver også dokumentation for, at du indhenter sårbarhedsinformation, vurderer din eksponering og handler på den. Kombinér SBOM'en med løbende genvurdering, en registrering af berørte releases og de beslutninger, du har truffet.

Hvad er forskellen på at være compliant og at have dokumentation?

Compliance betyder, at dine processer opfylder rammeværkets krav, som en revisor eller en kunde vurderer det. Dokumentation er det, der viser, at processerne virker. En SBOM er dokumentation for nogle få kontroller. Den gør dig ikke compliant med noget rammeværk.