Softwarekomponentliste (SBOM), afhængigheder og tredjepartskomponenter

Det meste af koden i et moderne softwareprodukt er skrevet af andre. Cyber Resilience Act gør fabrikanten ansvarlig for hele produktet, også de biblioteker og tjenester, der er bygget ind, og kræver en softwarekomponentliste i et maskinlæsbart format. Lovens minimum er de øverste afhængigheder, men overvågningen af sårbarheder kræver som regel mere. Artiklerne her viser, hvad listen skal rumme, hvem der skal have den, og hvordan pligten over for komponenterne kan bevises i hele supportperioden.

Listen og dens modtagere

• Softwarekomponentlisten (SBOM) efter CRA: det, gennemgangen kontrollerer Pligterne og prøven af hver.
• Øverste niveau er lovens minimum: afstanden til det, sårbarhedsovervågningen kræver Dybde og format.
• Skal kunderne have komponentlisten? Myndighed, kunder og offentlighed Hvad loven kræver udleveret til hvem.
• Den tyske retningslinje TR-03183-2 som målestok for komponentlisten, indtil der findes standarder En målestok uden formodning.
• En komponentliste for hver version: den tyske regel, og hvad forordningen kræver gemt, når der frigives hver uge Hyppige releases og ti års opbevaring.

Overvågning og vurdering

• Overvågning af komponenter for hver understøttet version: beviset for en løbende pligt Hvor matchningen svigter.
• “Ikke berørt”: den dokumenterede vurdering, når en sårbarhed i en afhængighed ikke rettes En vurdering, der holder som bevis.
• Sårbarhed i en andens komponent: meld opstrøms og del rettelsen Pligten over for vedligeholderen.

Valg og afvikling af komponenter

• Valg af open source- og tredjepartskomponenter: det, gennemgangen beder om at se Omhu, der kan dokumenteres.
• Komponentens support slutter, eller projektet står uden vedligeholder Supportperioderne lagt side om side.

Sådan kommer I i gang

Lad byggekæden danne komponentlisten automatisk for hver release i et af de udbredte formater, fx CycloneDX eller SPDX, og gem den sammen med versionen. Sammenhold derefter listen med en kilde til kendte sårbarheder, og notér, hvem der vurderer et match, og hvor vurderingen gemmes. Til sidst sammenlignes komponenternes forventede vedligeholdelse med den supportperiode, I lover kunderne. Hvor en komponent slutter før jeres produkt, skal der være en plan. Når kunder beder om listen, er det ofte led i deres egen kontrol af leverandører, som er beskrevet på sitet om leverandøraudit.

Hvad det kræver, og hvad det koster at lade være

Det kræver en byggekæde, der kan danne listen, og nogen, der har ansvaret for at reagere på match. En liste, der kun laves én gang til dokumentationen, forældes ved næste release, og så kan I ikke svare hurtigt, den dag en alvorlig fejl i en populær afhængighed rammer nyhederne.

Det skal I lade være med

• At stoppe ved de øverste afhængigheder, fordi loven tillader det · overvågningen bliver blind.
• At lukke et match uden skriftlig vurdering · “ikke berørt” skal kunne begrundes.
• At vælge komponenter uden at se på vedligeholdelsen · jeres supportperiode afhænger af den.

Det skal auditten kunne vise

• ☐ En maskinlæsbar komponentliste for hver frigivet version.
• ☐ Overvågning af komponenterne i alle understøttede versioner.
• ☐ Dokumenterede vurderinger af match, der ikke er rettet.
• ☐ Kriterier for valg af nye komponenter og en plan for dem uden vedligeholder.

Senest gennemgået: november 2026.

Næste skridt

• Softwarekomponentlisten (SBOM) efter CRA
• Overvågning af komponenter for hver understøttet version

Læs også: Sårbarheder og opdateringer · Open source

→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT