Forordningen kræver, at softwarekomponentlisten som minimum dækker de vigtigste produktafhængigheder, hvilket i praksis læses som det øverste niveau. En liste, der stopper der, opfylder minimumskravet fra 11. december 2027, men den siger lidt om de komponenter, der ligger længere nede, og det er ofte dér, sårbarhederne findes.
Denne artikel handler om afstanden mellem minimum og brugbarhed. Pligterne i sig selv er gennemgået i artiklen om softwarekomponentlisten efter CRA.
Minimumskravet
Ordlyden i bilag I, del II, nr. 1, sætter gulvet ved de vigtigste produktafhængigheder og kræver et format, der både er maskinlæsbart og almindeligt anvendt. I den engelske udgave står der “top-level dependencies”. At det danske udtryk betyder det samme, er en tolkning, men det er den læsning, ENISA og de fleste andre bygger på.
Forordningen nævner intet format. Kommissionen har efter artikel 13, stk. 24, mulighed for at præcisere format og elementer ved en gennemførelsesretsakt. Ingen sådan retsakt var at finde i de kilder, vi læste i november 2026. Indtil da er det op til fabrikanten at vælge et format, der er almindeligt anvendt, og at begrunde dybden.
Hvad ENISA’s undersøgelse viser
ENISA offentliggjorde i juni 2026 rapporten “SBOM Adoption State of Play 2026”. Den bygger på 334 svar fra en spørgeskemaundersøgelse sidst i 2025. Omkring to tredjedele af svarene kom fra EU-baserede organisationer, og over to tredjedele fra organisationer med mere end 250 ansatte. Tallene er svar fra denne gruppe og ikke et billede af markedet.
Formater. 44 procent svarede, at de bruger CycloneDX, og 29 procent SPDX. 11 procent bruger intet standardformat, og 17 procent et proprietært format.
Største barriere. At opnå høj fuldstændighed var den største udfordring. 62 procent svarede, at det var temmelig eller ekstremt svært. Datakvalitet blev nævnt af 37 procent, og matchning mod sårbarheder var temmelig svært for 35 procent og ekstremt svært for 23 procent.
Dybde. 36 procent har brug for alle primære komponenter og deres direkte afhængigheder, med de ukendte markeret, men kun 29 procent modtager det fra deres leverandører. 24 procent har brug for fuld dybde, men kun 14 procent modtager det.
Minimum som mål. 59 procent har helt eller delvist automatiseret listen med minimumsindholdet, altså kun det øverste niveau. ENISA kalder det bekymrende for kvaliteten og anvendeligheden, at mange vil nøjes med minimumsindholdet.
Hvorfor det øverste niveau ikke rækker
Et typisk softwareprodukt har en håndfuld direkte afhængigheder, der hver trækker mange andre med sig. En liste i øverste niveau nævner den håndfuld. De transitive afhængigheder, altså afhængighedernes afhængigheder, står ikke på den.
ENISA peger på, at dybden afgør, om transitive afhængigheder kan vurderes. Bliver der offentliggjort en sårbarhed i et bibliotek tre led nede, kan en liste i øverste niveau ikke svare på, om produktet indeholder biblioteket. Svaret må findes på anden vis, og det tager tid.
At listen derfor er utilstrækkelig til overvågning, er vores slutning ud fra ENISA’s tekst. Forordningen kræver ikke mere end minimumsindholdet. Men den kræver også, at sårbarheder i produktet, herunder i komponenterne, håndteres effektivt i hele supportperioden (artikel 13, stk. 8). Den pligt bliver svær at opfylde, hvis man ikke ved, hvilke komponenter der er i produktet.
Dybde og format i en gennemgang
En gennemgang kan holde to ting adskilt. Opfylder listen minimumskravet? Og er den dyb nok til at understøtte den sårbarhedshåndtering, fabrikanten selv beskriver i den tekniske dokumentation?
Det første er et spørgsmål om ordlyden. Det andet er et spørgsmål om sammenhæng. Står der i dokumentationen, at fabrikanten overvåger alle komponenter for sårbarheder, men dækker listen kun det øverste niveau, passer de to ikke sammen. Det er et fund, selv om listen opfylder minimum.
Den tyske retningslinje BSI TR-03183-2 kræver rekursiv opløsning af afhængigheder helt ned til den første komponent, der ligger uden for det, I leverer. Retningslinjen binder ingen og skaber ikke formodning om overensstemmelse, men den viser, hvad en mere fuldstændig liste kan bestå af.
Formatvalget
CycloneDX er standardiseret af Ecma International som ECMA-424, og den aktuelle version er 1.7. SPDX er udgivet som international standard ISO/IEC 5962:2021, og den aktuelle version hos projektet er 3.0. Begge er maskinlæsbare og almindeligt anvendte i ENISA’s forstand. Vi rangerer dem ikke. Valget afhænger af, hvad jeres byggeværktøjer og kunder arbejder med.
Hvad det kræver, og hvad det koster at lade være
Det kræver en beslutning om, hvor dybt listen skal gå, og en begrundelse for den, der hænger sammen med den beskrevne sårbarhedshåndtering. For de fleste betyder det, at listen laves automatisk ved hvert byggeri med alle afhængigheder, som byggeværktøjet kender.
Nøjes I med minimum, kan I opfylde ordlyden og stadig stå uden svar, når en kunde eller myndighed spørger, om en bestemt sårbar komponent findes i produktet.
Det skal I lade være med
- At kalde minimumsindholdet tilstrækkeligt til overvågning · det øverste niveau viser ikke de transitive afhængigheder.
- At bruge ENISA’s procentandele som markedsandele · det er svar fra en bestemt gruppe.
- At vente på en formatretsakt, der ikke er vedtaget · formatet skal vælges og begrundes nu.
Det skal auditten kunne vise
- ☐ En begrundet beslutning om listens dybde.
- ☐ Sammenhæng mellem dybden og den beskrevne sårbarhedshåndtering.
- ☐ Valgt format og version, med dato.
- ☐ Markering af ukendte eller ufuldstændige afhængigheder i listen.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, artikel 13, stk. 8 og 24, og bilag I, del II, nr. 1, læst 13. november 2026.
- ENISA, SBOM Adoption State of Play 2026, afsnit 1.3, 2.1 og 2.4.2-2.4.4, læst 13. november 2026.
- BSI, TR-03183-2, version 2.1.0, afsnit 5.1, læst 13. november 2026.
- Ecma International, ECMA-424 og SPDX, specifikationer, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Tæl, hvor mange komponenter jeres liste har, og hvor mange byggeværktøjet faktisk henter. Forskellen viser afstanden.
- Softwarekomponentliste, afhængigheder og tredjepartskomponenter
- Softwarekomponentlisten (SBOM) efter CRA
Læs også: Overvågning af komponenter for hver understøttet version · Den tyske retningslinje TR-03183-2 som målestok
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
