Sårbarheter
CISA KEV: katalogen Known Exploited Vulnerabilities
Av de flere hundre tusen publiserte CVE-ene er bare en liten brøkdel noen gang blitt utnyttet i praksis. CISAs katalog Known Exploited Vulnerabilities lister dem opp. Hvis en av dem er i programvare du leverer, går den øverst på listen.
Oppdatert
Hva er CISA KEV-katalogen?
Katalogen Known Exploited Vulnerabilities (KEV) vedlikeholdes av den amerikanske etaten Cybersecurity and Infrastructure Security Agency (CISA). CISA kaller den den autoritative kilden til sårbarheter som er blitt utnyttet i praksis, og oppfordrer sterkt alle organisasjoner til å prioritere utbedring av dem.
CISA opprettet katalogen i november 2021 sammen med Binding Operational Directive 22-01. Per katalogversjonen av 24. september 2026 inneholder den 1 723 sårbarheter. Det er en svært liten andel av alle publiserte CVE-er, og det er nettopp derfor den er nyttig: En KEV-oppføring er verken en prognose eller en alvorlighetsvurdering, den er et bevis på utnyttelse.
Slik blir en sårbarhet lagt til
CISA legger til en sårbarhet når den oppfyller tre kriterier:
- Den har en CVE-ID.
- Den blir aktivt utnyttet, med pålitelige bevis på at den er blitt eller blir utnyttet.
- Det finnes tydelig veiledning for utbedring, et klart tiltak for berørte organisasjoner, for eksempel en oppdatering fra leverandøren.
Det tredje kriteriet har betydning i praksis: En sårbarhet kan bli utnyttet en stund før den dukker opp i KEV, fordi det ikke fantes noen retting å vise til. Alle kan nominere en sårbarhet gjennom et skjema som er lenket fra KEV-siden til CISA.
Hva hver KEV-oppføring inneholder
| Felt | Hva det inneholder |
|---|---|
cveID |
CVE-identifikatoren |
vendorProject, product |
Hvem som lager den berørte programvaren, og hvilket produkt |
vulnerabilityName, shortDescription |
Et navn og en kort beskrivelse |
dateAdded, dueDate |
Når CISA la den til, og utbedringsfristen for amerikanske føderale etater |
requiredAction |
Hva du skal gjøre, vanligvis ta i bruk leverandørens oppdateringer eller avbøtende tiltak, eller slutte å bruke produktet |
knownRansomwareCampaignUse |
«Known» hvis den er brukt i en løsepengevirus-kampanje, ellers «Unknown» |
forensicTriage |
«Yes» hvis BOD 26-04 krever forensisk triage for den |
notes, cwes |
Referanser og svakhetstypene |
361 oppføringer er i dag merket som brukt i løsepengevirus-kampanjer. Hvis du må rangere innenfor KEV, kommer de først.
BOD 26-04: KEV-frister for føderale etater
For amerikanske føderale sivile etater under den utøvende makten er KEV ikke et råd. Binding Operational Directive 26-04, utstedt 10. juni 2026, fastsetter hvor raskt de må utbedre. Det opphevet BOD 22-01, som hadde gitt to uker for de fleste KEV-oppføringer og seks måneder for CVE-er tildelt før 2021, og BOD 19-02. Kriteriene for å legge en sårbarhet til i KEV ble ikke endret.
BOD 26-04 fastsetter hver frist ut fra fire spørsmål, basert på CISAs beslutningsmodell SSVC:
- Offentlig eksponert: Kan ressursen nås fra offentlige nettverk?
- KEV-status: Er sårbarheten i katalogen?
- Automatisering av utnyttelse: Kan en angriper automatisere utnyttelsen?
- Teknisk konsekvens: Gir utnyttelse delvis eller full kontroll?
Svarene gir frister fra 3 dager, med forensisk triage for å sjekke om systemet allerede var kompromittert, til retting ved neste systemoppgradering. Direktivet gjelder ikke for selskaper utenfor den føderale forvaltningen, med mindre en kontrakt sier det. Likevel er det et nyttig referansepunkt for din egen policy.
Slik bruker du KEV hvis du bygger programvare
De fleste KEV-oppføringer gjelder produkter fra store leverandører: Microsoft alene står for 388, fulgt av Cisco, Apple, Adobe og Google. Åpen kildekode er også med, og da inne i andres produkter. Log4Shell (CVE-2021-44228) er eksempelet alle husker.
Byggepipelines er ikke unntatt. De kompromitterte GitHub Actions tj-actions/changed-files
(CVE-2025-30066) og reviewdog/action-setup (CVE-2025-30154) står begge i katalogen: En kjent utnyttet
sårbarhet kan ligge i workflowen som bygger produktet ditt, ikke bare i produktet.
- Match KEV mot det du leverer, ikke mot det repositoriene dine deklarerer. Et sårbart bibliotek som er hentet inn transitivt eller lastet ned av et byggeskript, er likevel i produktet.
- Behandle et treff som en hendelse, ikke som en backlog-sak. Rett det, eller avbøt det og registrer hvorfor.
- Sjekk eksponeringsperioden. Hvilke utgivelser leverte den sårbare versjonen, og siden når? Det er det kundene spør om.
- Følg med på rapporteringsfristen. Etter EUs Cyber Resilience Act utløser en aktivt utnyttet sårbarhet i et produkt en plikt for produsenten til å sende et tidlig varsel innen 24 timer.
- Ranger alt annet med EPSS og CVSS. Prioritering av sårbarheter går gjennom metoden.
Slik får du KEV-dataene
- CISA: katalogsiden, pluss CSV, JSON og et JSON-skjema.
- GitHub:
cisagov/kev-dataspeiler datafilene og oppdateres når katalogen gjør det. - E-post: CISA tilbyr et abonnement på katalogoppdateringer.
- Verktøyene dine: Mange skannere og plattformer for sårbarhetshåndtering flagger KEV-oppføringer, blant dem Grype, Tenable, Qualys og Rapid7.
Slik hjelper CRACI
KEV forteller deg hvilke sårbarheter som utnyttes. CRACI forteller deg hvor de er. Det kjører GitHub Actions-jobbene dine og registrerer pakkene hver jobb faktisk hentet, inkludert transitive avhengigheter, cachede pakker og skjulte avhengigheter som ingen lockfile lister opp, og vurderer overvåkede SBOM-er på nytt kontinuerlig.
- Hvilke bygg som er berørt. Bygghistorikken viser hvilke tidligere bygg som inneholdt den sårbare avhengigheten, direkte eller transitiv, så du kjenner eksponeringsperioden.
- Hvem som retter den. Sikkerhetsteam triagerer funn og sender hvert av dem til teamet som eier rettingen.
- Hindre at den leveres igjen. Policy gates kan blokkere et bygg som inneholder en bestemt CVE.
- Rapporter den. For aktivt utnyttede sårbarheter under CRA sender CRACI inn varslene til myndighetene på vegne av produsenten.
CISA KEV: ofte stilte spørsmål
Hva er CISA KEV?
Katalogen Known Exploited Vulnerabilities (KEV) er CISAs liste over sårbarheter som er blitt utnyttet i praksis. CISA kaller den den autoritative kilden til utnyttede sårbarheter og oppfordrer alle organisasjoner til å prioritere utbedring av dem.
Hvor mange sårbarheter er det i KEV-katalogen?
1 723 per katalogversjonen av 24. september 2026, av de flere hundre tusen publiserte CVE-ene. 361 av dem er merket som kjent brukt i løsepengevirus-kampanjer.
Hva får en sårbarhet inn i KEV?
Tre kriterier: Den har en CVE-ID, det finnes pålitelige bevis på at den er blitt eller blir utnyttet, og det finnes tydelig veiledning for utbedring, for eksempel en oppdatering fra leverandøren.
Må private selskaper følge KEV-fristene?
Nei. Fristene binder amerikanske føderale sivile etater under den utøvende makten gjennom Binding Operational Directive 26-04. Alle andre kan bruke katalogen som et prioriteringssignal, og mange kunder og revisorer forventer det.
Hva erstattet BOD 22-01?
BOD 26-04, utstedt 10. juni 2026, opphevet BOD 22-01 og BOD 19-02. I stedet for faste to uker for KEV-oppføringer fastsetter det frister fra 3 dager til neste systemoppgradering, basert på KEV-status, offentlig eksponering, om utnyttelsen kan automatiseres, og den tekniske konsekvensen.
Hva er forskjellen på KEV og EPSS?
KEV registrerer sårbarheter som allerede er utnyttet. EPSS anslår sannsynligheten for at en publisert CVE blir utnyttet de neste 30 dagene. Bruk KEV først og EPSS til å rangere alt annet.
Finn kjent utnyttede sårbarheter i det du leverer
Book en demo og kjør en av GitHub Actions-workflowene dine på CRACI. Se hver sårbare pakke bygget hentet inn, og hvilke bygg som leverte den.
Book en demo