SBOM'er som dokumentation for ISO 27001, NIS2 og DORA

Klokken er 07:42 en fredag, da Amelia, CISO i en hurtigt voksende fintech-virksomhed, modtager den alarm, ingen sikkerhedsleder ønsker at se.

Et udbredt open source-bibliotek har en kritisk sårbarhed med fjernudførelse af kode. SCA-værktøjet (Software Composition Analysis) viser, at komponenten muligvis findes i autentifikationstjenesten, måske i fakturering og muligvis i en tredjeparts API-wrapper, der bruges i betalingsflowet. Udviklingsteamet skal bruge tid på at bekræfte det. Juridisk afdeling spørger, om NIS2-underretningsfristen er begyndt at løbe. DORA-programlederen spørger, om den berørte tjeneste understøtter en kritisk eller vigtig funktion for en finansiel enhed. Salg spørger, om det vil blokere en fornyelse. Bestyrelsen stiller det enkleste og sværeste spørgsmål: “Er vi eksponeret?”

Uden en softwarestykliste er det ærlige svar ofte: “Det ved vi ikke endnu.”

I 2026 er det svar ikke kun et teknisk hul. Det er en governance-svaghed, en kontraktlig risiko, en revisionseksponering og, for regulerede enheder, et robusthedsproblem. SBOM’er er gået fra DevSecOps-hygiejne til revisionsbevis på bestyrelsesniveau for dokumentation af softwareforsyningskæden, drift af ISO/IEC 27001:2022-kontroller, NIS2-cybersikkerhedsrisikostyring, DORA-styring af IKT-tredjeparter, GDPR-ansvarlighed og kunders due diligence.

Nøglen er ikke blot at generere en SBOM-fil. Nøglen er at dokumentere, at softwarekomponenter er identificeret, godkendt, overvåget, risikovurderet, patchet, kontraktligt reguleret og sporbare til ansvarlige ejere. Det er her, Clarysecs politikbibliotek, Zenith Blueprint: En revisors 30-trins køreplan og Zenith Controls: Vejledningen til tværgående compliance omdanner et udviklerartefakt til juridisk forsvarlig compliance-dokumentation.

Hvorfor SBOM’er nu er revisionsbevis for softwareforsyningskæden

En SBOM er en fortegnelse over softwarekomponenter, herunder open source-pakker, kommercielle biblioteker, versioner, kilder, licenser og afhængighedsrelationer. En brugbar SBOM hjælper med at besvare fire spørgsmål, som tilsynsmyndigheder, kunder og bestyrelser nu fokuserer på:

1. Hvad findes i vores software?
2. Hvor er den udrullet?
3. Er den sårbar, ikke længere understøttet, uden licens eller ikke godkendt?
4. Hvem ejer afhjælpning, afbødning eller risikoaccept?

Disse spørgsmål knytter sig direkte til moderne juridiske og regulatoriske forventninger.

NIS2 gælder for mange mellemstore og store enheder i væsentlige og vigtige sektorer, herunder digital infrastruktur, cloud computing-tjenester, datacentertjenesteudbydere, udbydere af administrerede tjenester, udbydere af administrerede sikkerhedstjenester, onlinemarkedspladser, søgemaskiner, sociale netværksplatforme og visse digitale udbydere. Den kan også finde anvendelse på grundlag af national udpegning og sektorspecifik gennemførelse. For omfattede enheder kræver NIS2, at ledelsesorganer godkender foranstaltninger til cybersikkerhedsrisikostyring og fører tilsyn med implementeringen. Article 21 omfatter forsyningskædesikkerhed, sikker anskaffelse, sikker udvikling og vedligeholdelse, håndtering og offentliggørelse af sårbarheder, hændelseshåndtering, forretningskontinuitet, politik for aktivstyring, adgangsstyring, kryptografi, vurdering af effektivitet og cyberhygiejne.

DORA, der finder anvendelse fra 17. januar 2025, etablerer en ensartet EU-ramme for digital operationel robusthed for finansielle enheder. Den dækker styring af IKT-risiko, rapportering af IKT-relaterede hændelser, robusthedstest, styring af IKT-tredjepartsrisiko, kontraktlige aftaler og tilsyn med kritiske IKT-tredjepartsudbydere. DORA forventer, at finansielle enheder identificerer IKT-aktiver, IKT-understøttede forretningsfunktioner, afhængigheder, sammenkoblinger, sårbarheder, risikoscenarier, ændringer og processer understøttet af tredjeparter.

GDPR tilføjer et databeskyttelseslag. Hvis en sårbar komponent påvirker systemer, der behandler personoplysninger, bliver spørgsmålet, om personoplysninger kan være blevet tilgået, ændret, mistet, videregivet eller på anden måde kompromitteret. Dataansvarlige og databehandlere har behov for revisionsbevis, der viser, at de kan identificere berørte systemer, dataflows, underdatabehandlere og konsekvensen af et brud.

NIST CSF 2.0 forstærker samme driftsmodel gennem GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND og RECOVER. Resultaterne for forsyningskæden forventer leverandøransvar, kritikalitet, kontraktlige krav, due diligence, overvågning, hændelsesplanlægning og bestemmelser for relationens ophør.

Når Amelias bestyrelse spørger, om fintech-virksomheden er eksponeret, kan en organisation med SBOM-understøttelse svare med dokumentation:

• Hvilke produkter og releases der indeholder den sårbare komponent
• Hvilke udrullede miljøer der er berørt
• Hvilke kunder, regioner, funktioner og dataflows der er forbundet
• Hvilken leverandør eller intern ejer der er ansvarlig
• Hvilke kompenserende kontroller der er aktive
• Om tærskler i NIS2, DORA, GDPR eller kontrakter kan være udløst
• Hvilken rettelse, afbødning, undtagelse eller risikoaccept der er godkendt

Det er forskellen på en komponentliste og et kontrolsystem.

ISO 27001:2022 er rygraden i SBOM-styring

ISO/IEC 27001:2022 er et stærkt fundament for SBOM-styring, fordi den er en standard for et ledelsessystem og ikke blot en teknisk tjekliste. Dens klausuler kræver, at organisationer definerer kontekst, interessenter, omfang, ledelsesforpligtelse, politik, roller, risikovurdering, risikobehandling, målsætninger, evaluering af præstation, intern revision, ledelsens gennemgang og løbende forbedring.

SBOM-programmer fejler, når de ligger uden for ISMS’et. Udviklingsteamet kan generere filer, men ingen håndhæver SLA’er for afhjælpning af sårbarheder, leverandørforpligtelser, opbevaring af revisionsbevis, risikoaccept eller regler for kundekommunikation. ISO 27001 løser dette ved at gøre SBOM’er til en del af organisationens risikostyringssystem.

I henhold til klausul 4.1 til 4.4 fastlægger organisationen interne og eksterne forhold, interessentkrav, retlige og regulatoriske forpligtelser, kontraktlige forventninger og ISMS-omfang. For SBOM-dokumentation bør omfanget udtrykkeligt omfatte:

• Produkter og tjenester leveret til kunder
• Cloud- og SaaS-produktionsmiljøer
• CI/CD-pipelines, koderepositorier og artefaktregistre
• Open source- og kommercielle softwarekomponenter
• Outsourcet udvikling og integrationspartnere
• IKT-tredjepartsudbydere og underleverandører
• Kundesikkerhedskrav efter DORA, NIS2, GDPR og kontrakter

Klausul 5.1 til 5.3 gør risiko i softwareforsyningskæden til et ledelsesanliggende. Ledelsen skal tilpasse sikkerhedsmål til forretningens retning, stille ressourcer til rådighed, tildele ansvar og kommunikere politikken. Klausul 6.1.2 og 6.1.3 omdanner SBOM-konstateringer til revisionsbevis for risikovurdering og risikobehandling. En kritisk sårbar komponent i en interneteksponeret autentifikationstjeneste er ikke blot en sag. Det er et risikoscenarie, der påvirker fortrolighed, integritet, tilgængelighed, kontraktlige forpligtelser, regulatorisk rapportering og operationel robusthed.

De mest relevante ISO/IEC 27001:2022 Anneks A-kontroller for SBOM-dokumentation er:

Clarysec kortlægger disse relationer gennem ISO/IEC 27002:2022-attributter i Zenith Controls. Eksempelvis behandler Zenith Controls ISO/IEC 27002:2022-kontrol 5.21, “Styring af informationssikkerhed i IKT-forsyningskæden”, som forebyggende, beskyttende for fortrolighed, integritet og tilgængelighed, tilpasset cybersikkerhedskonceptet Identify og opererende på tværs af governance-, økosystem- og beskyttelsesdomæner. Den behandler kontrol 8.25, “Sikker udviklingslivscyklus”, som forebyggende og tilpasset Protect. Den behandler kontrol 8.8, “Styring af tekniske sårbarheder”, som forebyggende og tilpasset Identify og Protect, og forbinder sårbarhedsstyring med governance, økosystem, beskyttelse og forsvar.

Denne oversættelse er vigtig, fordi forskellige reviewere stiller forskellige spørgsmål. En ISO-revisor kan spørge, om komponentrisiko indgår i Anvendelseserklæringen. En DORA-reviewer kan spørge, om en komponent understøtter en kritisk eller vigtig funktion. En kunde kan spørge, om uafklarede sårbarheder overskrider kontraktlige SLA’er. Det samme SBOM-bevis kan understøtte alle tre, hvis det styres korrekt.

Clarysecs politiklag for revisionsklare SBOM’er

Et pålideligt SBOM-program kræver politiksprog. Udviklere skal vide, hvad der skal registreres. Indkøb skal vide, hvad leverandører skal levere. Sikkerhedsfunktionen skal vide, hvilke konstateringer der udløser eskalering. Compliance skal vide, hvilket revisionsbevis der skal opbevares.

For mindre organisationer etablerer Politik for sikker udvikling - SMV den mindst mulige effektive SBOM-kontrol:

Direktøren (GM) eller en udpeget udvikler skal vedligeholde en liste over alle anvendte eksterne komponenter, herunder: 6.6.2.1 Version og kilde 6.6.2.2 Kendte sårbarheder eller patchstatus 6.6.2.3 Seneste opdaterings- eller gennemgangsdato

Kravet er enkelt, men stærkt. Det etablerer synlighed over versioner, sporbarhed til kilde, sårbarhedsstatus og gennemgangsfrekvens.

Politik for krav til applikationssikkerhed - SMV tilføjer livscyklusgennemgang:

Ethvert tredjepartsværktøj, plugin eller eksternt kodebibliotek, der anvendes i en applikation, skal registreres og gennemgås årligt med henblik på sikkerhedspåvirkning og patchstatus.

Politik for sårbarheds- og patchstyring - SMV forbinder SBOM’er med afhjælpning:

Udviklere skal overvåge og opdatere tredjepartsbiblioteker (f.eks. open source-pakker)

For enterprise-miljøer hæver Politik for sikker udvikling forventningen:

Brug af open source- eller tredjepartskode skal godkendes, spores og valideres gennem:

Den gør også scanning obligatorisk:

Alle tredjepartskomponenter skal scannes for sårbarheder før udrulning og under drift ved brug af automatiserede værktøjer.

Outsourcet udvikling skal følge samme standard. Politik for outsourcet udvikling kræver:

Sikker brug af open source-biblioteker, underlagt sårbarhedsscanning og godkendelse

Leverandørkontrakter kræver rettigheder til håndhævelig dokumentation. Politik for tredjeparts- og leverandørsikkerhed - SMV kræver kontraktklausuler om fortrolighed, sikkerhedsforpligtelser, underretningsfrister ved brud, revisionsrettigheder, begrænsninger for videre underleverandører og sikker ophørshåndtering:

Kontrakter skal indeholde obligatoriske klausuler om: 5.3.1 Fortrolighed og non-disclosure 5.3.2 Informationssikkerhedsforpligtelser 5.3.3 Underretningsfrister ved brud på persondatasikkerheden (f.eks. inden for 24-72 timer) 5.3.4 Revisionsrettigheder eller adgang til dokumentation for efterlevelse 5.3.5 Begrænsninger for videre underleverandører uden godkendelse 5.3.6 Ophørsvilkår, herunder sikker returnering eller destruktion af data

For enterprise-kunder omfatter Politik for tredjeparts- og leverandørsikkerhed:

Revisionsrettigheder, inspektionsadgang og mulighed for at anmode om sikkerhedsdokumentation

Hvis en SaaS-udbyder, partner inden for outsourcet udvikling eller kommerciel softwareleverandør ikke vil levere sikkerhedsdokumentation, sårbarhedsstatus, underretningsforpligtelser eller revisionsadgang, har dokumentationen for softwareforsyningskæden et blindt punkt.

Politik for risikostyring af leverandørafhængigheder omdanner afhængighedskoncentration til målbar robusthedsrisiko:

Register over leverandørafhængigheder: Vendor Management Office (VMO) skal vedligeholde et ajourført register over alle kritiske leverandører, herunder oplysninger som leverede tjenester/produkter; om leverandøren er eneleverandør; tilgængelige alternative leverandører eller substitutionsmulighed; gældende kontraktvilkår; og en vurdering af konsekvensen, hvis leverandøren svigter eller kompromitteres. Registeret skal tydeligt identificere leverandører med høj afhængighed (f.eks. leverandører, hvor der ikke findes et hurtigt alternativ).

Dette register bør forbindes med SBOM’er. Hvis et kritisk bibliotek kommer fra en eneleverandør, understøtter et reguleret kundemiljø og ikke har nogen hurtig erstatning, er det ikke blot en pakke. Det er en robusthedsafhængighed.

Fra SBOM-fil til operationel kontrol på én sprint

Et praktisk SBOM-program bør starte med én produktlinje og ét produktionsmiljø. Forsøg ikke at oprette en fortegnelse over hele organisationen på dag ét. Hvis Amelias fintech-virksomhed begynder med sit kundeonboarding- og betalingsflow, kan teamet etablere en gentagelig evidensmodel, før den skaleres.

Trin 1: Definér SBOM-omfanget i ISMS’et

Opret en omfangsbeskrivelse, der er knyttet til jeres ISMS-omfang og regulatoriske drivere:

• Produkt: SaaS-platform til kundeonboarding og betaling
• Miljø: EU-produktion
• Repositorier: auth-service, billing-service, payment-api, reporting-api, frontend-app
• Build-systemer: Git-udbyder, CI/CD-platform, containerregister
• Udrulning: Kubernetes-klynge, administreret database, objektlagring
• Data: kontodata, autentifikationslogfiler, faktureringsmetadata, betalingsreferencer
• Kunder: finansielle enheder i EU og kommercielle kunder
• Regulatoriske drivere: ISO 27001:2022, NIS2-kundedokumentation, DORA IKT-tredjeparts-due diligence, GDPR-ansvarlighed for sikkerhed

Dette er i overensstemmelse med ISO 27001-klausul 4-logikken for omfang og NIST CSF Profile-scoping.

Trin 2: Generér og opbevar SBOM’er ved build

Konfigurér CI/CD-pipelines til at generere en SBOM for hvert buildartefakt, herunder containerimages. Standardformater som CycloneDX og SPDX anvendes ofte. Opbevar hver SBOM i et kontrolleret repository for revisionsbevis, knyttet til build-ID, commit-hash, udrulningsregistrering og releaseversion.

Dette understøtter direkte kravet i Politik for sikker udvikling - SMV om at vedligeholde version, kilde, kendt sårbarheds- eller patchstatus og gennemgangsdato.

Trin 3: Berig SBOM-data med udnyttelighed og forretningskontekst

Stop ikke ved en pakkeliste. Tilføj operationel risikokontekst:

• Er komponenten sårbar?
• Er den sårbare funktion tilgængelig?
• Er tjenesten interneteksponeret?
• Behandler tjenesten personoplysninger?
• Understøtter den en kritisk eller vigtig funktion for en DORA-kunde?
• Er der en patch tilgængelig?
• Findes der en kompenserende kontrol?
• Er risikoaccept godkendt af risikoejeren?

En kritisk CVE i en pakke, der kun anvendes til test, er noget andet end en kritisk CVE i en produktionsautentifikationstjeneste. ISO 27001-klausulerne om risikovurdering og risikobehandling hjælper med at gøre denne sondring juridisk forsvarlig.

Trin 4: Knyt SBOM’er til leverandørkontroller og kontroller for outsourcet udvikling

Hvis en komponent leveres af en kommerciel leverandør eller en partner inden for outsourcet udvikling, skal leverandørregistreringen opdateres:

Dette understøtter NIS2 Article 21 om forsyningskædesikkerhed og DORA Article 28-forventninger til strategi for IKT-tredjepartsrisiko, due diligence, kontraktlige sikkerhedsforanstaltninger, registre over oplysninger, revisionsplanlægning, ophørsrettigheder og exitstrategier.

Trin 5: Definér afhjælpningsregler og revisionsbevis

Knyt SLA’er for afhjælpning til forretningspåvirkning og ikke kun til CVSS-scores.

Det er her, SBOM’er bliver nyttige for NIS2, DORA og GDPR. En afhjælpningsarbejdsgang bør tage højde for potentiale for væsentlige hændelser, konsekvens af større IKT-relaterede hændelser, kriterier for brud på persondatasikkerheden, kontraktlige underretningsforpligtelser og påvirkning af operationel robusthed.

Trin 6: Tilføj et release-kontrolpunkt

Før udrulning skal pipeline- eller ændringsprocessen bekræfte:

• SBOM er genereret korrekt
• Ingen kritiske ikke-godkendte sårbarheder er tilbage
• Nye tredjepartskomponenter er godkendt
• Licenspolitikken er bestået
• SCA, SAST, DAST eller anden påkrævet test er gennemført
• Ændringssagen er knyttet
• Tilbagerulningsplan er dokumenteret for højrisikoreleases

Dette forbinder A.8.25 sikker udvikling, A.8.29 sikkerhedstest og A.8.32 ændringsstyring i én samlet arbejdsgang, der kan revideres.

Trin 7: Opbyg release-dokumentationspakken

For hver release skal følgende opbevares:

• SBOM-fil
• Build-ID og commit-hash
• SCA-scanningsoutput
• Registrering af sårbarhedstriage
• Godkendte undtagelser
• Ændringsgodkendelse
• Udrulningsregistrering
• Testresultater
• Leverandørdokumentation, hvis relevant
• Hændelses- eller problemregistrering, hvis releasen afhjælpede en sårbarhed

Når en revisor spørger, hvordan tredjepartsbiblioteker styres i produktion, skal Amelias team ikke lede i Slack-tråde. De åbner release-dokumentationspakken.

Kortlægning på tværs af compliance: ét SBOM-program, mange forpligtelser

Den kommercielle værdi af et SBOM-program stiger, når det kortlægges én gang og genbruges på tværs af frameworks. Clarysecs tilgang til tværgående compliance undgår dobbeltarbejde ved at oversætte samme revisionsbevis til forskellige dokumentationssprog.

NIS2-hændelsesrapportering kan gå hurtigt, når udnyttelse forårsager eller kan forårsage alvorlig driftsafbrydelse, økonomisk tab eller betydelig materiel eller immateriel skade. NIS2 anvender trinvis rapportering, herunder tidlig varsling inden for 24 timer efter kendskab, hændelsesunderretning inden for 72 timer og en endelig rapport inden for én måned efter hændelsesunderretningen. SBOM’er hjælper med at afgøre, om den berørte komponent er til stede, om kundetjenester er berørt, og om grænseoverskridende påvirkning er sandsynlig.

DORA anvender en struktureret livscyklus for IKT-hændelser, herunder detektion, registrering, klassificering, rodårsagsanalyse, eskalering, kommunikationsplaner, eskalering til ledelsesorganet og regulatorisk rapportering af større IKT-relaterede hændelser. SBOM-dokumentation understøtter klassificering, fordi den forbinder en sårbar komponent med berørte kunder, nedetid, geografisk udbredelse, datatab, tjenestens kritikalitet og økonomisk påvirkning.

NIST CSF 2.0 tilføjer nyttigt sprog til kundedokumentation. Zenith Controls kortlægger A.5.21 til governance-resultater for forsyningskæden som GV.SC-05, hvor cybersikkerhedskrav til leverandører er fastlagt, kommunikeret og integreret i kontrakter og andre aftaler. Krav om SBOM’er, offentliggørelse af sårbarheder, revisionsbevis og afhjælpningsfrister bliver en kontraktlig kontrol og ikke en ad hoc-anmodning.

Hvordan Zenith Blueprint sekventerer arbejdet

Zenith Blueprint omdanner kontrolsprog til en implementeringskøreplan.

I risikostyringsfasen forbinder Step 14 sikker udvikling, CI/CD-kontroller, scanning af afhængigheder, ændringsstyring, hændelseshåndtering og træning af udviklere. I fasen Controls in Action er Step 20 udtrykkelig om tredjeparts- og open source-komponenter:

Denne kontrol gælder også for tredjeparts- og open source-komponenter. Brug af eksterne biblioteker er standardpraksis, men hver inkludering er en tillidsbeslutning. Udviklere bør vurdere afhængigheder ud fra omdømme, vedligeholdelsesfrekvens, kendte sårbarheder og licens- begrænsninger. Værktøjer som SBOM’er (Software Bill of Materials) bliver stadig vigtigere til at spore, hvad der er indlejret i jeres stack.

Step 21 beskriver sikkerhedstest som kontekstafhængig og anbefaler lagdelt test for forretningskritiske eller interneteksponerede systemer, herunder Software Composition Analysis for tredjepartsbiblioteker, statisk og dynamisk analyse, penetrationstest, validering af trusselsmodellering, misbrugscasetest, fuzzing og manuel eksplorativ test.

Step 23 behandler leverandøraftaler, herunder fortrolighedsforpligtelser, ansvar for adgangsstyring, tekniske og organisatoriske foranstaltninger, frister for rapportering af hændelser, revisionsret, underleverandørkontroller og bestemmelser ved kontraktophør.

Den praktiske lære er enkel. SBOM’er hører hjemme i risikostyring, sikker udvikling, test, leverandørstyring, hændelseshåndtering og ledelsesrapportering.

Revisionsperspektivet: hvad forskellige reviewere vil teste

Et modent SBOM-program skal kunne modstå forskellige revisionsstile.

En ISO 27001:2022-revisor vil starte med ISMS’et. Revisoren vil spørge, om risiko i softwareforsyningskæden er omfattet, om interessentkrav omfatter NIS2, DORA-kunder, GDPR og kontrakter, om komponentrisiko indgår i risikometodikken, om Anvendelseserklæringen omfatter relevante Anneks A-kontroller, og om politikker implementeres over tid. Revisoren kan udtage én release som stikprøve og spore den fra politik til pipeline, SBOM, sårbarhedsscanning, ændringsgodkendelse, udrulning og overvågning efter release.

En DORA-reviewer eller finansiel kunde vil fokusere på operationel robusthed og IKT-tredjepartsrisiko. De kan spørge, hvilke komponenter der understøtter den tjeneste, som den finansielle enhed bruger, om tjenesten understøtter en kritisk eller vigtig funktion, hvordan IKT-aktiver og afhængigheder dokumenteres, om sårbarheder overvåges, om årlig test dækker kritiske systemer, og om kontrakter omfatter bistand, revisionsrettigheder, hændelsesunderretning, datalokation, underleverandører og ophørsvilkår.

En NIST CSF-assessor vil se efter resultater. Under GOVERN vil de teste juridisk, regulatorisk, kontraktlig, privatlivs- og forsyningskædestyring. Under IDENTIFY forventer de synlighed over aktiver, software og tjenester. Under PROTECT tester de sikker udvikling og pipeline-kontroller. Under DETECT og RESPOND undersøger de sårbarhedsalarmer, analyse, eskalering og kommunikation. Under RECOVER vil de spørge, hvordan kompromittering af komponenter påvirker genetablering og kundekommunikation.

En COBIT- eller ISACA-inspireret revisor vil fokusere på governance, ansvarlighed, risikoejerskab, kontroldesign og pålideligheden af revisionsbevis. Revisoren kan teste, om SBOM’er er komplette, om sårbarhedssager lukkes inden for politikken, om undtagelser udløber, om leverandørdokumentation er aktuel, og om ledelsen modtager meningsfuld rapportering.

Almindelige SBOM-fejl, der bør undgås

SBOM-programmer fejler typisk af forudsigelige årsager.

Den første fejl er at generere SBOM’er uden at opbevare dem som kontrolleret revisionsbevis. Hvis filen overskrives ved hvert build og ikke kan knyttes til en release, er den svagt revisionsbevis.

Den anden fejl er at adskille SBOM’er fra sårbarhedsstyring. En komponentliste uden triage, ejerskab, afhjælpning eller risikoaccept dokumenterer ikke kontroldrift.

Den tredje fejl er at udelade transitive afhængigheder. Sårbarheder skjuler sig ofte under det direkte afhængighedslag.

Den fjerde fejl er at holde outsourcet udvikling uden for processen. Hvis en leverandør leverer kode uden komponentoplysninger, scanningsdokumentation eller godkendelsesregistreringer, har softwareforsyningskæden et ustyret blindt punkt.

Den femte fejl er at underskrive leverandørkontrakter uden evidensrettigheder. Indkøb underskriver aftalen, udviklingsteamet bruger tjenesten, og sikkerhedsfunktionen opdager senere, at der ikke findes nogen revisionsret, ingen forpligtelse til offentliggørelse af sårbarheder, ingen begrænsning for underleverandører og ingen exit-support.

Den sjette fejl er ikke at kortlægge komponenter til forretningstjenester. En sårbar pakke betyder ikke meget, før man ved, om den påvirker autentifikation, betalinger, rapportering, patientdata, cloudadministration, kundeonboarding eller et reguleret finansielt flow.

Den syvende fejl er at skjule uafklarede kritiske sårbarheder for ledelsen. Både NIS2 og DORA gør ledelsesansvar eksplicit. Kritisk komponentrisiko skal være synlig i styringsfora og ikke begraves i udviklingsbacklogs.

Sådan ser god praksis ud i 2026

Et revisionsklart SBOM-program har tydelige kendetegn.

Der findes en godkendt politik, som kræver, at tredjeparts- og open source-komponenter godkendes, spores, scannes og gennemgås. CI/CD-pipelinen genererer SBOM’er automatisk. SCA-scanninger kører før udrulning og under drift, hvor det er relevant. Kritiske sårbarheder udløser defineret eskalering. Undtagelser har ejere, udløbsdatoer, kompenserende kontroller og risikoaccept.

Leverandørkontrakter omfatter sikkerhedsforpligtelser, underretningsfrister ved brud, revisionsrettigheder, underleverandørkontroller og bestemmelser om ophør. Kritiske leverandører gennemgås mindst årligt. Leverandørafhængighed og koncentrationsrisici er synlige. Teams inden for outsourcet udvikling følger de samme regler for sikker udvikling og komponentgodkendelse som interne teams.

Ledelsesrapportering forbinder teknisk risiko med forretningspåvirkning:

• Kritiske sårbare komponenter pr. produkt
• Eksponering pr. kunde eller reguleret tjeneste
• Åben afhjælpning ud over SLA
• Komponenter uden godkendt kilde
• Ikke-understøttede eller udtjente biblioteker
• Huller i leverandørdokumentation
• Undtagelser, der afventer fornyelse eller lukning
• Hændelser knyttet til komponentsårbarheder

Det er her, SBOM’er ophører med at være et compliance-artefakt og bliver et ledelsesværktøj.

Omdan SBOM’er til juridisk forsvarlig compliance-dokumentation

Næste gang en alarm om en kritisk komponent lander kl. 07:42, bør svaret ikke være: “Vi skal bruge to timer på at finde ud af, hvor den er.”

Det bør være: “Her er den berørte komponent, her er tjenesterne, her er kunderne, her er risikovurderingen, her er afhjælpningsplanen, og her er dokumentationen.”

Clarysec kan hjælpe jer med at designe det kontrolsystem. Vi hjælper organisationer med at definere SBOM-omfanget i ISMS’et, kortlægge ISO 27001:2022 Anneks A-kontroller til NIS2, DORA, GDPR, NIST CSF 2.0 og COBIT-inspirerede revisionsforventninger, implementere politikker for sikker udvikling og leverandører, opbygge release-dokumentationspakker og forberede revisionsklar dokumentation ved hjælp af Zenith Controls og Zenith Blueprint.

Klar til at omdanne jeres softwareforsyningskæde fra en kilde til usikkerhed til dokumentation for robusthed?

Download de relevante Clarysec-politikker, brug Zenith Blueprint til at sekventere implementeringen, og brug Zenith Controls til at kortlægge jeres dokumentation på tværs af ISO 27001:2022, NIS2, DORA og kundekrav til dokumentation. Kontakt Clarysec for at starte med en fokuseret SBOM-parathedsvurdering og opbygge et praktisk, revisionsklart program for dokumentation af softwareforsyningskæden.