SBOM:er som underlag för efterlevnad: ISO 27001, SOC 2 och NIS2

Bevis är inte efterlevnad

En kontroll uppfylls av en process som fungerar. Bevis visar att den fungerar. En SBOM visar en specifik sak: vad en viss release innehöll. Den visar ingenting om åtkomstkontroll, incidenthantering eller om någon agerade på ett fynd.

Den kan också vara fel på ett sätt som ingen märker. En generator som läste fel filer ger en giltig SBOM som saknar halva produkten. Sårbarhetsskanningen av den SBOM:en är ren, efterlevnadsplattformen ser att en skanning kördes, och varje kontroll lyser grönt. Vad en grön SOC 2-kontroll av SBOM:er verifierar går igenom det felet i detalj.

Bevis från en SBOM räknas när den:

1. Är knuten till en release. En SBOM per version du har levererat, inte en för repot.
2. Är fullständig, eller anger vad den missade. En SBOM som anger sina luckor går att lita på för det den listar.
3. Sparas under den period som revisionen omfattar. En revisor som tar stickprov från i mars förra året behöver SBOM:en från i mars förra året.
4. Kontrolleras på nytt när nya sårbarheter dyker upp. En lista som ingen jämför med nya säkerhetsmeddelanden bevisar lite om sårbarhetshantering.

För vad en SBOM innehåller, se vad är en SBOM. För ramverken för säker utveckling av industriprodukter och programvara till den amerikanska federala förvaltningen, se IEC 62443-4-1 och NIST SSDF.

ISO/IEC 27001:2022

ISO/IEC 27001 är standarden som ett ledningssystem för informationssäkerhet certifieras mot (ordlista). Bilaga A listar 93 kontroller; en organisation väljer dem som dess riskbedömning kräver och dokumenterar dem i sitt uttalande om tillämplighet (Statement of Applicability). ISO/IEC 27002:2022 ger vägledningen för införandet. Ingen av dem nämner en SBOM. Tabellen citerar bara kontrollernas titlar, på engelska, och sammanfattar kort vad varje kontroll handlar om.

Kontroll	Vad den handlar om	Hur en SBOM eller byggregistrering fungerar som bevis	Vad den inte täcker
5.9 "Inventory of information and other associated assets"	Att veta vilka tillgångar du har och vem som äger dem	Programvaran du levererar och kör är en tillgång. En komponentlista per release är förteckningen över vad som finns i den.	Hårdvara, data, personer och tjänster
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"	Att hantera risken som följer med leverantörer och IKT-leveranskedjan	Två riktningar. Som köpare kan du kräva SBOM:er av leverantörer och bevaka dem. Som leverantör är din SBOM det som din certifierade kunds process för leveranskedjan ber dig om. Komponenter med öppen källkod är en del av IKT-leveranskedjan men kommer utan leverantörsavtal, och det är just därför en förteckning över dem spelar roll.	Avtal, leverantörsbedömningar och granskningar
8.8 "Management of technical vulnerabilities"	Att få information om sårbarheter, bedöma din exponering och agera på den	En aktuell komponentlista som matchas mot säkerhetsmeddelanden och omvärderas när nya kommer, plus en registrering av vilka releaser som innehöll en sårbar version och sedan när	Att patcha din infrastruktur, skanna värdar, och själva besluten
8.25 "Secure development life cycle"	Regler för att utveckla programvara och system på ett säkert sätt	En registrerad, upprepbar releaseprocess: varje release byggd i samma pipeline, med sin SBOM	Det mesta av kontrollen: utbildning, miljöer, design och granskning
8.26 "Application security requirements", 8.27 "Secure system architecture and engineering principles", 8.28 "Secure coding"	Krav, design och kod	Inte direkt. De handlar om det du skriver, inte det du drar in.	Allt: kodgranskning, SAST och designdokumentation är bevisen här
8.29 "Security testing in development and acceptance"	Att testa säkerheten före release	En policygrind som stoppar ett bygge vid ett sårbarhetsfynd är ett registrerat test med ett resultat	Funktionell säkerhetstestning, penetrationstester
8.30 "Outsourced development"	Att styra och följa upp utveckling som du lägger ut	Utlagd kod som byggs i din pipeline får samma SBOM och kontroller som din egen	Avtalet, leverantörens egna arbetssätt

Var ärlig om 8.25 till 8.30: det mesta som de kontrollerna kräver ligger utanför en SBOM. Att påstå mer är det snabbaste sättet att förlora revisorns förtroende för resten.

Exempel: en revisor frågar om 8.8

"Hur vet ni när en ny sårbarhet påverkar en produkt som ni redan har levererat?" Här är beviskedjan för ett säkerhetsmeddelande, och vem som står för varje länk.

Steg	Bevis	Kommer från
1. Releasens innehåll	SBOM:en för version 4.2, registrerad av bygget som producerade den	Dina byggverktyg
2. Matchningen mot säkerhetsmeddelandet	En ny CVE som publicerats för ett bibliotek i den SBOM:en, matchad via dess package URL	Din sårbarhetsbevakning
3. Exponeringsfönstret	Varje bygge som innehöll den sårbara versionen, och datumet för det första	Din bygghistorik
4. Beslutet	Vem som bedömde den, när, och utfallet: åtgärda, begränsa eller inte påverkad, med motivering	Din process och dess dokumentation
5. Åtgärden	Version 4.2.1, vars SBOM inte längre innehåller den sårbara versionen	Dina byggverktyg

Verktyg kan stå för steg 1, 2, 3 och 5. Steg 4 är din process, och det är steget som revisorer läser noggrannast.

SOC 2

En SOC 2-rapport anger om kontrollerna uppfyller AICPA:s Trust Services Criteria (2017, med fokuspunkter som reviderades 2022). Kriterierna är beskrivningar av utfall. De nämner inte SBOM:er, och två av dem är där SBOM:er hjälper.

• CC7.1 kräver att organisationen använder rutiner för upptäckt och övervakning för att identifiera (1) ändringar i konfigurationer som leder till att nya sårbarheter införs och (2) mottaglighet för nyupptäckta sårbarheter. Bevis: en SBOM per release, omvärderad mot nya säkerhetsmeddelanden, och en registrering av hur varje fynd hanterades.
• CC8.1 gäller ändringshantering: hur ändringar i infrastruktur, data, programvara och rutiner godkänns, utvecklas eller anskaffas, testas, godkänns och genomförs. Bevis: varje release byggd i en registrerad pipeline, ändringen i beroendena synlig från ett bygge till nästa, och policygrindar som en kontroll av vad som får levereras.

Kriterierna håller på att revideras. I oktober 2026 publicerade AICPA ett remissutkast till 2027 års Trust Services Criteria, med en riktad omstrukturering av kriterierna, synpunkter senast den 15 januari 2027 och ett föreslaget ikraftträdande för uppdrag som börjar den 31 december 2027 eller senare. Det är ett utkast, och kriteriernas nummer kan ändras: kontrollera den slutliga texten innan du kopplar bevis till de nya numren.

Om du redan använder en SOC 2-plattform, behåll den. Frågan är vad SBOM:en bakom dess kontroller visar: SOC 2-kontroller av SBOM:er i jämförelse.

NIS2

NIS 2-direktivet (EU) 2022/2555 gäller väsentliga och viktiga entiteter i de sektorer som det listar. Om du läser det här som leverantör av programvara eller enheter omfattas du oftast inte själv. Det gör din kund, och dess skyldigheter når dig som frågor. Artikel 21 fastställer åtgärderna för hantering av cybersäkerhetsrisker, och tre avsnitt ger upphov till de flesta av frågorna (återgivna i sammandrag):

• Artikel 21.2 d: säkerhet i leveranskedjan, inklusive säkerhetsrelaterade aspekter av förbindelserna mellan varje entitet och dess direkta leverantörer eller tjänsteleverantörer.
• Artikel 21.2 e: säkerhet vid förvärv, utveckling och underhåll av nätverks- och informationssystem, inklusive hantering och offentliggörande av sårbarheter.
• Artikel 21.3: entiteterna ska beakta de sårbarheter som är specifika för varje direkt leverantör och tjänsteleverantör, och den övergripande kvaliteten på deras leverantörers och tjänsteleverantörers produkter och cybersäkerhetsrutiner, inklusive deras förfaranden för säker utveckling. Det är den meningen som blir till ett frågeformulär på ditt skrivbord.

Genomförandeförordning (EU) 2024/2690

Kommissionens genomförandeförordning (EU) 2024/2690 av den 17 oktober 2024 fastställer de tekniska och metodologiska kraven för åtgärderna i artikel 21.2 för leverantörer av DNS-tjänster, toppdomänregister, leverantörer av molntjänster, leverantörer av datacentraltjänster, leverantörer av nätverk för innehållsleverans, leverantörer av hanterade tjänster, leverantörer av hanterade säkerhetstjänster, onlinemarknadsplatser, onlinesökmotorer, plattformar för sociala nätverkstjänster och tillhandahållare av betrodda tjänster. Den binder inte de övriga NIS2-sektorerna, men den är den mest detaljerade offentliga beskrivningen av vad säkerhet i leveranskedjan betyder, och andra köpare lånar från den. De punkter som når leverantörer, återgivna i sammandrag:

Punkt i bilagan	Vad den säger	Vad en leverantör får frågor om
5.1.2(a)	Vid val av leverantör beaktas leverantörernas och tjänsteleverantörernas cybersäkerhetsrutiner, inklusive deras förfaranden för säker utveckling	Hur utvecklar ni säkert, och hur vet ni vad som ingår i er produkt?
5.1.4(e) och (f)	Avtalen anger, när det är lämpligt, rätten att granska eller att få granskningsrapporter, och en skyldighet för leverantörer och tjänsteleverantörer att hantera sårbarheter som utgör en risk för entiteten	Kommer ni att hantera sårbarheter i det ni levererar, och kan vi få se bevisen?
5.2	Ett register över direkta leverantörer, med en förteckning över de IKT-produkter, IKT-tjänster och IKT-processer som var och en tillhandahåller	Vilka produkter och versioner levererar ni till oss?
6.1.2(c)	Vid förvärv av IKT-tjänster eller IKT-produkter: information som beskriver de hårdvaru- och programvarukomponenter som används i IKT-tjänsterna eller IKT-produkterna	Vilka hårdvaru- och programvarukomponenter innehåller er produkt? Det närmaste någon text på den här sidan kommer en SBOM, och den nämner ändå ingen.
6.10	Sårbarhetshantering: bevaka information om sårbarheter via kanaler som meddelanden från CSIRT eller information från leverantörer eller tjänsteleverantörer (6.10.2(a)), och när en sårbarhet inte behöver åtgärdas, dokumentera och motivera skälet (6.10.3)	Hur kommer ni att informera oss om sårbarheter, och varför är just den här inget problem?

Den sista punkten beskriver ett uttalande om att en produkt inte påverkas, med motivering. Det är vad ett VEX-dokument innehåller, även om förordningen inte anger något format.

Exempel: ett frågeformulär från en NIS2-kund

Fem frågor av det slag som en kund härleder ur de punkterna, med de bevis som en leverantör kan bifoga. En del svar kommer från registreringar som dina verktyg sparar; andra är policyer som du skriver.

Fråga	Bevis att bifoga	Registrering eller policy
"Lista programvarukomponenterna i den produktversion ni levererar till oss." (6.1.2(c))	SBOM:en för den versionen, i CycloneDX eller SPDX, med fullständigheten angiven	Registrering
"Beskriv er sårbarhetshantering och dess tidsramar." (5.1.4(f))	Din rutin för sårbarhetshantering, med allvarlighetsnivåer och måltider	Policy
"Vilka av versionerna vi kör innehöll det sårbara biblioteket, och sedan när?" (6.10)	Bygghistorik som visar varje bygge som innehöll komponenten, med datum	Registrering
"Varför påverkar den här CVE:n inte oss?" (6.10)	Ett uttalande om att produkten inte påverkas, med motivering, som "den sårbara koden finns inte med"	Registrering, baserad på din bedömning
"Hur kan forskare rapportera sårbarheter i era produkter?" (5.1.2(a))	Din policy för samordnat offentliggörande av sårbarheter	Policy

En skillnad att hålla isär: för produkter med digitala element som säljs i EU kräver Cyber Resilience Act faktiskt en SBOM. Det gör inte NIS2.

DORA, om du säljer till finansiella entiteter

Digital Operational Resilience Act, förordning (EU) 2022/2554, gäller finansiella entiteter, inte deras leverantörer direkt. Finansiella entiteter måste identifiera och dokumentera sina IKT-tillgångar och deras ömsesidiga beroenden och föra förteckningar över dem (artikel 8.1, 8.4 och 8.6), hantera IKT-tredjepartsrisk som en del av sin IKT-risk (artikel 28.1), föra ett informationsregister över alla sina avtal om IKT-tjänster (artikel 28.3) och ta in minimibestämmelser i de avtalen (artikel 30). DORA nämner inte SBOM:er. För en leverantör av programvara till en bank hjälper en komponentlista per release kunden att uppfylla artikel 8.

En beviskarta för alla ramverk

Raderna är bevis; varje cell anger den kontroll, det kriterium eller den punkt som beviset stöder, eller "inte direkt".

Bevis	ISO/IEC 27001:2022	SOC 2	NIS2 och 2024/2690	DORA
1. En SBOM per release, med fullständigheten angiven	5.9, 5.21, 8.8	CC7.1	Art. 21.2 d; 6.1.2(c)	Art. 8 (kundens förteckning)
2. Löpande omvärdering mot nya säkerhetsmeddelanden	8.8	CC7.1	Art. 21.2 e; 6.10	Inte direkt
3. Bygghistorik: vilka releaser som innehöll en komponent, och sedan när	8.8	CC7.1, CC8.1	6.10	Inte direkt
4. Dokumentation av triage och vidarebefordran	8.8	CC7.1	Art. 21.2 e; 6.10	Inte direkt
5. Uttalanden om att en produkt inte påverkas, med motivering	8.8	CC7.1	6.10	Inte direkt
6. Policygrindar som stoppar ett bygge	8.25, 8.29	CC8.1	Art. 21.2 e	Inte direkt
7. Leverantörers SBOM:er bevakade tillsammans med dina egna	5.19, 5.21, 5.22	CC7.1	Art. 21.2 d, 21.3; 5.2, 6.10	Art. 28.1
8. Egress-policy och nätverksregistreringar för bygget	8.25	CC8.1	Art. 21.2 d	Inte direkt

Vad en SBOM inte bevisar

• Din åtkomstkontroll, incidenthantering, kontinuitet, personalsäkerhet, kryptografi eller fysiska säkerhet.
• Att någon har åtgärdat något. Det är din process, och dess dokumentation.
• Att din egen kod är fri från brister. Kodgranskning, SAST och tester är bevisen för det.
• Vad som finns i binärfiler som du har fått utan SBOM.
• Att du är certifierad. En SBOM är inget certifikat, och ett certifikat som din verktygsleverantör har certifierar leverantörens eget ledningssystem, inte dig.

Var CRACI passar in

CRACI ersätter dina GitHub-hostade runners och registrerar vad varje bygge drog in, så att SBOM:en kommer från själva releasebygget, med en fullständighetsstatus för varje jobb.

• Bevakade SBOM:er omvärderas löpande när nya sårbarheter publiceras (sårbarhetsspårning).
• Bygghistoriken visar vilka byggen som innehöll ett sårbart beroende, och därmed perioden du var exponerad, inom din lagringstid. Om din revision omfattar en längre period, exportera varje releases SBOM och spara den med releasen.
• Säkerhetsteam triagerar de sårbarheter som hittas och skickar dem till de team som äger åtgärden, och CRACI stöder VEX för att registrera vilka produkter en sårbarhet inte påverkar.
• Policygrindar kan stoppa ett bygge vid fynd, även ett bygge som innehåller en specifik CVE.
• SBOM:er från tredje part kan läggas till, så att inköpta komponenter bevakas tillsammans med dina egna byggen.
• SBOM:er exporteras som CycloneDX eller SPDX, och API:t returnerar SBOM:er, nätverksspårningar och proveniensdata. Egress-policyn registrerar och begränsar vart varje bygge får ansluta.

CRACI levererar bevis för de här kontrollerna. Det gör dig inte ISO 27001- eller SOC 2-kompatibel eller redo för NIS2, och det är ingen plattform för automatiserad efterlevnad. CRACI:s eget certifikat är en separat sak: CRACI Corporation Oy:s ledningssystem för informationssäkerhet för utveckling och drift av CRACI-plattformen är certifierat enligt ISO/IEC 27001, utfärdat av Into Certification. Det gäller hur CRACI driver sin tjänst, inte din organisation eller dina produkter. Se säkerhet hos CRACI, och så fungerar CRACI för hela plattformen.

När CRACI inte är svaret

• Dina byggen körs inte på GitHub Actions. Det är den enda CI som CRACI har stöd för i dag; andra CI-system finns på färdplanen.
• Du behöver en plattform för automatiserad efterlevnad för policyer, behörighetsgranskningar och revisorns arbetsflöde. Behåll eller köp en; se SOC 2-kontroller av SBOM:er i jämförelse.
• Din brist på bevis är mest organisatorisk: policyer, utbildning, incidenthantering.
• Din största leverantörsrisk är binärfiler som du får utan SBOM:er. Binäranalys svarar på det.

Svarar du på en kunds förfrågan? Se hur du svarar på en kunds SBOM-förfrågan, guiden för komponentleverantörer och checklistan som din kund kommer att använda.

SBOM:er som underlag för efterlevnad: vanliga frågor

Kräver ISO 27001 en SBOM?

Nej. ISO/IEC 27001:2022 nämner inte SBOM:er. Kontrollerna 5.9 (förteckning), 5.21 (IKT-leveranskedjan) och 8.8 (tekniska sårbarheter) i bilaga A kräver utfall som en SBOM stöder, och organisationen och dess revisor avgör vilka bevis som räcker.

Kräver SOC 2 en SBOM?

Nej. Trust Services Criteria är beskrivningar av utfall och nämner inte SBOM:er. En SBOM per release, omvärderad mot nya säkerhetsmeddelanden, är bevis för CC7.1, och en registrerad byggpipeline stöder CC8.1 om ändringshantering.

Kräver NIS2 en SBOM?

Nej. Artikel 21.2 d kräver säkerhet i leveranskedjan och 21.2 e sårbarhetshantering, utan att nämna SBOM:er. Genomförandeförordning (EU) 2024/2690, som gäller vissa leverantörer av digitala tjänster, kräver i punkt 6.1.2(c) information om hårdvaru- och programvarukomponenterna i IKT-produkter, fortfarande utan ordet SBOM.

Vilka kontroller i bilaga A till ISO 27001 stöder en SBOM?

Främst 5.9 (förteckning över information och andra tillhörande tillgångar), 5.19 till 5.22 (leverantörer och IKT-leveranskedjan) och 8.8 (hantering av tekniska sårbarheter). En byggregistrering berör delvis 8.25, 8.29 och 8.30. 8.26 till 8.28 handlar om krav, design och kod, utanför en SBOM.

Vad ber NIS2-kunder sina programvaruleverantörer om?

Oftast en beskrivning av säker utveckling, komponenterna i den levererade versionen, ett åtagande att hantera sårbarheter, ett sätt att ta emot sårbarhetsinformation och motiveringar när en sårbarhet inte är tillämplig. Frågorna kommer från artikel 21.3 och, för vissa sektorer, leverantörspunkterna i genomförandeförordning 2024/2690.

Är en SBOM tillräckliga bevis för kontroll 8.8 i ISO 27001?

Nej. Den visar vad varje release innehåller. Kontroll 8.8 kräver också bevis för att du skaffar information om sårbarheter, bedömer din exponering och agerar. Kombinera SBOM:en med löpande omvärdering, en registrering av påverkade releaser och de beslut du fattade.

Vad är skillnaden mellan att vara regelefterlevande och att ha bevis?

Efterlevnad betyder att dina processer uppfyller ramverkets krav, enligt bedömningen av en revisor eller en kund. Bevis är det som visar att processerna fungerar. En SBOM är bevis för några få kontroller. Den gör dig inte regelefterlevande enligt något ramverk.