Open source og tredjepartskomponenter: hvad testen siger om dem

Et moderne softwareprodukt består for en stor del af kode, som andre har skrevet: open source-biblioteker, rammeværk, færdige moduler og tjenester, produktet kalder. Når kunderne spørger til de komponenter, vil de måske vide to ting: ved I, hvad produktet indeholder, og opdager I det, når en komponent får en kendt sårbarhed? En pentest kan svare på en lille del af det. Den afprøver komponenterne, som de bruges i det kørende produkt på testdagen. Den giver hverken en fuldstændig liste over dem eller en løbende overvågning.

Det korte svar til kunden er derfor sjældent selve pentestrapporten. Det er rapporten sammen med en beskrivelse af, hvordan I holder styr på komponenterne mellem to test.

Kundens tre spørgsmål

Spørgsmålene i sikkerhedsspørgeskemaer om tredjepartskode ligner hinanden:

Overblik · har I en liste over de komponenter, produktet bygger på, og deres versioner?
Overvågning · hvordan opdager I, at en komponent har fået en kendt sårbarhed?
Reaktion · hvor hurtigt opdaterer I, og hvordan får kunderne besked, hvis de er berørt?

Ingen af de tre besvares direkte af en pentest. Men testen kan vise, om processen bag svarene virker i praksis, fordi den kan finde komponenter, der er forældede eller har kendte svagheder, som processen burde have fanget. → Sikker udvikling i skemaet

Hvad en pentest kan sige om komponenterne

Testeren arbejder med det kørende produkt. Testen kan derfor vise, om en kendt sårbarhed i en komponent kan nås og udnyttes gennem produktet, som det er sat op og bruges. Det er en værdifuld oplysning, fordi den skelner mellem en sårbarhed, der står på en liste, og en, der har betydning i jeres produkt.

Testen har også grænser. Komponenter, der ikke viser sig udefra, bliver måske ikke opdaget. En sårbarhed, der først bliver offentlig dagen efter testen, står naturligvis ikke i rapporten. Og testen gennemgår ikke komponenternes kode; den ser på, hvordan de opfører sig i jeres produkt. → Kodegennemgang eller penetrationstest?

Kendte sårbarheder i offentligt tilgængelig software får som regel et CVE-nummer. Når et fund i rapporten henviser til et sådant nummer, kan kunden selv slå sårbarheden op. Det gør fundet lettere at forklare, men det kræver også, at I har en plan for rettelsen klar, når rapporten udleveres.

Komponentlisten er det andet halve svar

Det, kunderne spørger efter, når de vil have overblik, er en softwarekomponentliste, på engelsk ofte kaldet SBOM. Den amerikanske myndighed CISA beskriver den som en indlejret fortegnelse, en ingrediensliste over de komponenter, software består af. Listen gør det muligt at svare hurtigt, når en ny sårbarhed bliver kendt: er komponenten i produktet, og i hvilken version?

For produkter, som EU’s Cyber Resilience Act omfatter, kræver forordningens bilag I, del II, bl.a. at fabrikanten identificerer og dokumenterer komponenter ved at udarbejde en softwarekomponentliste i et almindeligt anvendt og maskinlæsbart format. Om jeres produkt er omfattet, skal vurderes for sig, og teksten her er ikke juridisk rådgivning. → Cyber Resilience Act

Listen er kun nyttig, hvis den bliver holdt ajour. En liste fra sidste år giver samme falske tryghed som en gammel rapport, og kunderne vil spørge til datoen. Pentesten og komponentlisten supplerer hinanden. Listen viser, hvad der er i produktet. Testen viser, om noget af det kan bruges mod produktet, som det kører.

Mellem to test

Tiden mellem to pentest er den periode, hvor kunderne er mest afhængige af jeres egen proces. Nye sårbarheder bliver offentliggjort løbende, og et bibliotek, der var i orden på testdagen, kan have en kendt svaghed en måned senere. → Sårbarheder i afhængigheder mellem to test

Når en sårbarhed i en udbredt komponent kommer i nyhederne, kan spørgsmålet fra kunderne komme samme dag: er I ramt? Et svar, der bygger på en opdateret komponentliste, kan gives hurtigt og præcist. Et svar, der bygger på den seneste pentest, siger kun, hvordan det så ud på testdagen. → Kunden spørger efter en kendt sårbarhed

Den generelle side af tredjepartskode, set fra en virksomhed, der køber og bruger systemer, er beskrevet på penetrationtest.dk.

Et tænkt eksempel

Et softwarehus har et produkt til lønadministration. En kunde i finanssektoren sender et spørgeskema med et afsnit om tredjepartskode og spørger, om softwarehuset kan udlevere en komponentliste, hvordan nye sårbarheder opdages, og om den seneste pentest fandt forældede komponenter.

Svaret samler tre dokumenter. Komponentlisten viser biblioteker og versioner på en given dato. En kort beskrivelse forklarer, hvordan listen sammenholdes med nye sårbarheder, og hvem der beslutter, hvornår der opdateres. Pentestrapporten viser, at testeren fandt én forældet komponent, som kunne nås gennem produktet, og at den er opdateret og efterprøvet. Kunden får et billede af både øjebliksbilledet og processen, og det er det, spørgsmålene i virkeligheden handler om.

Det, I aftaler med testeren

Testeren kan bruge tiden bedre, når det ikke skal gættes, hvad produktet er bygget af:

Komponentlisten · hvis I har den, så giv testeren den. Den peger på de steder, hvor en kendt sårbarhed kan have betydning.
Eksterne tjenester · notér de tjenester, produktet kalder, og om de er med i testen eller ej.
Kendte undtagelser · fortæl testeren om komponenter, I ved er forældede, og hvorfor de stadig er der.
Rapportens form · aftal, at fund i komponenter angiver komponent, version og eventuelt CVE-nummer, så de kan forklares over for kunderne.

Det skal I lade være med

At sende pentestrapporten som svar på spørgsmålet om komponentliste · de to dokumenter svarer på forskellige spørgsmål.
At skjule kendte forældede komponenter for testeren · det bruger testtid på noget, I allerede ved.
At svare på en ny sårbarhed med datoen for den seneste test · kunden spørger til i dag.
At love, at alle komponenter altid er opdaterede · et løfte i skemaet skal kunne dokumenteres.
At regne en test uden fund i komponenter for et bevis på, at alle er i orden · testen ser kun det, der kan nås.

Hvad kan og ikke kan konkluderes

En pentest uden fund i tredjepartskomponenter viser, at testeren ikke fandt kendte sårbarheder, der kunne nås gennem produktet, med den version og opsætning, der var i brug på testdagen. Den siger ikke, hvilke komponenter produktet indeholder, og den siger intet om sårbarheder, der er blevet kendt siden. Det skal besvares med komponentlisten og jeres proces for opdateringer.

Tjekliste til komponenterne

☐ Har I en opdateret liste over produktets komponenter og versioner?
☐ Har testeren fået listen eller en beskrivelse af de vigtigste komponenter?
☐ Angiver rapporten komponent og version ved fund i tredjepartskode?
☐ Er der en proces for at opdage nye sårbarheder mellem to test?
☐ Har I et standardsvar til kunderne, når en kendt sårbarhed kommer i nyhederne?

Kilder

CISA: Software Bill of Materials (SBOM): definition af en softwarekomponentliste som en fortegnelse over de komponenter, software består af.
Cyber Resilience Act, forordning (EU) 2024/2847: bilag I, del II, punkt 1, om softwarekomponentliste i et maskinlæsbart format.
CVE: offentlige numre for kendte sårbarheder.

Senest gennemgået: oktober 2026.