TL; DR
De fleste sårbarhetslister forteller deg hva som kan gå galt. CISEn KEV-katalog forteller deg hva som går galt akkurat nå. Kjente utnyttede sårbarheter (KEV-er) er CVE-er som er bekreftet aktivt utnyttet i naturen. CISA vedlikeholder den offisielle katalogen og pålegger føderale etater tidsfrister for utbedring gjennom bindende driftsdirektiv 22-01. De fleste private organisasjoner bruker den samme listen for å kutte gjennom varslingsstøy og identifisere hva som faktisk må fikses først.
CVSS, EPSS og KEV svarer på tre forskjellige spørsmål. CVSS måler teoretisk alvorlighetsgrad – hvor ille kan dette være? EPSS forutsier sannsynlighet for utnyttelse innen 30 dager – hvor sannsynlig er det at dette blir målrettet? KEV bekrefter aktiv utnyttelse – blir dette angrepet akkurat nå? En sårbarhet med en moderat CVSS-score, en høy EPSS-score og en KEV-tagg er mer presserende enn en kritisk CVSS-score uten bevis for utnyttelse. De tre signalene fungerer sammen, ikke om hverandre.
En KEV i din avhengighet er ikke en teoretisk risiko – den har en tidsfrist. KEV-er involverer ofte tredjepartskomponenter, rammeverk, containere og CI/CD avhengigheter som teamene antar er trygge. CVE-2023-4966 (CitrixBleed) ble bekreftet utnyttet innen få dager etter avsløringen. CVE-2024-1086 ble plukket opp av ransomware-grupper kort tid etter at den ble lagt inn i KEV-katalogen. standard Fiksingsvinduet for internett-vendte KEV-er er 1–3 dager, ikke den typiske oppdateringssyklusen.
Dette innlegget dekker: hva KEV-er er og hvordan de skiller seg fra CVE-er, CVSS og EPSS; hvordan man bygger en prioriteringsarbeidsflyt rundt CISEn katalog; og hvordan Xygeni automatiserer KEV-korrelasjon, håndheving av autovern og utbedring på tvers av CI/CD pipelines — inkludert en fungerende YAML-rekkverkspolicy.
Hva er kjente utnyttede sårbarheter (KEV-er)?
Hver sårbarhetsskanner produserer funn rangert etter CVSS-alvorlighetsgrad. Problemet er at CVSS måler teoretisk innvirkning, ikke aktiv utnyttelse. CISEn katalog over kjente utnyttede sårbarheter (KEV) løser et annet, mer presserende problem: den viser CVE-ene som angripere utnytter akkurat nå, med tidsfrister for oppdateringer. For ethvert team som prøver å bestemme seg for hva som skal fikses først, er dette det mest handlingsrettede signalet som er tilgjengelig.
Kjente utnyttede sårbarheter (KEV-er) er CVE-listede sårbarheter bekreftet utnyttet i naturenDet amerikanske byrået for cybersikkerhet og infrastruktursikkerhet (CISA) opprettholder den offisielle KEV-katalog og pålegger tidsfrister for utbedringer gjennom Bindende driftsdirektiv 22-01. Mange private organisasjoner bruker nå denne listen til å prioritere oppdateringer.
Selv CVSS poengsummål potensiell effekt, KEV-er representerer aktiv utnyttelse. Med andre ord gjør de «kanskje utnyttbar» til «å bli utnyttet», noe som krever raskere tjenestenivåavtaler og automatiserte guardrails.
KEV-er vs. CVE-er vs. EPSS
Sikkerhetsteam blander ofte disse relaterte begrepene sammen. Å forstå forskjellen er avgjørende for nøyaktig risikovurdering
| akronym | Kilde | Formål |
|---|---|---|
| CVE | NVD | Unik identifikator for en avslørt sårbarhet. |
| CVSS | NVD / FØRSTE | Måler teoretisk alvorlighetsgrad (påvirkning + utnyttbarhet). |
| EPSS | FIRST.org | Forutsier sannsynligheten for utnyttelse innen 30 dager. |
| KEV | CISA | Bekrefter utnyttelse i den virkelige verden og setter tidsfrister for oppdateringer. |
Sammen danner disse systemene et risikohierarki: CVSS viser hvor ille det kan være, EPSS viser hvor sannsynlig det er, og kjente utnyttede sårbarheter viser hva som faktisk skjer.
Videre lesning: CVSS-poengsum: Hvordan CVSS-poengsum fungerer og EPSS vs. CVSS: Hva er forskjellen?
Hvorfor KEV-er er viktige for utviklere og CISOs
For det første fremhever KEV-er live angriperens oppførselFor det andre involverer de ofte tredjepartskomponenter, rammeverk, containere eller CI/CD avhengigheter, som teamene antar er trygge. Følgelig, En forsinket løsning kan åpne for sideveis bevegelse i bygge- og leveringsinfrastrukturen din.
Nylige eksempler:
- CVE-2024-1086 (Linux nf_tables): lagt til i KEV-katalogen; utnyttet av ransomware-grupper i midten av 2024.
- CVE-2023-4966 (CitrixBleed): bekreftet utnyttelse innen få dager etter avsløringen; tvungne nødoppdateringssykluser over hele verden.
Ta bort: KEV-er er ikke potensielle trusler, de er aktiv Derfor bør alle kjente utnyttede sårbarheter behandles som «fiks nå», med mindre tilgjengelighetsanalysen viser noe annet.
Slik sporer og prioriterer du kjente utnyttede sårbarheter
Til å begynne med, sjekk den offisielle CISEn katalog over kjente utnyttede sårbarheter og merk eventuelle treff i sikkerhetsskanneren din. Bruk deretter denne informasjonen til å bestemme hvilke rettelser som må skje først. I tillegg, kombiner Kjente utnyttede sårbarheter med EPSS-poengsummer å kutte støy og fokusere på svakhetene som virkelig påvirker den kjørende koden din.
Steg-for-steg arbeidsflyt:
- Synkroniser data: Hent de siste oppdateringene fra CISEn liste hver dag og kombiner dem med dine andre sårbarhetsfeeder.
- Taggresultater: Merk hvert funn som «Kjent utnyttet» når ID-en samsvarer med CISEn liste.
- Sjekk tilgjengelighet: Se om den sårbare koden faktisk kjører inne i appen eller bygget ditt pipeline.
- Vurder utnyttbarhet: Bruk EPSS for å finne ut hvilke andre problemer som snart kan bli målrettet.
- Søknadsfrister:
- Internett-relaterte sårbarheter: rettes innen 1–3 dager.
- Interne: fiks innen en uke.
- Koden er ikke i bruk: følg med og bekreft ofte.
- Automatiser svar: Systemet blokkerer usikre sammenslåinger, åpner sikre pull requests, og registrerer unntak for å sørge for at lagene ikke går glipp av noe.
Fra bevissthet til handling: Automatisering av feilrettinger med Xygeni
I praksis skaleres ikke det å håndtere alt dette manuelt. Derfor, Xygeni kobler kjente utnyttede sårbarheter direkte til din CI/CD arbeidsflyter, som gjør varsler om til reelle, veiledede handlinger.
- Smart korrelasjon: Matcher oppdaget CVE-er mot CISEn liste og uthevinger av problemer som kan fikses nå inni pull requests.
- Tilgjengelighet + Utnyttbarhet: Bekrefter om den sårbare kodebanen kjører og lenker EPSS data for precise-prioritering.
- Guardrails: Stopper risikable sammenslåinger eller distribusjoner når en utnyttet feil påvirker sensitive filer eller tjenester.
- Automatisk utbedring: Åpner sikre PR-er, sjekker for mulige endringer som ikke fungerer og kjører tester før sammenslåing.
- Revisjonslogger: Fører tydelig oversikt over hva som ble rettet og når, og støtter dermed interne sikkerhetsmål.
Kort sagt viser trusselinformasjon hva som blir angrepet, mens Xygeni sørger for at det blir fikset raskt, trygt og automatisk.
Eksempel på rekkverkspolicy (YAML)
guardrail:
id: "kev-protection"
description: "Block merges if known exploited vulnerability detected"
conditions:
- match: vulnerability.kev == true
- match: reachability == "reachable"
actions:
- block: merge
- notify: ["slack:#security-alerts", "jira:SEC-OPS"]
- create_pr: true
sla:
critical: 72h
high: 7d
Denne regelen håndhever ingen sammenslåing for aktive kjente utnyttede sårbarheter, varsler relevante kanaler og oppretter automatisk en feilrettings-PR, alt innenfor din CI/CD guardrails.
Mini-sak: Forebygging av KEV-distribusjon
- Uke 1: Et nytt åpen kildekode-bibliotek passerer SAST men inkluderer CVE-2023-4966.
- Uke 2: Xygenis KEV-korrelasjon oppdager det i den siste CISEn oppdatering.
- Uke 3: Guardrails stopp sammenslåingen; Auto-Remediation foreslår en oppdatert versjon.
Utfall: Teamet unngikk å sende en kjent utnyttet sårbarhet til produksjon og restaurering pipeline flyt innenfor samme sprint.
Xygeni korrelerer dine åpne CVE-er mot CISEn KEV-katalog flagger automatisk kjente utnyttede sårbarheter inni pull requests, håndhever guardrails som blokkerer usikre sammenslåinger, og åpner utbedrings-PR-er med innebygd validering av avbrytende endringer.
