Dependency risk og open source governance er gået fra “nice-to-have” til noget, kunder, myndigheder og interne risikofunktioner forventer, at du kan styre og dokumentere. Under CRA er pointen ret simpel: hvis du sælger et digitalt produkt i EU, skal du kunne vise, at du arbejder systematisk med sikkerhed gennem hele produktets livscyklus, inklusive håndtering af sårbarheder.
Det her er den praktiske version: hvad du bør kunne svare på, hvilke processer der typisk mangler, og hvordan du bygger en driftsvenlig tilgang til afhængigheder og open source, uden at det ender som et Excel-ritual ingen tror på.
Hvad CRA reelt “tester” dig på (uden at du drukner i jura)
Du kan tænke CRA som en kombination af tre forventninger:
- Security by design: du har tænkt sikkerhed ind i planlægning, udvikling, release og vedligehold.
- Vulnerability handling: du kan opdage, prioritere, fixe og kommunikere sårbarheder effektivt i supportperioden.
- Dokumenterbarhed: du kan bevise, at du gør det. Ikke “vi plejer at…”, men sporbare beslutninger og artefakter.
Og ja, det bliver mere konkret i takt med at kravene begynder at gælde: CRA trådte i kraft 10. december 2024, rapporteringsforpligtelser gælder fra 11. september 2026, og de brede hovedkrav gælder fra 11. december 2027.
Mini-konklusion: CRA handler mindre om at “have et værktøj” og mere om at kunne dokumentere en stabil proces, der virker under pres.
Dependency risk: det du faktisk skal styre (ikke bare tælle)
Afhængighedsrisiko er ikke kun “CVE’er i et dashboard”. Det er et miks af:
- Sårbarheder: kendte issues, men også svag crypto, default creds, unsafe parsing, osv.
- Supply chain: kompromitterede pakker, typosquatting, ondsindede maintainer-skift, maliciøse updates.
- Vedligeholdelse: projekter der dør, dependencies der bliver “stale”, og opgraderinger der pludselig knækker alt.
- Licensrisiko: uforenelige vilkår, copyleft-krav, uklare NOTICE-forpligtelser.
- Driftsrisiko: performance, memory leaks, uventede netværkskald, afhængigheder der trækker mere med sig end du tror.
Hvis du vil lyde moden (og faktisk være det), skal du kunne svare på:
- Hvilke afhængigheder er kritiske for produktets sikkerhed og funktion?
- Hvilke ligger i runtime vs kun build-time?
- Hvilke er internet-eksponerede gennem din arkitektur?
- Hvad gør I, når en kritisk sårbarhed rammer “fredag 15:47”?
- Hvordan sikrer I, at opdateringer ikke bliver et sjældent, traumatisk event?
Mini-konklusion: God dependency risk handler om kontekst, eksponering og forretningsimpact, ikke om at jage et lavt antal findings.
Open source governance: din “trafiklov” for komponenter
Open source governance er reglerne for, hvordan teams må introducere, opdatere og håndtere open source. Governance virker kun, hvis den er:
- Tydelig (alle kan forstå den)
- Let at følge (automation > møder)
- Konsekvent (samme beslutningslogik hver gang)
- Sporbar (hvem godkendte hvad, og hvorfor)
Et pragmatisk minimum (som ikke kræver 40 sider)
- Regler for nye dependencies
- Hvornår må et team tage en dependency ind uden review?
- Hvornår kræver det security/legal review (fx høj risiko, uklar licens, lav vedligeholdelse)?
- Patching- og opdateringspolitik
- Definér SLA’er: fx “kritisk i eksponeret runtime” = fix/mitigation inden X dage.
- Definér hvad der tæller som “mitigation” (patch, config, feature flag, WAF, isolation).
- Licenspolitik
- Tilladt / betinget tilladt / forbudt.
- En enkel undtagelsesproces med owner + udløbsdato.
- Versioning discipline
- Pinning/lockfiles, reproducible builds, og en fast kadence for dependency updates.
- Undtagelser der ikke bliver permanente
- Hver undtagelse skal have: begrundelse, risk owner, kompensation, deadline/expiry.
Mini-konklusion: Governance er ikke et dokument. Det er en beslutningsmotor, der gør det let at gøre det rigtige og besværligt at gøre det farlige.
Tooling: vælg det, der passer til drift, ikke til demoen
Du kan købe dig fattig i “platforme”, der lover ro i sjælen. I praksis er de vigtigste kriterier ret kedelige:
- Understøtter jeres sprog og build-systemer (ellers får du blind spots)
- Finder både direkte og transitive dependencies
- Kan køre i CI/CD og knytte resultater til et konkret release
- Har policy-as-code (så regler kan versionstyres og reviewes som normal kode)
- Kan give historik/audit trail (så du kan dokumentere forbedringer og undtagelser)
- Kan outputte noget, kunder og risikofolk kan forstå uden tolk
Det vigtigste designvalg er ikke “hvilket brand”. Det er: Hvordan får vi signaler, vi faktisk handler på?
Hvis værktøjet skaber 900 findings og ingen handling, har du købt støj.
Mini-konklusion: Tooling er kun nyttigt, hvis det reducerer beslutningstid og gør handling automatisk, ikke hvis det bare producerer rapporter.
Drift: en proces, der kan tåle virkeligheden
Her er en driftsvenlig end-to-end arbejdsgang, der typisk matcher det, CRA i praksis presser dig hen imod: håndtering af risiko gennem livscyklus, med dokumentation og klare roller.
1) Indfør fast cadence for dependency updates
- Ugentlig eller to-ugentlig “dependency window” (små, hyppige ændringer slår sjældne mega-opgraderinger).
- Skab rutine i at opdatere uden drama.
2) Scan og evaluér på hver build/release
- Gør det til en del af pipeline, ikke en manuel øvelse.
- Stop builds på få, klare “hard fails” (fx kritisk + eksponeret + kendt exploit).
3) Triage efter risiko, ikke efter CVSS alene
Sortér efter:
- Eksponering (internet/privileged entry points)
- Runtime vs build-time
- Exploitability (kendt exploit, aktiv udnyttelse, let at udnytte)
- Asset-kritikalitet (hvad kan kompromitteres?)
4) Skab “one truth” for beslutninger
- Når du accepterer risiko eller laver undtagelser: log det.
- Brug samme skabelon hver gang: hvad, hvorfor, kompensation, owner, udløb.
5) Fix, release, og kommuniker status ensartet
- Ejer er teamet der kan releasen.
- Security/platform faciliterer, definerer standarder og følger op.
Mini-konklusion: Det du skal “kunne”, er ikke perfektion. Det er forudsigelighed: at du kan reagere hurtigt og ens hver gang.
Typiske faldgruber (og hvordan du undgår dem)
Faldgrube 1: “Vi scanner, så vi er sikre”
Scanning uden triage, ejerskab og deadlines er bare en dyr måde at finde ud af, at verden er uperfekt.
Gør i stedet: Definér få gates + en triage-model, og mål på remediation tid.
Faldgrube 2: Undtagelser bliver en losseplads
Hvis undtagelser ikke udløber, bliver de til permanent risiko og teknisk gæld.
Gør i stedet: Kræv udløbsdato og risk owner. Ingen owner = ingen undtagelse.
Faldgrube 3: Licenser bliver “det må legal kigge på senere”
Senere bliver til aldrig, og så har du juridisk gæld du ikke kan afvikle.
Gør i stedet: En simpel licenspolitik + automatiske checks + undtagelsesflow.
Faldgrube 4: Opdateringer bliver sjældne og smertefulde
Når du ikke opdaterer løbende, bliver hver opdatering et mini-projekt, og så udsætter folk det.
Gør i stedet: Små, hyppige opdateringer som en normal del af udviklingsarbejdet.
Mini-konklusion: De værste problemer skyldes næsten altid manglende ejerskab og manglende rutiner, ikke “forkert tool”.
Et realistisk “første sprint” mod CRA-klar drift
Hvis du vil skabe værdi hurtigt (og ikke ende i compliance-teater), så gør det her:
- Definér en patch-SLA for kritiske sårbarheder (baseret på eksponering og impact).
- Indfør faste dependency updates i en cadence, teams kan leve med.
- Implementér policy-as-code for nye dependencies + en enkel undtagelsesproces.
- Byg sporbarhed: beslutningslog for undtagelser + historik for remediation.
- Sæt en simpel KPI: “median tid til remediation” for kritiske issues.
Det er ikke glamourøst. Det virker. Og det er præcis den slags drift, CRA implicit belønner: konsistens, dokumentation og livscyklus-tænkning.
