En moden operating model for vulnerability management gør forskellen mellem “vi patcher, når vi når det” og et kontrolleret flow, hvor fund bliver vurderet, udbedret, verificeret og kommunikeret uden drama. Denne artikel giver dig en praktisk model, du kan implementere i et team på få uger, og som skalerer til flere produkter, flere leverandører og flere krav.
Du får konkrete beslutningskriterier, en SLA-tabel med exception-godkendelse, og et gennemgående blik på supply chain: afhængigheder, transitive dependencies og håndtering af upstream-forsinkelser. Undervejs får du typiske faldgruber, bedste praksis og små “mini-konklusioner”, så du kan omsætte teorien til handling.
Hvad er en operating model for sårbarheder, og hvorfor betyder den noget?
En operating model for sårbarhedshåndtering er en aftalt måde at arbejde på, der beskriver hvem der gør hvad, hvornår og hvordan fra et fund opstår til det er lukket og dokumenteret. Den betyder noget, fordi sårbarheder ikke kun er tekniske fejl; de er en løbende driftsopgave med risiko, prioritering, ejerskab og kommunikation på tværs af udvikling, drift, sikkerhed og forretning.
Uden en model ender mange organisationer med enten at overreagere (alt er “kritisk”) eller underreagere (ingen føler ejerskab). Begge dele øger risikoen og omkostningerne, især når audit, kunder eller regulatorer spørger til proces, sporbarhed og SLA.
Mini-konklusion: En tydelig operating model reducerer både sikkerhedsrisiko og friktion, fordi den gør prioritering og ansvar forudsigeligt.
Intake: Sådan samler du fund fra scanner, bug bounty og kunderapporter
Intake handler om at få alle fund ind ét sted, ensartet, med tilstrækkelig kontekst til at kunne triagere hurtigt. De tre mest almindelige kilder er automatiske scanninger (SAST/DAST/SCA), bug bounty eller eksterne forskere, samt kunderapporter og driftshændelser.
Standardiser din intake med et minimumssæt af felter
Hvis du vil undgå, at triage drukner i frem-og-tilbage, så kræv altid nogle basisfelter. Det gør det også lettere at måle lead time og følge op på SLA.
- Produkt, komponent og miljø (prod/test/on-prem/cloud)
- Beskrivelse af sårbarheden og forventet impact
- Reproduktionssteps eller proof-of-concept
- Versioner, commit, container image eller package-lock reference
- Eksponering: internet-facing, intern, partner, embedded
- Kilde: scanner, bug bounty, kunde, intern test
Deduplicering og “signal vs. støj”
Scannerfund kan være støjende, især ved falske positiver eller når samme CVE dukker op i flere images. Brug en enkel regel: dedup på (CVE + package + version + deploy-context). Supplér med “suppressions” med udløbsdato, så midlertidige undtagelser ikke bliver permanente.
Mini-konklusion: God intake er ikke flere værktøjer, men bedre normalisering og færre uklare tickets.
Triage: Severity, exploitability og exposure i praksis
Triage er kernen i prioriteringen. Mange teams stopper ved CVSS, men reelt bør du kombinere tre akser: severity (konsekvens), exploitability (hvor realistisk udnyttelse er) og exposure (hvor sårbart systemet er i sin kontekst). På den måde kan en “høj” CVSS i en isoleret build-pipeline få lavere prioritet end en “medium” i en internet-eksponeret auth-service.
En enkel triage-score, alle kan forstå
Hold modellen forklarlig, så udviklere, produkt og ledelse kan være enige. Et pragmatisk setup er:
- Severity: Kritisk/Høj/Medium/Lav baseret på impact (data, drift, integritet)
- Exploitability: Aktiv udnyttelse, kendt exploit, kræver lokal adgang, teoretisk
- Exposure: Internet-facing, partner-facing, intern, air-gapped
Dokumentér beslutningen i ticketen: “Hvorfor blev den prioritet valgt?” Det sparer tid senere, især ved audits eller kundespørgsmål.
Håndtering af “ikke-sårbare i praksis”
Et klassisk problem i SCA er CVE’er i packages, der ikke kan nås i runtime (fx devDependencies eller ubrugte code paths). Her bør triage kræve bevis: “unreachable” skal understøttes af fx call graph, build-flag eller runtime-policy. Brug tidsbegrænsede undtagelser og planlæg oprydning.
Mini-konklusion: Triage bliver robust, når du kombinerer severity med realistisk udnyttelse og faktisk eksponering.
Remediation: Ejerskab, SLA, backporting og exception-styring
Remediation handler om at omsætte prioritet til handling: hvem fixer, hvornår, og hvordan vi sikrer, at fixet når alle relevante versioner. Start med et simpelt princip: den der ejer komponenten, ejer også sårbarheden, mens security faciliterer, måler og eskalerer.
Her er en praktisk SLA-model, der kan tilpasses. Den forudsætter, at “exception” betyder en dokumenteret, tidsbegrænset afvigelse med kompenserende kontroller.
Severity → SLA → Godkendelse af exception
- Kritisk → 48 timer → CISO eller Head of Security
- Høj → 14 dage → Produktchef + Security lead
- Medium → 60 dage → Engineering manager
- Lav → 180 dage → Team lead
Sørg for, at SLA måles på “time to remediate” og ikke kun “time to acknowledge”. Ellers får du hurtige svar, men ingen fix.
Backporting uden kaos
Hvis du har flere vedligeholdte release branches, skal du definere en backport-policy: Hvilke branches får sikkerhedsfix? Hvilke er end-of-life? En praktisk fejl er at love backport til for mange gamle versioner uden kapacitet. Sæt klare regler, fx “N og N-1 får security fixes”, og kommuniker dem til kunderne.
Hvad koster det, og hvordan budgetterer man?
Omkostningen er primært tid: udvikling, test, release og koordinering. Planlæg kapacitet ved at reservere en fast procent af sprinten til sikkerhedsarbejde, og brug triage-data til at justere. Den dyreste situation er uplanlagt “brand-slukning”, hvor teams afbryder roadmap, fordi processer og ejerskab ikke var på plads.
Mini-konklusion: Remediation lykkes, når SLA, ejerskab og backporting er aftalt på forhånd, og exceptions er styrede og tidsbegrænsede.
Supply chain: Dependencies, transitive deps og upstream-forsinkelser
De fleste moderne sårbarheder kommer via afhængigheder. Det gælder både direkte dependencies og transitive dependencies, som sniger sig ind via andre biblioteker. Derfor skal operating modellen inkludere en supply chain-rutine: inventar, påvirkningsanalyse og plan B, når upstream ikke leverer hurtigt nok.
Start med at have en opdateret SBOM eller i det mindste en pålidelig dependency-liste per build. Ved triage skal du vurdere: Er sårbarheden i en runtime path? Er den i en container base image? Er den kun i build tooling?
Når upstream er forsinket, har du typisk fire muligheder, i stigende kompleksitet:
- Opgradér til en alternativ minor/patch-version, hvis fix findes i en anden gren
- Skift dependency til en kompatibel fork eller erstatning
- Lav en midlertidig patch (vendoring) og track tilbage til upstream
- Indfør kompenserende kontroller: WAF-regler, feature flags, hardening, isolation
Et vigtigt princip: Hvis du vendor en patch, så planlæg hvordan du fjerner den igen. Ellers bygger du teknisk gæld, der bliver til sikkerhedsgæld.
Mini-konklusion: Supply chain-sårbarheder kræver både teknisk overblik (SBOM) og en klar strategi for upstream-forsinkelser.
Verification: Re-test, regression og bevis for lukning
Verification er mere end at lukke en ticket. Du skal kunne bevise, at sårbarheden er væk, og at fixet ikke skaber nye problemer. Det gør din proces troværdig over for kunder, interne interessenter og auditorer.
Re-test: Hvad er “god nok” verifikation?
For scannerfund bør du køre samme scanner igen og verificere, at fundet er væk i samme deploy-context. For bug bounty bør du bruge de originale reproduktionssteps og få en “accepted fix” fra triage-teamet. For kunderapporter bør du i det mindste validere med en test, der matcher kundens miljø så tæt som muligt.
Undgå faldgruben: “Fix i main, men ikke i drift”
En almindelig fejl er at implementere fixet, men ikke få det deployet bredt: container images bliver ikke rebuilt, base images forbliver gamle, eller et gammelt artifact ligger stadig i et registry. Gør verifikation komplet ved at tjekke artefaktkæden: source → build → image → deploy.
Mini-konklusion: Et fix er først rigtigt lukket, når re-test viser, at den relevante version i det relevante miljø ikke længere er sårbar.
Communication: Release notes, advisories og intern status uden støj
Kommunikation er ofte det, der adskiller en moden proces fra en intern brandslukning. Du skal kommunikere både udadtil (kunder, partnere) og indadtil (ledelse, drift, support). Målet er at være præcis, rettidig og ikke skabe unødig alarm.
Midt i din proces er det nyttigt at have en fælles referenceramme for sårbarhedshåndtering, så teams taler samme sprog om ansvar, deadlines og dokumentation, især når kravene skærpes af nye regler og kundekrav.
Release notes vs. security advisories
Release notes er for alle brugere og bør nævne sikkerhedsrettelser på et passende niveau. Advisories er mere detaljerede og bør indeholde: berørte versioner, severity, afhjælpning, workarounds, og evt. kredit til reporter. Hold en fast skabelon, så support kan svare ensartet.
Intern status: Hvad skal rapporteres, og til hvem?
Rapportér ikke alt til alle. Brug en enkel cadance: ugentlig status til engineering og product, månedlig til ledelse. Fokusér på trends: antal åbne pr. severity, SLA-compliance, gennemsnitlig remediation-tid og top-5 produkter med størst eksponering.
Mini-konklusion: God kommunikation skaber tillid, fordi den gør risiko og fremdrift synlig uden at drukne modtagerne.
Typiske fejl og bedste praksis, der får modellen til at holde
Selv gode modeller falder, hvis de bliver for tunge eller for utydelige. Her er fejl, der går igen, og hvordan du undgår dem i praksis.
- Alt bliver kritisk: Brug triage-aksen exposure, og kræv bevis for exploitability
- Ingen ejer fundet: Bind komponent-ejerskab til teams og services i et katalog
- Exceptions bliver permanente: Sæt udløbsdato og kræv kompenserende kontroller
- Backlogs vokser: Indfør kapacitetsreservation og kvartalsvis oprydning
- Supply chain ignoreres: Vedligehold SBOM og track transitive deps aktivt
- Verifikation springes over: Gør re-test til en obligatorisk “Definition of Done”
Bedste praksis er ikke at være perfekt fra dag ét, men at være konsekvent: samme felter, samme triage-kriterier, samme SLA-rapportering. Når data er sammenlignelige, kan du forbedre processen løbende.
Mini-konklusion: De stærkeste programmer vinder på disciplin og sporbarhed, ikke på ekstra kompleksitet.
Secure SDLC og dokumentation: Fundamentet, der binder det hele sammen
En operating model for sårbarheder kan ikke stå alene; den skal være forankret i et Secure SDLC, hvor sikkerhed er indbygget i krav, design, kode, test og release. Når Secure SDLC er på plads, bliver intake og triage bedre, fordi fundene falder tidligere og er lettere at forstå, og remediation bliver billigere, fordi arkitektur og pipelines allerede understøtter sikre defaults.
Dokumentation er det praktiske fundament: beslutninger, exceptions, threat models, dependency-politikker, release-notes-skabeloner og evidens for re-test. Når du kan vise “hvad vi gjorde, hvornår, og hvorfor”, bliver både drift og compliance enklere. Det er også her, at pointerne om proces og dokumenteret sporbarhed, som Nesp.ONE fremhæver, giver mest værdi i hverdagen: ikke som papirarbejde, men som et fælles system til at styre risiko.
Mini-konklusion: Secure SDLC og god dokumentation gør sårbarhedshåndtering til en stabil driftsevne i stedet for en reaktiv øvelse.