Tredjepartsbiblioteker, SBOM og byggepipeline

Det meste af et moderne softwareprodukt er kode, I ikke selv har skrevet. Jeres udviklere bygger oven på biblioteker, der selv bygger på andre biblioteker, og koden når ud til kunderne gennem en automatisk kæde af værktøjer. Ledelsens spørgsmål er enkelt: Ved I, hvad produktet består af, og opdager I en sårbar komponent før kunderne gør? Svaret kræver tre ting, nemlig en komponentliste, der laves automatisk, en fast rutine for opdateringer og en pipeline, som kun de rigtige kan ændre.

Tre ord, der skal være på plads

Afhængigheder er de biblioteker og pakker, produktet bruger. De indirekte er dem, jeres biblioteker selv har med, og det er ofte dem, der er flest af, og som ingen har valgt bevidst.

Softwarekomponentliste, på engelsk SBOM (software bill of materials), er en maskinlæsbar oversigt over komponenterne i et produkt. Den svarer til varedeklarationen på en fødevare.

Byggepipeline er den automatiske kæde, der tager koden, tester den, bygger den og lægger den ud. Værktøjerne dertil kaldes ofte CI/CD.

Hvad reglerne siger om komponenter

Er jeres produkt omfattet af Cyber Resilience Act, skal I som fabrikant identificere og dokumentere komponenterne, herunder ved at udarbejde en softwarekomponentliste. Det følger af forordningens bilag I, del II, og kravene gælder fra 11. december 2027. Om produktet er omfattet, er en afklaring for sig.

Listen skal ikke offentliggøres. Det punkt bliver ofte misforstået. Markedsovervågningen kan bede om den, og Kommissionen kan præcisere formatet. Indtil da vælger mange et af de udbredte formater som CycloneDX eller SPDX. Det er et praktisk valg, og I bør følge med i, om der kommer en præcisering.

Forordningen kræver også omhu ved valg af komponenter, herunder ved fri software, der ikke er markedsført kommercielt. Omfanget følger risikoen. Kommissionens FAQ nævner blandt andet analyse af softwaresammensætning, gennemgang af komponentens egen komponentliste, hvis den findes, og kontrol af komponentens supportperiode. Det sidste er nyttigt i praksis. Et bibliotek, som ingen længere vedligeholder, er en risiko, også selv om det ikke har kendte sårbarheder i dag.

Også uden CRA kan kunderne spørge. Et spørgeskema fra kunden rummer ofte spørgsmål om, hvordan I følger med i sårbarheder.

Rutinen i et lille team

1. Lad pipelinen lave komponentlisten ved hver udgivelse. En liste, der er lavet i hånden, er forældet ugen efter. Gem listen sammen med den version, den hører til, for en kunde kan spørge til en gammel version.
2. Lås versionerne. Bibliotekernes versioner skal stå fast i en låsefil, så samme kode giver samme resultat i dag og om en måned. Ellers kan en ny version glide ind uden en beslutning.
3. Scan automatisk. Værktøjer kan sammenligne komponentlisten med kendte sårbarheder hver dag, også for versioner, I ikke længere udvikler på. OWASP Dependency-Track er et eksempel på et åbent værktøj til den slags.
4. Opdater lidt og ofte. Faste små opdateringer er mindre risikable end en stor opdatering en gang om året. Giv opgaven en plads i planen. Sidder den fast, er det et tegn på teknisk gæld.
5. Vurder, før I reagerer. Langt fra hver sårbarhed kan udnyttes i jeres produkt. Bruger I slet ikke den sårbare funktion, kan det stå som en begrundet vurdering. Hvem der må træffe den, skal være aftalt.
6. Beslut, før I tilføjer. En ny afhængighed er et valg, I skal leve med. Tre spørgsmål er nok: Vedligeholdes den? Hvor mange flere komponenter trækker den med? Passer licensen? Licensen er et andet spørgsmål end sårbarheder, og det behandles i licenser på open source.

Pipelinen er selv et mål

Pipelinen har typisk nøgler til produktionsmiljøet og kan ændre det, kunderne får. Derfor er den et af de mest værdifulde steder at ramme. Fire enkle regler dækker det meste:

• Ingen kan lægge kode i produktion uden om pipelinen.
• Ændringer i selve pipelinen gennemgås af en anden.
• Værktøjer og tilføjelser i pipelinen er fastlåst til kendte versioner og hentes fra steder, I har valgt.
• Pipelinens nøgler er kortlivede eller har så få rettigheder som muligt, se nøgler og adgangskoder i koden og pipelinen.

Købte cloudtjenester tæller med

Bruger produktet en andens færdige SaaS, fx til betaling eller mail, er den ifølge Kommissionens vejledning ikke fjerndatabehandling under jeres ansvar. Den behandles som en komponent, så risikoen ved integrationen skal vurderes og håndteres hos jer. Hav derfor en kort liste over tjenesterne ved siden af komponentlisten. Vejledningen er ikke bindende. Det samme overblik bruges, når en kunde spørger, hvor data ligger.

Når en komponent har en sårbarhed

Find ud af, om den kan udnyttes i jeres produkt. Er den aktivt udnyttet i produktet, skal I indberette den. Er den ikke det, er den ikke indberetningspligtig for jer. Den kan meldes frivilligt, og den, der vedligeholder komponenten, skal have besked. Fremgangsmåden står i 24 timer til ENISA.

Det skal I lade være med

• At lave komponentlisten i hånden · den bliver forældet, og den hører ikke til en bestemt version.
• At offentliggøre listen uden grund · der er intet krav om det.
• At lade automatiske opdateringer gå direkte i produktion uden test · det flytter risikoen uden at fjerne den.

Det skal I kræve af den eksterne

• ☐ En komponentliste, der laves automatisk ved hver udgivelse og gemmes pr. version.
• ☐ Daglig kontrol mod kendte sårbarheder.
• ☐ En aftalt regel for, hvem der vurderer et fund, og hvor hurtigt.
• ☐ En liste over købte tjenester, der indgår i produktet.
• ☐ En pipeline, hvor ændringer gennemgås, og hvor nøglerne har få rettigheder.

Kilder

• Kommissionens FAQ om Cyber Resilience Act: afsnit 4.4 om komponenter og 5.4 om tredjepartskomponenter.
• Kommissionens vejledning C(2026) 5252: ikke bindende, nr. 200 til 202 og 218.
• Forordning (EU) 2024/2847: art. 3, nr. 39, art. 13, stk. 5 og 6, og bilag I, del II, nr. 1.
• OWASP Dependency-Track: værktøj til analyse af komponentlister.

Senest gennemgået: november 2026.

Næste skridt

• Sikkerhed i produktet og i udviklingsprocessen
• Cyber Resilience Act: hvad betyder den for jeres produkt?

Læs også: Sikker softwareudvikling i et lille team · Supportperiode: hvor længe lover I at rette sårbarheder?

→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT