Innledning: Risikobasert sårbarhetshåndtering i henhold til cyberrobusthetsloven
Moderne team vet allerede at det er umulig å fikse alle sårbarheter. Det som virkelig betyr noe er å fikse de riktige. Derfor har risikobasert sårbarhetshåndtering blitt den foretrukne tilnærmingen for DevSecOps-team. I EU er dette imidlertid ikke lenger bare beste praksis. Cyber Resilience Act innfører konkrete juridiske forpliktelser, spesielt når programvare inkluderer problemer som er oppført i CISEn katalog over kjente utnyttede sårbarheter.
I denne nye konteksten går prioritering av sårbarheter fra å være et sikkerhetsvalg til å bli et krav om samsvar. Teamene må bevise at de forstår hvilke sårbarheter som aktivt utnyttes og hvordan de bestemmer hva som skal fikses først. Og klokken er ikke lenger abstrakt: Rapporteringsplikter fra kredittvurderingsbyråer for aktivt utnyttede sårbarheter og alvorlige hendelser gjelder fra 11. september 2026., med hele settet med hovedforpliktelser som følger i desember 2027. Uansett hvilken prioriteringsmodell en organisasjon bruker i dag, må den kunne forsvares under dette rapporteringskravet i løpet av uker, ikke kvartaler.
Risikobasert sårbarhetshåndtering og kjente utnyttede sårbarheter
Risikobasert sårbarhetshåndtering fokuserer på reell eksponering i stedet for rå alvorlighetsgrad. I stedet for å behandle alle CVE-er likt, prioriterer teamene basert på utnyttelse, tilgjengelighet og innvirkning.
Det er her kjente, utnyttede sårbarheter spiller en sentral rolle. Når en CVE dukker opp i CISEn katalog over kjente utnyttede sårbarheter bekrefter at angripere allerede bruker den i reelle miljøer. Dette signalet har mye større vekt enn en teoretisk poengsum.
Hvis du ønsker en dypere forklaring på hva KEV-er er og hvordan du identifiserer dem, kan du lese vårt tidligere innlegg Kjente utnyttede sårbarheter: Hva du bør fikse førstI denne artikkelen fokuserer vi på hvordan KEV-er passer inn i samsvars- og prioriteringsmodeller under Cyber Resilience Act.
Hva loven om cyberrobusthet egentlig krever
Cyber Resilience Act er en EU-forordning som setter obligatoriske cybersikkerhetsforpliktelser for produkter med digitale elementer som selges i EU. Den krever at leverandører håndterer sårbarheter gjennom hele produktets livssyklus og unngår å gi ut programvare med kjente utnyttede sårbarheter. I følge offisiell EU-dokumentasjon, må produsentene:
- Identifisere og håndtere sårbarheter gjennom hele produktets livssyklus
- Forhindre forsendelse av programvare med kjente utnyttede sårbarheter
- Rapporter aktivt utnyttede sårbarheter og alvorlige hendelser innen 24 timer etter at de ble oppmerksomme på dette, en rapporteringsplikt som trer i kraft 11. september 2026.
- Oppbevar bevis for håndtering av sårbarhetercisioner
Med andre ord, når en sårbarhet dukker opp i CISEn katalog over kjente utnyttede sårbarheter, som ignoreres, skaper både sikkerhets- og regulatorisk risiko, og fra september 2026 kommer denne risikoen med en tilknyttet rapporteringsklokke.
Hva er loven om cyberrobusthet (CRA)?
Ocuco Lov om cyberresiliens er en EU-forordning som definerer obligatoriske krav til cybersikkerhet for programvare og digitale produkter som selges i Europa. Den krever at leverandører håndterer sårbarheter gjennom hele produktets livssyklus og unngår å utgi programvare med kjente utnyttede sårbarheter.
Sjekkliste for risikobasert sårbarhetshåndtering for CRA-klar
Hvorfor KEV-er er sentrale for samsvar med CRA-regler
Ocuco CISEn katalog over kjente utnyttede sårbarheter viser CVE-er som angripere allerede utnytter. Med andre ord fjerner den tvetydighet fra prioritering.
I stedet for å spørre «Kan dette utnyttes?», må teamene nå stille et mye mer direkte spørsmål: «Blir dette allerede utnyttet, og sender vi det uansett?»
I henhold til Cyber Resilience Act har dette skillet juridisk betydning. Som et resultat blir KEV-er den sterkeste utløseren for SLA-er for utbedring og blokkering av utgivelser. I denne sammenhengen samsvarer risikobasert sårbarhetshåndtering naturlig med regulatoriske forventninger.
Vi dekket hendelsesrapporteringssiden av dette mer grundig i en fellessesjon med Nariman Aga-Tagiyev, cybersikkerhetsarkitekt hos SecureHabits.nl: 24 timer til rapportering: Overlevelse av CRAs varslingsklokkeDen går gjennom den tretrinns hendelsessyklusen som CRA forventer at organisasjoner skal spore, fra en rapportert bekymring, til en etterforskning, til en bekreftet hendelse som starter 24-timers rapporteringsvinduet.
CVSS, EPSS og KEV-er tjener forskjellige formål
For å prioritere riktig, må teamene først forstå hva hvert signal faktisk representerer.
- CVSS viser potensiell innvirkning
- EPSS estimerer sannsynligheten for utnyttelse
- CISEn katalog over kjente utnyttede sårbarheter bekrefter at utnyttelse allerede skjer
Sett alene kan hver måleenhet være misvisende. Men når team bruker dem sammen, får de en mye klarere kontekst. Derfor danner kombinasjonen av disse signalene grunnlaget for effektiv risikobasert sårbarhetshåndtering.
Risikobasert sårbarhetshåndtering i praksis
I praksis følger en risikodrevet prioriteringsmodell en tydelig og repeterbar flyt.
- Oppdag sårbarheter på tvers av kode og avhengigheter
- Sjekk treff mot CISEn katalog over kjente utnyttede sårbarheter
- Evaluer sannsynligheten for utnyttelse ved hjelp av EPSS
- Bekreft tilgjengeligheten i applikasjonen din, eller pipeline
- Bruk utbedringsregler basert på eksponering og produktrolle
Som et resultat slutter team å behandle sårbarhetslister som statiske etterslep og begynner å behandle dem som konkrete sikkerhetsdefinisjoner.cisioner.
Ulike prioriteringsmodeller team bruker i dag
Ikke alle team prioriterer risiko på samme måte. Generelt, ser vi tre vanlige modeller i virkelige miljøer.
1. Alvorlighetsgrad først-modellen
Teamene løser problemer basert kun på CVSS.
Denne modellen er enkel å ta i bruk. Den skaper imidlertid støy og oppfyller ikke forventningene i henhold til Cyber Resilience Act.
2. Sannsynlighetsdrevet modell
Team er avhengige av EPSS for å forutsi hva angripere kan utnytte neste gang.
Denne tilnærmingen forbedrer fokus. Likevel overser den fortsatt sårbarheter som angripere allerede utnytter.
3. Utnyttelsesbevisst modell
Lag kombinerer EPSS med CISEn katalog over kjente utnyttede sårbarheter og teknisk kontekst.
I motsetning til dette støtter denne modellen best risikobasert sårbarhetsstyring og er direkte knyttet til kredittvurderingsmyndighetenes forpliktelser.
Hvordan Xygeni operasjonaliserer CRA Ready Prioritering
Xygeni hjelper team med å gjøre reguleringer om til daglig arbeidsflyt. I stedet for å bare stole på dashboards, Xygeni håndhever decisnøyaktig hvor kodeendringer skjer. Som et resultat blir prioritering automatisk og konsekvent.
Nøkkelfunksjoner inkluderer:
- Automatisk korrelasjon med CISEn katalog over kjente utnyttede sårbarheter
- EPSS-basert sannsynlighetsscoring for utnyttelse
- Rekkeviddeanalyse for å bekrefte reell eksponering
- Guardrails som blokkerer sammenslåinger eller utgivelser når KEV-er påvirker tilgjengelig kode
- Automatisert utbedring gjennom sikker pull requests
- Fullstendige revisjonslogger for å demonstrere samsvar med Cyber Resilience Act
Kort sagt, team ser ikke bare risiko. De handler ut fra den på en repeterbar og reviderbar måte.
Eksempel fra utvikler til utvikler: KEV-blokkering av en utgivelse
Tenk deg at en avhengighetsoppdatering introduserer en CVE.
- Sårbarheten vises i CISEn katalog over kjente utnyttede sårbarheter
- Xygeni oppdager det i løpet av pull request
- Reachability-analyse bekrefter at kodebanen kjøres
- Guardrails blokker sammenslåingen automatisk
- Boten foreslår en sikker oppgradering og kjører tester
Utvikleren løser problemet i samme arbeidsflyt. Versjonen forblir kompatibel. Ingen møter er nødvendig.
Med andre ord, dette er risikobasert sårbarhetshåndtering som anvendes akkurat der utviklere allerede jobber.
Hvorfor dette er viktig utover samsvar
Selv om Cyber Resilience Act utløste dette skiftet, går fordelene lenger. Team som prioriterer bruk av KEV-er, EPSS og kontekst:
- Reduser årvåkenhetstretthet
- Forkort utbedringstiden
- Unngå nødplaster
- Send tryggere programvare med trygghet
I det store og hele blir samsvar et naturlig resultat av å gjøre sikkerhet på riktig måte.
Avsluttende tanker: CRA gjør risikobasert styring obligatorisk
Cyber Resilience Act formaliserer det sikkerhetsteam allerede har lært på den harde måten. Ikke alle sårbarheter er like viktige.
Ocuco CISEn katalog over kjente utnyttede sårbarheter definerer hva angripere bruker i dag. EPSS forutsier hva de vil bruke neste gang. Kontekst viser om det påvirker deg.
Sammen danner de moderne risikobasert sårbarhetshåndtering, og fra 11. september 2026 slutter det å være valgfritt. Team som allerede kan svare på «er dette utnyttet, og sender vi det uansett?», vil møte CRAs rapporteringsklokke uten å måtte stresse. Team som ikke kan det, finner ut hvor kort tid 24 timer faktisk er.
Xygeni hjelper team med å bruke denne modellen kontinuerlig, automatisk og på en måte som utviklere faktisk aksepterer.
om forfatteren
Written by Fatima Said, innholdsmarkedsføringssjef spesialisert i applikasjonssikkerhet hos Xygeni-sikkerhet.
Fátima lager utviklervennlig, forskningsbasert innhold på AppSec, ASPM, og DevSecOps. Hun oversetter komplekse tekniske konsepter til klare, handlingsrettede innsikter som kobler nettsikkerhetsinnovasjon med forretningsmessig effekt.
