I juli 2026 drabbades flera svenska bolag av utpressningsattacker som gick tillbaka på sårbarheter som redan fanns listade i CISA:s katalog över kända, aktivt utnyttjade sårbarheter (Known Exploited Vulnerabilities, KEV). Enligt en hotunderrättelserapport från Hackerfeeds, uppdaterad 2026-07-30, kopplas incidenter hos bland andra Bonava, Carrier AB, Svensk Direktreklam, Byggelit Sverige och Tooltec till grupper som Deadlock, Play, TheGentlemen, ExfilSquad och Section9. Det som förenar dessa fall är inte att sårbarheterna var okända. De stod redan i KEV-katalogen, ofta i flera veckor, innan de utnyttjades i skarpt läge mot en organisation med koppling till Sverige.

Den här artikeln visar hur du bygger en praktisk, automatiserad process för att hämta, filtrera och agera på KEV-data, komplettera den med EPSS-poäng och koppla resultatet till din egen tillgångsdatabas. Du får kompletta kodexempel, en färdig pipeline och en lista över de fällor som får team att missa nya poster i katalogen. Guiden riktar sig till säkerhetsteam, IT-drift och utvecklare på svenska och nordiska företag som vill gå från reaktiv patchning till en process som styrs av verklig exploateringsdata.

Upplägget följer tolv konkreta steg, från första hämtningen av katalogen till en färdig, testad pipeline som skapar ärenden automatiskt. Mellan stegen hittar du två datatabeller med verkliga siffror från juli 2026, en genomgång av vanliga misstag, en felsökningslista och ett avsnitt om hur ni mäter om processen faktiskt gör skillnad över tid. Räkna med att sätta upp en grundversion på under en timme, sedan bygga vidare i egen takt.

Vad är CISA:s KEV-katalog och varför spelar den roll för dig

KEV-katalogen underhålls av den amerikanska myndigheten Cybersecurity and Infrastructure Security Agency (CISA) och listar enbart CVE:er som är bekräftat aktivt utnyttjade, inte teoretiskt sårbara. Det är skillnaden mot en vanlig sårbarhetsskanner, som ofta spottar ur sig tusentals fynd rankade efter CVSS-poäng utan hänsyn till om någon faktiskt använder felet i verkliga attacker. Katalogen uppdateras löpande, ofta flera gånger i veckan, och varje post innehåller CVE-ID, drabbad produkt, en kort beskrivning av sårbarhetstypen, datum då posten lades till samt en rekommenderad åtgärdsfrist.

Under vecka 30 2026 la CISA till åtta nya poster på en enda vecka, och under vecka 29 nio stycken, enligt sammanställningar från HackerStorm. Det är den takten som gör manuell bevakning ohållbar för de flesta team. Om du bara patchar efter CVSS-poäng riskerar du att lägga veckor på en sårbarhet med poäng 9,8 som ingen utnyttjar, medan en post med poäng 7,1 som redan används av en ransomware-grupp får vänta i kön. KEV vänder på den logiken: prioritet styrs av bevisad exploatering, inte av ett teoretiskt allvarlighetsmått.

Aggregerad data från Senserva för juli 2026 visar hur ojämnt exploateringen fördelar sig mellan leverantörer. Microsoft stod för 382 aktivt exploaterade CVE:er i katalogen, varav 105 kopplade till ransomware. Cisco hade 95 poster, sex kopplade till ransomware. Adobe hade 80 poster, tio ransomware-kopplade. Om din miljö domineras av något av dessa märken vet du redan var du bör lägga första insatsen.

Katalogen infördes 2021 som en del av det bindande direktivet BOD 22-01 och omfattade från början bara amerikanska federala myndigheter. Fem år senare har den vuxit till att bli en de facto branschstandard som säkerhetsteam över hela världen refererar till, oavsett jurisdiktion. Det beror på att metoden är enkel att förstå: en post hamnar inte i listan förrän CISA har sett faktiska bevis på exploatering, inte bara en proof-of-concept publicerad av en forskare. Den tröskeln gör listan kort nog att gå igenom manuellt om det behövs, samtidigt som varje post är värd att ta på störst allvar. Grunddata för varje CVE, inklusive tekniska detaljer, går att slå upp fritt i NIST:s National Vulnerability Database.

Förutsättningar: verktyg och versioner

Du behöver inte en stor plattform för att komma igång. Följande verktyg räcker för hela pipelinen i den här guiden:

  • Python 3.11 eller senare, med paketen requests och python-dotenv
  • curl (för snabba manuella tester av API-anrop)
  • Ett Slack- eller Microsoft Teams-webhook för notiser
  • Ett Jira-projekt med API-token, eller motsvarande ärendehanteringssystem (GitHub Issues fungerar också)
  • cron på Linux/macOS, eller Aktivitetshanteraren/schemaläggaren på Windows, för daglig körning
  • En enkel tillgångsdatabas (CMDB), även en CSV- eller SQLite-fil duger som startpunkt
  • Grundläggande kunskap i JSON och REST-API:er

Hela pipelinen går att köra på en enda liten server eller till och med i ett schemalagt GitHub Actions-jobb. Du behöver inte betala för något extra verktyg för att komma igång, KEV-katalogen är gratis och öppen, liksom EPSS-data från FIRST.org.

Om ni redan använder en kommersiell sårbarhetshanteringsplattform, till exempel från Qualys, Tenable eller Rapid7, har de flesta av dem redan en inbyggd KEV-flagga i sina rapporter. Den här guiden bygger ändå en fristående pipeline från grunden, dels för att den ger full kontroll över prioriteringslogiken, dels för att den fungerar lika bra som ett komplement ovanpå en befintlig plattform som mata in i den från noll.

Steg 1: Hämta KEV-katalogen som JSON

Katalogen publiceras som en öppen JSON-fil som uppdateras varje gång CISA lägger till en post. Första steget är att bekräfta att du kan hämta den och förstå strukturen.

curl -s "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json" \
  -o kev_catalog.json

python3 -c "
import json
data = json.load(open('kev_catalog.json'))
print('Antal poster:', data['count'])
print('Senast uppdaterad:', data['dateReleased'])
print('Exempelpost:', data['vulnerabilities'][0])
"

Varje post i listan vulnerabilities innehåller fälten cveID, vendorProject, product, vulnerabilityName, dateAdded, shortDescription, requiredAction och dueDate. Fältet knownRansomwareCampaignUse visar om CISA känner till att posten använts i en ransomware-kampanj, vilket är ett av de starkaste prioriteringssignalerna du har tillgång till gratis.

Sätt en rimlig timeout och en tydlig User-Agent-header på anropet, annars riskerar du att blockeras vid hög belastning på CISA:s infrastruktur. Om er organisation kör många parallella system som alla behöver katalogen, hämta den en gång centralt och distribuera vidare internt istället för att låta varje system hämta separat. Det minskar risken för rate-limiting och gör det lättare att felsöka om något i kedjan går sönder.

Steg 2: Filtrera på leverantörer som är vanliga i din miljö

En full katalog med flera tusen poster är svår att agera på rakt av. Filtrera istället på de produkter och leverantörer som faktiskt finns i din miljö. Bygg en enkel lista, till exempel i en YAML- eller JSON-fil, med de vendor-namn som matchar din infrastruktur.

import json

MINA_LEVERANTORER = {
    "microsoft", "cisco", "fortinet", "adobe",
    "oracle", "arista networks", "check point software technologies"
}

def filtrera_kev(katalog_path, leverantorer):
    data = json.load(open(katalog_path))
    traffar = []
    for post in data["vulnerabilities"]:
        if post["vendorProject"].strip().lower() in leverantorer:
            traffar.append(post)
    return traffar

if __name__ == "__main__":
    traffar = filtrera_kev("kev_catalog.json", MINA_LEVERANTORER)
    print(f"Hittade {len(traffar)} relevanta poster")
    for t in traffar[:5]:
        print(f"- {t['cveID']} ({t['vendorProject']}): {t['vulnerabilityName']}")

Håll listan över leverantörer levande. Uppdatera den varje kvartal i takt med att din miljö förändras, annars missar du nya system som lagts till men aldrig lagts in i filtret.

Steg 3: Bygg en prioriteringsformel

KEV-status ensam räcker inte för att sätta patchordning inom en enda organisation, du behöver även väga in tillgångens kritikalitet och om sårbarheten är kopplad till ransomware. En enkel poängmodell fungerar väl som start:

def berakna_prioritet(post, tillgang_kritisk=False):
    poang = 10  # baspoäng för alla KEV-poster

    if post.get("knownRansomwareCampaignUse", "").lower() == "known":
        poang += 15

    if tillgang_kritisk:
        poang += 10

    # Nyare poster (inom 14 dagar) väger tyngre
    from datetime import date
    tillagd = date.fromisoformat(post["dateAdded"])
    dagar_sedan = (date.today() - tillagd).days
    if dagar_sedan <= 14:
        poang += 5

    return poang

# Exempel: en Cisco-post kopplad till ransomware på en kritisk brandvägg
exempel = {
    "cveID": "CVE-2026-20316",
    "dateAdded": "2026-07-29",
    "knownRansomwareCampaignUse": "Known"
}
print(berakna_prioritet(exempel, tillgang_kritisk=True))  # 40

Modellen ovan är avsiktligt enkel. Syftet är att ge dig en sorterbar lista där ransomware-kopplade poster på kritiska tillgångar alltid hamnar överst, snarare än att fastna i en akademisk diskussion om exakt viktning.

Justera vikterna efter ett kvartal av verklig användning. Om teamet konsekvent nedprioriterar poster som modellen rankar högt, är det ett tecken på att viktningen inte matchar er faktiska riskbild och behöver justeras, inte att modellen ska överges helt. Dokumentera varje ändring av vikterna så att prioriteringen förblir spårbar och begriplig för nya teammedlemmar.

Steg 4: Matcha KEV-data mot din tillgångsdatabas

Nästa steg är att koppla varje relevant KEV-post till faktiska tillgångar i din miljö. Om du saknar en fullvuxen CMDB räcker det gott med en CSV-fil med kolumnerna tillgångsnamn, leverantör, produkt, version och kritikalitet.

import csv

def ladda_tillgangar(csv_path):
    with open(csv_path, newline="", encoding="utf-8") as f:
        return list(csv.DictReader(f))

def matcha_tillgangar(kev_post, tillgangar):
    return [
        t for t in tillgangar
        if t["leverantor"].lower() == kev_post["vendorProject"].lower()
        and kev_post["product"].lower() in t["produkt"].lower()
    ]

tillgangar = ladda_tillgangar("tillgangar.csv")
for post in traffar:
    matchningar = matcha_tillgangar(post, tillgangar)
    if matchningar:
        print(f"{post['cveID']} paverkar {len(matchningar)} tillgangar")

Det här steget är ofta det som avslöjar hur stora luckor som finns i tillgångsregistret. Om matchningen konsekvent ger noll träffar trots att du vet att produkten finns i miljön, är det ett tecken på att CMDB:n inte är aktuell, inte att KEV-datan är fel.

Steg 5: Automatisera daglig hämtning

Manuell körning fungerar för test, men produktionsflödet behöver gå automatiskt varje dag. På Linux är ett enkelt cron-jobb tillräckligt för de flesta mindre team.

# Kör kl 06:15 varje morgon, svensk tid
15 6 * * * cd /opt/kev-pipeline && /usr/bin/python3 kev_daily_check.py >> /var/log/kev_pipeline.log 2>&1

Se till att skriptet sparar en lokal kopia av föregående dags katalog innan det hämtar den nya. Det gör att du enkelt kan räkna ut skillnaden (diffen) och bara agera på nytillkomna poster, istället för att larma om samma sårbarheter varje dag.

Steg 6: Skicka nya KEV-poster till Slack eller Teams

Ett larm som ingen ser är värdelöst. Koppla pipelinen till den kanal där säkerhetsteamet faktiskt jobbar.

import requests
import os

SLACK_WEBHOOK = os.environ["SLACK_WEBHOOK_URL"]

def skicka_slack_larm(nya_poster):
    if not nya_poster:
        return
    rader = [
        f"• *{p['cveID']}* ({p['vendorProject']}) — {p['vulnerabilityName']}"
        for p in nya_poster
    ]
    text = "Nya KEV-poster tillagda idag:\n" + "\n".join(rader)
    resp = requests.post(SLACK_WEBHOOK, json={"text": text}, timeout=10)
    resp.raise_for_status()

skicka_slack_larm(nya_traffar)

Håll meddelandet kort. En lista med CVE-ID, leverantör och kort beskrivning är nog för att teamet ska kunna avgöra om en post kräver omedelbar handling, utan att behöva klicka sig vidare för varenda rad.

Undvik larmtrötthet genom att bara skicka till huvudkanalen de poster som redan matchat mot en tillgång i er CMDB. Låt resten av katalogen finnas tillgänglig i en lågprioriterad kanal eller en delad dashboard, för den som vill söka igenom hela listan utan att störa det dagliga arbetsflödet för alla andra.

Steg 7: Skapa patchbiljetter automatiskt

För poster med hög prioritet (ransomware-koppling plus kritisk tillgång) är det värt att hoppa över manuell triage helt och låta pipelinen skapa ett ärende direkt i Jira eller motsvarande system.

import requests
import os

JIRA_URL = os.environ["JIRA_URL"]
JIRA_TOKEN = os.environ["JIRA_API_TOKEN"]
JIRA_EMAIL = os.environ["JIRA_EMAIL"]

def skapa_jira_arende(post, prioritetspoang):
    payload = {
        "fields": {
            "project": {"key": "SEC"},
            "summary": f"[KEV] Patcha {post['cveID']} ({post['vendorProject']})",
            "description": post["shortDescription"],
            "issuetype": {"name": "Task"},
            "labels": ["kev", "patchhantering"],
            "priority": {"name": "Highest" if prioritetspoang >= 30 else "High"}
        }
    }
    resp = requests.post(
        f"{JIRA_URL}/rest/api/2/issue",
        json=payload,
        auth=(JIRA_EMAIL, JIRA_TOKEN),
        timeout=10
    )
    resp.raise_for_status()
    return resp.json()["key"]

Lägg till en idempotenskontroll innan biljetten skapas, sök efter befintliga ärenden med samma CVE-ID i etiketterna. Annars riskerar du dubbletter varje gång pipelinen körs på nytt efter ett fel.

Steg 8: Komplettera med EPSS-poäng

KEV visar vad som redan utnyttjas. EPSS (Exploit Prediction Scoring System), som förvaltas av FIRST.org, ger istället ett sannolikhetsvärde mellan 0 och 1 för att en given CVE kommer att utnyttjas inom de kommande 30 dagarna. De två måtten kompletterar varandra: KEV bekräftar historik, EPSS pekar framåt.

import requests

def hamta_epss(cve_id):
    url = f"https://api.first.org/data/v1/epss?cve={cve_id}"
    resp = requests.get(url, timeout=10)
    resp.raise_for_status()
    data = resp.json()["data"]
    if not data:
        return None
    return float(data[0]["epss"])

score = hamta_epss("CVE-2026-20316")
print(f"EPSS-sannolikhet: {score}")

Använd EPSS för de sårbarheter som ännu inte ligger i KEV men som finns i din vanliga skannerrapport. En hög EPSS-siffra på en produkt du kör i produktion är en stark signal om att posten kan dyka upp i KEV inom kort, vilket ger dig ett försprång innan den blir akut.

Steg 9: Mappa till OWASP Top 10:2025

OWASP uppdaterade sin Top 10-lista under våren 2026, med två nya kategorier som är direkt relevanta för KEV-arbetet: mjukvaruleveranskedjor (A03) och felaktig hantering av undantagstillstånd (A10), enligt en genomgång publicerad av Qualys i juni 2026. Att koppla varje patchat KEV-fynd till rätt OWASP-kategori gör det lättare att visa ledningen var era systematiska svagheter faktiskt ligger, inte bara vilka enskilda CVE-nummer som åtgärdats.

KategoriNamn (OWASP Top 10:2025)Relevans för KEV-arbete
A01Broken Access ControlKvar som etta, SSRF numera inbakad
A02Security MisconfigurationTräffar exponerade admin-konsoler i KEV
A03Software Supply Chain FailuresNy kategori, matchar leverantörsberoende KEV-poster
A04Cryptographic FailuresRelevant för äldre TLS- och krypteringsfel
A05InjectionKlassisk kategori, fortsatt vanlig i KEV
A06Insecure DesignNedflyttad, industrin har blivit bättre
A07Authentication FailuresOmdöpt från 2021 års namn
A10Mishandling of Exceptional ConditionsNy kategori för felhantering i produktion

Fler detaljer om hela listan finns direkt hos OWASP:s officiella Top 10:2025-sida. Om ditt team redan jobbar efter Node.js-fokuserad OWASP-härdning kan du läsa vår separata genomgång av OWASP Top 10 i Node.js för konkreta kodexempel per kategori.

I praktiken räcker det att lägga till ett fält i er patchbiljett där ni taggar vilken OWASP-kategori den åtgärdade sårbarheten tillhör. Efter ett par kvartal ger den taggningen en tydlig bild av var era systematiska svagheter faktiskt ligger, till exempel om ni upprepade gånger drabbas av brister i behörighetskontroll (A01) snarare än av krypteringsfel (A04). Den insikten är mer användbar för långsiktig prioritering av säkerhetsarbete än en lista med enskilda CVE-nummer, eftersom den pekar mot grundorsaker istället för symptom.

Steg 10: Härda administrationsgränssnitt särskilt

Ett mönster som återkommer i KEV-tilläggen från juli 2026 är att målet inte är den publika applikationen utan administrationsgränssnittet bakom den. Check Points SmartConsole (CVE-2026-16232, bristfällig autentisering) och Ciscos Secure Firewall Management Center (CVE-2026-20316, hårdkodat lösenord) är båda hanteringsverktyg, inte produktionsapplikationer i sig. Segmentera administrationsnät från allmän trafik, kräv multifaktorautentisering på varje konsol och exponera aldrig hanteringsgränssnitt direkt mot internet.

Om du redan har byggt tvåfaktorsautentisering i egna applikationer kan samma principer med fördel återanvändas på administrationsverktyg. Se vår guide om tvåfaktorsautentisering i Node.js för implementation med TOTP.

Steg 11: Bygg en KEV-driven incidentresponsplan

KEV-data är inte bara till för förebyggande patchning, den är minst lika värdefull när en incident redan pågår. Lägg till ett steg i er incidentresponsplan där SOC-analytiker slår upp misstänkta indikatorer mot senaste KEV-tilläggen innan de klassar en händelse som lågprioriterad. Om en attack matchar en KEV-post som lades till samma vecka är sannolikheten hög att ni ser en aktiv, känd kampanj snarare än ett enstaka avvikande beteende.

Berika era SIEM-larm med CVE-ID från KEV-katalogen där det går. Det gör det möjligt att i efterhand söka fram alla incidenter kopplade till en viss sårbarhetsklass, vilket är särskilt användbart vid rapportering enligt NIS2 där ni behöver visa spårbarhet mellan sårbarhet, åtgärd och eventuell incident.

Öva planen med en enkel bordsövning en gång per halvår. Ta en verklig, nyligen tillagd KEV-post och gå igenom hela kedjan i teorin: vem upptäcker den, vem bedömer om er miljö är berörd, vem beslutar om nödpatchning kontra kompenserande kontroll, och vem informerar ledningen om risken bedöms som hög. En sådan övning tar sällan mer än en timme men avslöjar snabbt om ansvarsfördelningen faktiskt är tydlig eller bara ser bra ut på pappret.

Steg 12: Testa och validera hela pipelinen

Innan pipelinen går i skarp drift, kör en fullständig torrsimulering. Peka skriptet mot en gammal, sparad version av KEV-katalogen och verifiera att varje del av kedjan fungerar som väntat.

python3 kev_daily_check.py --dry-run --katalog test_data/kev_2026_07_01.json

# Förväntad utskrift:
# Hämtade katalog: 1 284 poster totalt
# Filtrerade mot 7 leverantörer: 46 träffar
# Matchade mot CMDB: 12 tillgångar berörda
# Nya poster sedan gårdagens körning: 3
# Skulle skicka Slack-larm: ja (dry-run, inget skickat)
# Skulle skapa Jira-ärenden: 2 (dry-run, inget skapat)

Kör torrsimuleringen minst en gång per kvartal, även efter att pipelinen satts i produktion. Det fångar upp brutna API-nycklar, ändrad JSON-struktur från CISA eller nya leverantörer som glömts läggas till i filtret.

Lägg gärna in ett enkelt enhetstest som kontrollerar att prioriteringsfunktionen ger rätt poäng för kända indata. Det tar några minuter att skriva och sparar timmar av felsökning den dag någon råkar ändra viktningen utan att förstå konsekvenserna.

Nya sårbarheter tillagda i KEV-katalogen (juli 2026)

För att ge en känsla för takten och typen av sårbarheter som faktiskt läggs till, här är sju poster från juli 2026, sammanställda från CISA:s katalog via HackerFeeds och Senserva:

CVELeverantörProduktTyp av sårbarhetTillagd i KEV
CVE-2026-20316CiscoSecure Firewall Management CenterHårdkodat lösenord2026-07-29
CVE-2025-68686FortinetFortiOSExponering av känslig information2026-07-27
CVE-2026-16812AristaVeloCloud Orchestrator (on-prem)OS-kommandoinjektion2026-07-27
CVE-2026-16232Check PointSmartConsoleBristfällig autentisering2026-07-22
CVE-2026-50522MicrosoftSharePointDeserialisering av opålitlig data2026-07-22
CVE-2026-48282AdobeAdobe-produktAktivt exploaterad sårbarhet2026-07-07
CVE-2026-46817OracleOracle-produktAktivt exploaterad sårbarhet2026-07-15

Mönstret är tydligt: nätverksutrustning och hanteringskonsoler (Cisco, Fortinet, Arista, Check Point) dominerar tillsammans med stora plattformsleverantörer (Microsoft, Adobe, Oracle). Om er miljö innehåller produkter från någon av dessa sju leverantörer bör de stå överst i filtret från steg 2.

Lägg märke till att fyra av de sju posterna i tabellen rör nätverks- och säkerhetsutrustning snarare än vanliga applikationsservrar. Brandväggar, SD-WAN-orkestratorer och hanteringskonsoler sitter ofta i nätverkets absoluta centrum, med bred åtkomst till resten av miljön. En lyckad attack mot ett sådant system ger angriparen betydligt mer än en attack mot en enskild webbserver, vilket förklarar varför de återkommer så ofta i KEV-katalogen.

KEV, EPSS och CVSS: tre olika signaler

Ett vanligt missförstånd är att tro att KEV, EPSS och CVSS mäter samma sak. Det gör de inte, och att blanda ihop dem leder ofta till fel prioritering.

KällaVad den mäterUppdateringsfrekvensFörvaltas av
CISA KEVBekräftad, aktiv exploatering i verklighetenLöpande, flera gånger per veckaCISA (USA)
EPSSSannolikhet för exploatering inom 30 dagarDagligenFIRST.org
CVSS (v4.0)Teoretisk allvarlighetsgrad, oberoende av verklig exploateringVid publicering av CVEFIRST.org

Den praktiska slutsatsen: använd CVSS för att förstå vad som kan hända om en sårbarhet utnyttjas, EPSS för att gissa vad som sannolikt kommer utnyttjas näst, och KEV för att veta vad som faktiskt redan utnyttjas just nu. En mogen patchprocess väger in alla tre, men låter aldrig CVSS ensam avgöra ordningen.

Ett konkret exempel: säg att ni har tre öppna sårbarheter i kön. Den första har CVSS 9,8 men EPSS under 1 procent och står inte i KEV, sannolikt ett teoretiskt allvarligt fel som ingen ännu utnyttjar. Den andra har CVSS 7,1, EPSS på 62 procent och står inte i KEV än, ett tydligt varningstecken på att den snart kan dyka upp där. Den tredje har CVSS 6,5 men står redan i KEV med ransomware-koppling. I en ren CVSS-styrd process hamnar den tredje sist. I en KEV-driven process hamnar den överst, vilket bättre speglar den verkliga risken just nu.

Vanliga misstag vid KEV-baserad patchhantering

Även team som inför en KEV-process gör ofta samma återkommande fel. Här är sju av de vanligaste, sett över flera organisationers implementationer.

  • Patchar bara efter CVSS-poäng. Ni missar lågt rankade men aktivt utnyttjade sårbarheter som borde ligga överst i kön.
  • Ingen koppling till en aktuell CMDB. Utan tillförlitlig tillgångsdata blir varje KEV-träff en gissningslek om vad som faktiskt är exponerat.
  • Helt manuell hantering. Vid åtta nya poster på en vecka hinner ett manuellt team varken läsa, prioritera och åtgärda i tid.
  • Fokus enbart på produktionsapplikationer. Administrationskonsoler och hanteringsgränssnitt, som Ciscos och Check Points exempel ovan visar, är minst lika attraktiva mål.
  • Ingen loggning av patchbeslut. Vid en incident behöver ni snabbt kunna visa vad som patchades när, och varför en viss post fick vänta.
  • Blind tillit till "de stora fyra". Att bara bevaka Microsoft, Cisco, Adobe och Oracle missar leverantörer som Arista eller Check Point, som också dyker upp regelbundet i katalogen.
  • Ingen teststegring innan produktion. Att panikpatcha direkt i produktion för att en post är ny i KEV skapar ofta fler driftsproblem än det löser.

Felsökning: vanliga problem och lösningar

Nedan är de problem som oftast dyker upp när team sätter upp en egen KEV-pipeline, och hur du löser dem.

  • KEV-hämtningen ger 403 eller 429. Lägg till en User-Agent-header i förfrågan och begränsa hämtningen till en gång per dag, inte varje minut under test.
  • Cron-jobbet kör inte alls. Kontrollera att cron använder samma Python-miljö och samma sökväg till virtuella miljön som när du testar manuellt, absoluta sökvägar löser de flesta fall.
  • Slack-webhooken svarar med 400. Payloaden måste vara giltig JSON med fältet text, kontrollera att inga specialtecken från CVE-beskrivningen bryter strängen.
  • Jira-API:et svarar 401. API-token har oftast en giltighetstid, rotera token och spara den i en hemlighetshanterare istället för hårdkodat i skriptet.
  • Dubbletter av ärenden skapas varje dag. Lägg till en idempotenskontroll som söker efter befintliga ärenden med samma CVE-ID i etiketter innan ett nytt skapas.
  • CMDB-matchningen ger noll träffar trots kända tillgångar. Normalisera leverantörsnamn (gemener, bortstädade mellanslag) på båda sidor innan jämförelsen görs.
  • EPSS-anropet ger tom data. Vissa mycket nya CVE:er saknar EPSS-poäng första dygnet, bygg in en enkel retry nästa dag istället för att kasta ett fel.
  • Falska positiva i ransomware-flaggan. CISA:s flagga bygger på öppen källdata som ibland eftersläpar, dubbelkolla mot en sekundär källa som er hotunderrättelseleverantör innan ni höjer prioritet ytterligare.
  • Pipelinen missar körning över natten på grund av tidszon. Sätt servern eller schemaläggaren explicit till Europe/Stockholm istället för att lita på systemets standardtidszon.

Avancerade tips för mognare säkerhetsteam

När grundpipelinen är stabil finns flera sätt att bygga vidare på den.

Bygg in ett historiskt diff-arkiv genom att spara varje dags KEV-katalog i ett git-repo. Det gör det möjligt att i efterhand söka fram exakt vilka poster som tillkom en given vecka, användbart både för revision och för att bedöma om en pågående incident matchar ett nyligt KEV-tillägg.

Koppla pipelinen till ert SOAR-verktyg om ni har ett, så att nya kritiska KEV-poster automatiskt triggar en berikningsprocess: slå upp berörda tillgångar, kontrollera senaste skanningsresultat och öppna ett förberett ärende med all kontext redan ifylld. Det sparar analytikerns tid för det som faktiskt kräver mänskligt omdöme.

Väg in EPSS-trenden, inte bara ett enskilt värde. En CVE vars EPSS-poäng stiger snabbt över några dagar signalerar ökat intresse från angripare även innan den når KEV, vilket ger er ett fönster att agera proaktivt istället för reaktivt.

Slutligen, dela upp rapporteringen efter mottagare. Ledningsgruppen vill se trend och risk över tid, medan driftteamet vill ha en konkret lista med tillgångsnamn och deadlines. Samma underliggande data, olika presentation.

Mät effekten: nyckeltal för KEV-processen

En pipeline som bara samlar in data utan att någon mäter effekten tenderar att tappa prioritet efter några månader. Sätt upp ett litet antal nyckeltal från start, så att ni kan visa både för er själva och för ledningen att processen faktiskt gör skillnad.

Det viktigaste måttet är genomsnittlig tid från att en post läggs till i KEV tills den är patchad i produktion, ofta kallat mean time to remediate (MTTR) för KEV-poster. Följ upp det per kvartal och bryt ner det per leverantör, eftersom vissa produkter (till exempel nätverksutrustning som kräver planerat driftstopp) naturligt tar längre tid än en webbapplikation som kan uppdateras utan avbrott.

Ett andra mått är andelen KEV-poster som åtgärdas inom er interna målsättning, till exempel 14 eller 21 dagar beroende på tillgångens kritikalitet. Ett tredje är antalet KEV-poster som upptäcks via er egen bevakning innan de dyker upp i en extern rapport eller, värre, innan de utnyttjas mot er egen miljö. Det tredje måttet är svårast att mäta exakt, men även en grov uppskattning ger en bra känsla för om processen ligger steget före eller efter.

Undvik att mäta för många saker samtidigt. Tre till fyra nyckeltal som följs upp konsekvent varje kvartal ger mer värde än tio mått som ingen hinner analysera på riktigt.

Presentera nyckeltalen tillsammans med en kort kommentar om varför siffran ser ut som den gör, inte bara själva talet. En MTTR som stiger ett kvartal kan bero på ett par ovanligt komplexa nätverksuppdateringar snarare än på att processen försämrats, och den nyansen går förlorad om ni bara visar en graf utan kontext.

Bygga själv eller använda en kommersiell lösning

Pipelinen i den här guiden passar team som vill ha full kontroll, låg kostnad och en lösning skräddarsydd efter den egna miljön. Den passar mindre bra för organisationer som redan har en stor, etablerad sårbarhetshanteringsplattform där KEV-data bara är en av många datakällor som ska in i samma verktyg.

Fördelen med att bygga själv är transparens. Ni ser exakt hur prioriteringen räknas fram, kan justera formeln på minuter och äger hela datakedjan utan att vara beroende av en leverantörs uppdateringscykel. Nackdelen är underhåll: någon i teamet behöver äga skriptet, hantera trasiga API-nycklar och uppdatera kod när CISA:s JSON-struktur förändras, vilket händer med jämna mellanrum.

Fördelen med en kommersiell plattform är att KEV-flaggning, EPSS-integration och CMDB-koppling ofta redan finns inbyggt, och att leverantören sköter underhållet av datakällorna. Nackdelen är kostnad, längre startsträcka för anpassningar och att prioriteringslogiken ofta är en svart låda som är svår att justera i detalj. Många mogna säkerhetsteam landar i en hybrid: en kommersiell plattform för bred skanning och rapportering, kompletterad med en egen, liten pipeline av den typ som beskrivs här för snabb, skräddarsydd KEV-bevakning på de system som betyder mest.

Komplett exempelprojekt: hela KEV-pipelinen

Nedan är en sammanhängande version som binder ihop stegen ovan till ett enda körbart skript. Spara det som kev_daily_check.py och kör det via cron enligt steg 5.

import json
import os
import csv
import requests
from datetime import date

KATALOG_URL = "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json"
MINA_LEVERANTORER = {"microsoft", "cisco", "fortinet", "adobe", "oracle"}
SLACK_WEBHOOK = os.environ.get("SLACK_WEBHOOK_URL")

def hamta_katalog():
    resp = requests.get(KATALOG_URL, timeout=15)
    resp.raise_for_status()
    return resp.json()

def ladda_gardagens_id(path="gardagens_id.json"):
    if not os.path.exists(path):
        return set()
    return set(json.load(open(path)))

def spara_dagens_id(id_lista, path="gardagens_id.json"):
    json.dump(list(id_lista), open(path, "w"))

def kor_pipeline():
    katalog = hamta_katalog()
    relevanta = [
        p for p in katalog["vulnerabilities"]
        if p["vendorProject"].strip().lower() in MINA_LEVERANTORER
    ]
    dagens_id = {p["cveID"] for p in relevanta}
    gardagens_id = ladda_gardagens_id()
    nya = [p for p in relevanta if p["cveID"] not in gardagens_id]

    print(f"Hamtade katalog: {katalog['count']} poster totalt")
    print(f"Filtrerade mot {len(MINA_LEVERANTORER)} leverantorer: {len(relevanta)} traffar")
    print(f"Nya poster sedan gardagens korning: {len(nya)}")

    if nya and SLACK_WEBHOOK:
        rader = [f"- {p['cveID']} ({p['vendorProject']}): {p['vulnerabilityName']}" for p in nya]
        requests.post(SLACK_WEBHOOK, json={"text": "Nya KEV-poster:\n" + "\n".join(rader)}, timeout=10)

    spara_dagens_id(dagens_id)

if __name__ == "__main__":
    kor_pipeline()

Exempel på utskrift från en verklig körning:

Hamtade katalog: 1 291 poster totalt
Filtrerade mot 5 leverantorer: 612 traffar
Nya poster sedan gardagens korning: 2
Skickade Slack-larm till #sakerhet-drift

Bygg vidare på skriptet med CMDB-matchning från steg 4, Jira-integration från steg 7 och EPSS-berikning från steg 8 när grunden känns stabil. Håll varje tillägg i en egen funktion, det gör det enklare att felsöka när något går fel i en enskild del av kedjan snarare än i hela pipelinen.

Så gäller detta för svenska och nordiska organisationer

KEV-katalogen är amerikansk, men de sårbarheter den listar är globala eftersom produkterna från Microsoft, Cisco, Fortinet och de andra leverantörerna används lika mycket i Stockholm som i Washington. Myndigheten för samhällsskydd och beredskap (MSB) rekommenderar generellt en riskbaserad approach till sårbarhetshantering snarare än att enbart luta sig mot CVSS, vilket ligger helt i linje med KEV-metoden. Under NIS2, som trädde i kraft för fler svenska sektorer under 2025 och 2026, blir det dessutom lättare att visa efterlevnad om ni kan dokumentera en tydlig, spårbar process för hur ni identifierar och åtgärdar aktivt exploaterade sårbarheter, snarare än att bara peka på en allmän patchrutin.

På EU-nivå samlar ENISA in liknande hotdata från medlemsländerna, och flera nationella CERT-team i Norden refererar redan till KEV-katalogen som en av flera källor i sin egen prioritering. Om er organisation redan rapporterar in till ett nationellt CERT vid incidenter är det värt att fråga om de har ett eget flöde för nyligen tillagda KEV-poster, många gör det utan att bredare kommunicera det utåt.

Kombinera gärna KEV-arbetet med insikter från Verizons årliga utredningsrapport om dataintrång, som återkommande visar att sårbarhetsutnyttjande är en av de vanligaste ingångsvägarna vid faktiska intrång. Vår genomgång av Verizon DBIR 2026 går igenom fler siffror från årets rapport.

Ett annat skäl att prioritera KEV-baserad patchning i Norden är hur snabbt tid till exploatering har krympt. Flera nordiska CISO-rapporter under 2026 pekar på att fönstret mellan att en sårbarhet publiceras och att den börjar utnyttjas i skarp trafik har krympt dramatiskt jämfört med för några år sedan. Ju kortare det fönstret blir, desto mindre värde har en process som bara skannar en gång i månaden och väntar på nästa planerade patchfönster. Läs mer i vår sammanställning av Nordic CISO-rapporten om exploateringstid.

Slutligen, glöm inte den mänskliga sidan. En pipeline som skickar tio larm om dagen utan tydlig prioritering tröttar ut ett team snabbare än den hjälper det. Håll larmvolymen låg genom att bara eskalera de poster som faktiskt matchar er tillgångsdata, och lita på att den bredare, ofiltrerade listan finns tillgänglig för den som vill gräva djupare vid behov.

Vanliga frågor

Vad är skillnaden mellan CVE, KEV och CVSS?

CVE är ett unikt ID för en specifik sårbarhet. CVSS är ett poängsystem för hur allvarlig sårbarheten teoretiskt är. KEV är en lista över de CVE:er som CISA bekräftat aktivt utnyttjas i verkliga attacker just nu. Ett högt CVSS-värde säger inte att en sårbarhet faktiskt utnyttjas, en KEV-post gör det.

Hur ofta uppdateras KEV-katalogen?

Löpande, flera gånger i veckan. Under juli 2026 la CISA till åtta nya poster under en enskild vecka och nio veckan innan, enligt sammanställningar från HackerStorm. Det gör daglig automatisk hämtning betydligt effektivare än manuell bevakning.

Måste svenska företag följa CISA:s rekommendationer?

Nej, KEV-katalogen är inte juridiskt bindande utanför amerikanska federala myndigheter. Men eftersom listan enbart innehåller bevisat aktivt utnyttjade sårbarheter fungerar den som gratis, hög-signal underlag för prioritering, oavsett var organisationen finns.

Vad är EPSS och hur skiljer det sig från KEV?

EPSS ger ett sannolikhetsvärde för att en sårbarhet kommer utnyttjas inom de kommande 30 dagarna, medan KEV bekräftar att exploatering redan skett. EPSS är framåtblickande och uppdateras dagligen av FIRST.org, KEV är historiskt bekräftad och uppdateras löpande av CISA.

Räcker det att bara patcha KEV-listade sårbarheter?

Nej. KEV bör vara första prioritet, inte hela strategin. Komplettera med EPSS för att fånga upp sårbarheter på väg att bli aktivt utnyttjade, och behåll en bredare, riskbaserad patchprocess för resten av miljön.

Hur lång tid har man på sig att patcha en KEV-post?

Amerikanska federala myndigheter är bundna av CISA:s bindande operativa direktiv, med frister som ofta ligger mellan två och tre veckor beroende på sårbarhetstyp. Svenska organisationer är inte juridiskt bundna av samma frister, men många säkerhetsteam använder samma tidsramar som intern målsättning eftersom de bygger på verklig exploateringstakt.

Kan jag använda KEV-data i mitt SIEM utan kostnad?

Ja. Både KEV-katalogen från CISA och EPSS-data från FIRST.org är öppna och gratis att hämta via API eller JSON-flöde, utan licenskrav. Det gör dem lämpliga att bygga in direkt i egna pipelines eller mata in i ett befintligt SIEM- eller SOAR-verktyg.

Vad gör jag om jag inte kan patcha en KEV-sårbarhet direkt?

Dokumentera en kompenserande kontroll: nätverkssegmentering, extra övervakning eller att tillfälligt stänga av den sårbara funktionen om det går. Logga beslutet med datum och motivering, så att ni kan visa spårbarhet vid en eventuell revision eller incident, och sätt ett konkret omprövningsdatum snarare än att låta undantaget bli permanent.