123% fler rapporterade CVE:er per dag 2026 än förra året.

Sårbarheter

CISA KEV: katalogen Known Exploited Vulnerabilities

Av hundratusentals publicerade CVE:er har en liten bråkdel någonsin utnyttjats i det vilda. CISA:s katalog Known Exploited Vulnerabilities listar dem. Om en av dem finns i programvara du levererar hamnar den högst upp på listan.

Uppdaterad

Vad är CISA:s KEV-katalog?

Katalogen Known Exploited Vulnerabilities (KEV) förvaltas av amerikanska Cybersecurity and Infrastructure Security Agency (CISA). CISA kallar den den auktoritativa källan till sårbarheter som har utnyttjats i det vilda, och uppmanar starkt alla organisationer att prioritera att åtgärda dem.

CISA inrättade katalogen i november 2021 i samband med Binding Operational Directive 22-01. Enligt katalogversionen från den 24 september 2026 innehåller den 1 723 sårbarheter. Det är en mycket liten andel av alla publicerade CVE:er, och just därför är den användbar: en KEV-post är inte en prognos eller en allvarlighetsbedömning, utan en registrering av utnyttjande.

Så läggs en sårbarhet till

CISA lägger till en sårbarhet när den uppfyller tre kriterier:

  1. Den har ett CVE-id.
  2. Den utnyttjas aktivt, med tillförlitliga bevis på att den har utnyttjats eller utnyttjas.
  3. Det finns tydlig vägledning för åtgärd, en tydlig åtgärd för berörda organisationer, till exempel en uppdatering från leverantören.

Det tredje kriteriet spelar roll i praktiken: en sårbarhet kan utnyttjas ett tag innan den dyker upp i KEV, eftersom det inte fanns någon åtgärd att hänvisa till. Vem som helst kan nominera en sårbarhet via ett formulär som länkas från CISA:s KEV-sida.

Vad varje KEV-post innehåller

Fält Vad det innehåller
cveID CVE-identifieraren
vendorProject, product Vem som gör den berörda programvaran, och vilken produkt
vulnerabilityName, shortDescription Ett namn och en kort beskrivning
dateAdded, dueDate När CISA lade till den, och sista datum för åtgärd för amerikanska federala myndigheter
requiredAction Vad som ska göras, oftast att tillämpa leverantörens uppdateringar eller begränsande åtgärder, eller att sluta använda produkten
knownRansomwareCampaignUse ”Known” om den har använts i en ransomware-kampanj, annars ”Unknown”
forensicTriage ”Yes” om BOD 26-04 kräver forensisk triagering för den
notes, cwes Referenser och typerna av svaghet

361 poster är för närvarande markerade som använda i ransomware-kampanjer. Om du måste rangordna inom KEV kommer de först.

BOD 26-04: KEV-tidsfrister för federala myndigheter

För amerikanska federala civila myndigheter är KEV inget råd. Binding Operational Directive 26-04, utfärdat den 10 juni 2026, anger hur snabbt de måste åtgärda sårbarheter. Det upphävde BOD 22-01, som hade gett två veckor för de flesta KEV-poster och sex månader för CVE:er som tilldelats före 2021, samt BOD 19-02. Kriterierna för att lägga till en sårbarhet i KEV ändrades inte.

BOD 26-04 fastställer varje tidsfrist utifrån fyra frågor, baserade på CISA:s beslutsmodell SSVC:

  • Offentligt exponerad: kan tillgången nås från publika nätverk?
  • KEV-status: finns sårbarheten i katalogen?
  • Automatisering av utnyttjande: kan en angripare automatisera utnyttjandet?
  • Teknisk påverkan: ger utnyttjandet partiell eller total kontroll?

Svaren ger tidsfrister från 3 dagar, med forensisk triagering för att kontrollera om systemet redan har komprometterats, till åtgärd vid nästa systemuppgradering. Direktivet gäller inte företag utanför den federala statsförvaltningen, om inte ett avtal säger det. Det är ändå ett användbart riktmärke för din egen policy.

Så använder du KEV om du bygger programvara

De flesta KEV-poster gäller produkter från stora leverantörer: enbart Microsoft står för 388, följt av Cisco, Apple, Adobe och Google. Öppen källkod förekommer också, och när den gör det finns den inuti andras produkter. Log4Shell (CVE-2021-44228) är exemplet alla minns.

Byggpipelines är inga undantag. De komprometterade GitHub Actions tj-actions/changed-files (CVE-2025-30066) och reviewdog/action-setup (CVE-2025-30154) finns båda i katalogen: en känt utnyttjad sårbarhet kan finnas i arbetsflödet som bygger din produkt, inte bara i produkten.

  1. Matcha KEV mot det du levererar, inte mot det dina repon deklarerar. Ett sårbart bibliotek som dragits in transitivt, eller laddats ner av ett byggskript, finns ändå i produkten.
  2. Behandla en träff som en incident, inte som en post i backloggen. Åtgärda den, eller begränsa den och registrera varför.
  3. Kontrollera din exponeringsperiod. Vilka releaser levererade den sårbara versionen, och sedan när? Det är vad kunderna frågar efter.
  4. Håll koll på rapporteringsklockan. Enligt EU:s Cyber Resilience Act utlöser en aktivt utnyttjad sårbarhet i en produkt en skyldighet för tillverkaren att lämna en tidig varning inom 24 timmar.
  5. Rangordna allt annat med EPSS och CVSS. Prioritering av sårbarheter går igenom metoden.

Så får du KEV-data

  • CISA: katalogsidan, plus CSV, JSON och ett JSON-schema.
  • GitHub: cisagov/kev-data speglar datafilerna och uppdateras när katalogen gör det.
  • E-post: CISA erbjuder en prenumeration på katalogens uppdateringar.
  • Dina verktyg: många skannrar och plattformar för sårbarhetshantering flaggar KEV-poster, bland dem Grype, Tenable, Qualys och Rapid7.

Så hjälper CRACI

KEV visar vilka sårbarheter som utnyttjas. CRACI visar var de finns. Det kör dina GitHub Actions-jobb och registrerar paketen som varje jobb faktiskt hämtade, inklusive transitiva beroenden, cachade paket och dolda beroenden som ingen lockfile listar, och omvärderar bevakade SBOM:er löpande.

  • Vilka byggen som berörs. Bygghistoriken visar vilka tidigare byggen som innehöll det sårbara beroendet, direkt eller transitivt, så att du känner till exponeringsperioden.
  • Vem som åtgärdar den. Säkerhetsteamen triagerar fynden och skickar vart och ett till teamet som äger åtgärden.
  • Hindra att den levereras igen. Policyspärrar kan blockera ett bygge som innehåller en specifik CVE.
  • Rapportera den. För aktivt utnyttjade sårbarheter enligt CRA lämnar CRACI in anmälningarna till myndigheterna för tillverkarens räkning.

CISA KEV: vanliga frågor

Vad är CISA KEV?

Katalogen Known Exploited Vulnerabilities (KEV) är CISA:s lista över sårbarheter som har utnyttjats i det vilda. CISA kallar den den auktoritativa källan till utnyttjade sårbarheter och uppmanar alla organisationer att prioritera att åtgärda dem.

Hur många sårbarheter finns i KEV-katalogen?

1 723 enligt katalogversionen från den 24 september 2026, av hundratusentals publicerade CVE:er. 361 av dem är markerade som kända för att ha använts i ransomware-kampanjer.

Vad gör att en sårbarhet läggs till i KEV?

Tre kriterier: den har ett CVE-id, det finns tillförlitliga bevis på att den har utnyttjats eller utnyttjas, och det finns tydlig vägledning för åtgärd, till exempel en uppdatering från leverantören.

Måste privata företag följa tidsfristerna i KEV?

Nej. Tidsfristerna binder amerikanska federala civila myndigheter enligt Binding Operational Directive 26-04. Alla andra kan använda katalogen som en signal för prioritering, och många kunder och revisorer förväntar sig det.

Vad ersatte BOD 22-01?

BOD 26-04, utfärdat den 10 juni 2026, upphävde BOD 22-01 och BOD 19-02. I stället för fasta två veckor för KEV-poster sätter det tidsfrister från 3 dagar till nästa systemuppgradering, baserat på KEV-status, offentlig exponering, om utnyttjandet kan automatiseras och den tekniska påverkan.

Vad är skillnaden mellan KEV och EPSS?

KEV registrerar sårbarheter som redan utnyttjas. EPSS uppskattar sannolikheten att en publicerad CVE utnyttjas de kommande 30 dagarna. Använd KEV först och EPSS för att rangordna allt annat.

Hitta känt utnyttjade sårbarheter i det du levererar

Boka en demo och kör ett av dina GitHub Actions-arbetsflöden på CRACI. Se varje sårbart paket som bygget drog in och vilka byggen som levererade det.

Boka en demo