CISA KEV e EPSS: priorizando pela evidência de exploração

Seu scanner devolve 400 achados e você tem uma semana. O CVSS consegue ordená-los por gravidade, mas uma falha 9.8 que ninguém usa pode esperar, enquanto uma falha 7.5 que atacantes já exploram não deveria. Duas fontes gratuitas mostram quais falhas são usadas na prática. O catálogo Known Exploited Vulnerabilities (KEV) da CISA lista falhas com exploração confirmada. O Exploit Prediction Scoring System (EPSS), mantido pela FIRST, estima a chance de cada falha ser explorada nos próximos 30 dias.

Este artigo explica as duas, mostra como elas se encaixam ao lado do CVSS e depois percorre um laboratório em que você consulta as duas fontes para os mesmos CVEs e monta uma tabela de prioridade pequena. O ponto para guardar: gravidade, evidência de exploração e a sua própria exposição decidem a ordem da correção, juntas. Cada uma sozinha gera uma ordem errada.

Se o CVSS ainda é novo para você, leia antes o que é CVSS. Para a diferença entre vulnerabilidade, ameaça e exploit, veja o que é uma vulnerabilidade.

#O que o CVSS informa e o que deixa de fora

O Common Vulnerability Scoring System avalia uma falha pelo vetor dela: como o atacante chega até ela, quanto esforço exige, se o atacante precisa de privilégios ou de uma ação do usuário, e o que a falha pode causar. A pontuação base é um número de 0 a 10 calculado a partir dessas propriedades.

A pontuação base responde a uma pergunta: quão ruim seria isso se alguém usasse a falha? Ela não responde se alguém está usando. O CVSS tem métricas temporais, que podem incluir a maturidade do exploit, mas a maioria dos painéis mostra a pontuação base em primeiro lugar, e esse número não muda depois que o CVE é publicado.

Dois CVEs do laboratório abaixo mostram essa lacuna. O CVE-2021-44228 (Log4Shell) tem pontuação base 10.0 na NVD. O CVE-2023-44487 (HTTP/2 Rapid Reset) tem 7.5. Ordenar só pela pontuação coloca o Log4Shell primeiro, e isso está certo. O problema aparece com um backlog de quarenta falhas com nota 9.8 e nenhum sinal de que alguma delas tenha sido usada. A pontuação dá um ponto de partida. Ela não dá uma ordem.

#CISA KEV: exploração confirmada

O catálogo KEV é a lista da CISA de vulnerabilidades exploradas na natureza. A CISA diz que mantém a fonte oficial dessa lista e recomenda que as organizações a usem como entrada no processo de priorização. A inclusão depende de evidência confiável de que a falha está sendo usada de forma ativa. As entradas entram à medida que essa evidência aparece.

O arquivo do catálogo que baixei para este artigo (versão 2026.11.06, publicada em 2026-11-06) tem 1.769 entradas. Cada entrada traz estes campos:

• cveID, vendorProject, product e vulnerabilityName
• dateAdded, o dia em que a CISA incluiu o CVE
• dueDate, o prazo definido pela CISA
• requiredAction, normalmente uma correção do fabricante ou uma mitigação
• knownRansomwareCampaignUse, com o valor Known ou Unknown
• notes e cwes

Das 1.769 entradas, 361 estão marcadas como Known para uso em campanhas de ransomware. 285 foram incluídas em 2026 até a data de publicação.

Dois limites importam. Primeiro, o catálogo não está completo. A exploração costuma começar antes de a CISA confirmar, e algumas falhas exploradas nunca recebem entrada. Um CVE fora do KEV está não confirmado, o que é diferente de seguro. Segundo, o KEV não diz se a sua cópia de um produto é afetada. Essa resposta vem do seu inventário.

#De onde vêm os prazos

A maioria das pessoas conhece os prazos do KEV pela BOD 22-01, uma diretiva operacional vinculante que a CISA publicou em 3 de novembro de 2021. Ela mandava as agências federais dos EUA corrigirem as entradas do KEV em até seis meses para CVEs com identificador atribuído antes de 2021, e em até duas semanas para todas as outras vulnerabilidades. O campo dueDate ainda reflete esse modelo nas entradas mais antigas.

A BOD 22-01 não é mais a regra. A página da diretiva no cisa.gov diz agora que ela foi revogada e substituída pela BOD 26-04, que a CISA lista com data de 10 de junho de 2026. A BOD 26-04 define prazos de correção a partir de quatro entradas:

• Status no KEV: o CVE está no catálogo?
• Exposição do ativo: usuários não autenticados em redes públicas conseguem alcançar o ativo?
• Automação da exploração: um adversário consegue automatizar cada etapa do exploit?
• Impacto técnico: quanto controle a exploração bem-sucedida dá ao atacante?

A Tabela 1 da BOD 26-04 traz os próprios prazos. A diretiva conta dias corridos e define as entradas "& forensic triage", que precisam ser corrigidas em três dias e depois verificadas quanto a sinais de comprometimento. Leia a tabela na página da diretiva para ver os valores exatos. Não copie números deste artigo nem de posts antigos.

O próprio catálogo mostra as duas fases. No arquivo que baixei, a diferença entre dateAdded e dueDate é de 21 dias em 1.025 entradas, 14 dias em 286 entradas e cerca de seis meses (181 ou 182 dias) em 249 entradas. Quase todas as entradas de seis meses têm CVEs de 2020 ou anteriores, o que bate com a regra da BOD 22-01. Os intervalos de 21 e 14 dias são datas definidas pela CISA caso a caso, então não seguem uma regra fixa. Há 152 entradas que citam a BOD 26-04 em requiredAction ou notes.

#FIRST EPSS: probabilidade nos próximos 30 dias

A FIRST, o Fórum de Equipes de Resposta a Incidentes e Segurança, mantém o EPSS. A FIRST descreve o EPSS como um modelo de aprendizado de máquina que estima a probabilidade de um CVE publicado ser explorado na natureza nos próximos 30 dias. A FIRST publica a pontuação todos os dias para todos os CVEs. Os dados são gratuitos e não exigem cadastro.

Cada CVE recebe dois números:

• A pontuação é uma probabilidade entre 0 e 1. Uma pontuação de 0,05 significa 5% de chance de exploração em 30 dias. A FIRST diz que o modelo é calibrado para que a pontuação corresponda a essa taxa.
• O percentil é a posição no ranking. Um percentil de 0,99 significa que o CVE tem pontuação maior que 99% dos CVEs pontuados naquele dia.

A maioria das pontuações fica perto de zero, porque a maioria das vulnerabilidades nunca é explorada. Por isso o percentil costuma ser mais fácil de ler que a pontuação bruta. Uma pontuação de 0,909 parece alta sozinha, e um percentil de 0,998 mostra como ela se compara com o resto da lista naquele dia.

A FIRST diz que o modelo usa cerca de 2.850 atributos de cinco categorias (código de exploit, comentários públicos, métricas CVSS, idade e volume de referências, entre outras) e que aprende com atividade de exploração observada, fornecida por parceiros. As pontuações mudam quando surgem novos sinais. A API pode devolver um histórico de 30 dias para um CVE, o que ajuda quando você precisa explicar por que uma pontuação subiu.

O EPSS tem um limite claro. Ele prevê atividade de exploração. Não diz o quão grave é uma falha e não diz se os seus sistemas executam o código afetado. Trate uma pontuação alta como motivo para olhar o ativo, e confirme o ativo antes de presumir que ele está em risco.

#Como eles se encaixam com o CVSS

Cada fonte responde a uma pergunta diferente:

A ordem de correção vem da combinação das quatro. Esta é uma base de partida, não uma lei. Primeiro vem o confirmado e alcançável. Depois vem o confirmado mas inalcançável, e o não confirmado com EPSS alto e alcançável. O resto segue pelo CVSS e pelo valor do ativo. A BOD 26-04 combina os mesmos tipos de entrada, então as regras federais seguem a mesma lógica.

#Laboratório prático: monte uma tabela de prioridade

Você precisa de:

• Um shell Bash. A execução de referência usou Git Bash no Windows 11, com curl 8.12.1 e Python 3.12.
• Acesso à internet para www.cisa.gov, api.first.org e services.nvd.nist.gov.
• jq, opcional. O jq não estava instalado na máquina de referência, então cada comando jq abaixo tem um equivalente em Python 3.12, e as saídas mostradas vêm dos comandos Python.

Estes passos apenas leem catálogos públicos. Nenhum deles escaneia um host. Se depois você conferir a coluna de exposição em serviços ativos, faça isso só em sistemas que são seus ou para os quais você tem permissão por escrito para testar.

#Passo 1: baixe o catálogo KEV

curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json -o kev.json
ls -l kev.json

O download é silencioso. Na execução de referência, o arquivo tinha 1.832.349 bytes. Abra o início do arquivo e confira catalogVersion e dateReleased antes de confiar nas contagens.

#Passo 2: conte as entradas

jq '.vulnerabilities | length' kev.json

Na máquina de referência, isso devolveu command not found, porque o jq não estava instalado. O equivalente em Python devolveu:

python -c "import json; d=json.load(open('kev.json')); print(len(d['vulnerabilities']))"

1769

O campo count no topo do arquivo deve mostrar o mesmo número.

#Passo 3: consulte um CVE no KEV

jq '.vulnerabilities[] | select(.cveID=="CVE-2021-44228") | {cveID, dateAdded, dueDate, requiredAction}' kev.json

O equivalente em Python imprimiu isto, com requiredAction abreviado aqui:

{
  "cveID": "CVE-2021-44228",
  "dateAdded": "2021-12-10",
  "dueDate": "2021-12-24",
  "requiredAction": "For all affected software assets for which updates exist, the only acceptable remediation actions are: 1) Apply updates; OR 2) remove affected assets from agency networks. ..."
}

Faça a mesma consulta para o CVE-2023-4863 e você obtém dateAdded 2023-09-13 e dueDate 2023-10-04. As datas são o motivo para guardar o arquivo do catálogo: elas registram quando a CISA agiu, e não apenas se ela agiu.

#Passo 4: pergunte ao EPSS sobre os mesmos CVEs

curl -s 'https://api.first.org/data/v1/epss?cve=CVE-2021-44228,CVE-2023-4863' | jq '.data'

A resposta bruta da execução de referência:

{"status":"OK","status-code":200,"version":"1.0","access":"public","total":2,"offset":0,"limit":100,"data":[{"cve":"CVE-2023-4863","epss":"0.999790000","percentile":"0.999800000","date":"2026-11-07"},{"cve":"CVE-2021-44228","epss":"0.999990000","percentile":"1.000000000","date":"2026-11-07"}]}

Dois detalhes importam no código. As linhas voltam em ordem diferente da pedida, então faça a correspondência pelo cve e nunca pela posição. Os valores vêm como texto, então converta-os para número antes de ordenar ou comparar.

#Passo 5: monte a tabela com um script

Salve isto como priority.py. Ele usa apenas a biblioteca padrão do Python.

import json, sys, time, urllib.request

KEV_FILE = sys.argv[1]
CVES = sys.argv[2:]

def get(url):
    with urllib.request.urlopen(url, timeout=60) as r:
        return json.load(r)

kev = {v["cveID"]: v for v in json.load(open(KEV_FILE))["vulnerabilities"]}
epss = {row["cve"]: row for row in get(
    "https://api.first.org/data/v1/epss?cve=" + ",".join(CVES))["data"]}

print("| CVE | CVSS 3.1 base | In KEV | EPSS | Percentile |")
print("|---|---|---|---|---|")
for cve in CVES:
    nvd = get(f"https://services.nvd.nist.gov/rest/json/cves/2.0?cveId={cve}")
    metrics = nvd["vulnerabilities"][0]["cve"].get("metrics", {})
    cvss = metrics.get("cvssMetricV31", [{}])[0].get("cvssData", {}).get("baseScore", "n/a")
    e = epss.get(cve, {})
    print(f"| {cve} | {cvss} | {'yes' if cve in kev else 'no'} | "
          f"{float(e.get('epss', 0)):.5f} | {float(e.get('percentile', 0)):.5f} |")
    time.sleep(7)  # the NVD API rate-limits requests without a key

Execute para seis CVEs: dois dos exemplos do catálogo e quatro escolhidos para contrastar com eles.

python priority.py kev.json CVE-2021-44228 CVE-2023-4863 CVE-2024-3400 CVE-2023-44487 CVE-2023-38545 CVE-2024-3094

Saída da execução de referência:

| CVE | CVSS 3.1 base | In KEV | EPSS | Percentile |
|---|---|---|---|---|
| CVE-2021-44228 | 10.0 | yes | 0.99999 | 1.00000 |
| CVE-2023-4863 | 8.8 | yes | 0.99979 | 0.99980 |
| CVE-2024-3400 | 10.0 | yes | 0.99999 | 1.00000 |
| CVE-2023-44487 | 7.5 | yes | 0.99999 | 0.99998 |
| CVE-2023-38545 | 9.8 | no | 0.78689 | 0.99591 |
| CVE-2024-3094 | 10.0 | no | 0.90900 | 0.99808 |

O script não preenche a coluna de exposição, porque só você conhece o seu inventário. Veja como a execução de referência preencheu essa coluna e o que cada verificação cobriu:

• CVE-2021-44228: o find por log4j-core*.jar no perfil do usuário e no repositório não devolveu nada. Resultado: não.
• CVE-2023-4863: a busca por libwebp* em /mingw64, /usr e no perfil do usuário não devolveu nada. Resultado: não.
• CVE-2023-38545: curl --version informa 8.12.1. A faixa da NVD para o libcurl afetado vai de 7.69.0 até, sem incluir, 8.4.0. Resultado: não, para o libcurl upstream. Veja o aviso abaixo.
• CVE-2024-3094: xz --version informa 5.6.4. A NVD lista 5.6.0 e 5.6.1 como afetadas. Resultado: não.
• CVE-2024-3400 e CVE-2023-44487: não verificados nesta máquina.

A coluna de exposição é a que mais gente erra. Distribuições Linux e fabricantes costumam fazer backport de correções, então só o número da versão pode enganar. Confira o aviso do fabricante para a sua build antes de marcar uma linha como segura.

#Passo 6: leia a tabela

Coloque as linhas em ordem de correção pela regra da seção anterior. Se CVE-2021-44228, CVE-2023-4863 ou CVE-2024-3400 fossem alcançáveis na sua rede, eles seriam as primeiras correções da semana, independentemente do que diga o resto da lista.

O CVE-2023-44487 tem pontuação CVSS menor que a do CVE-2023-38545, mas ele está confirmado e o EPSS dele é 0,99999. Numa lista em que os dois são alcançáveis, ele vai primeiro. A falha 9.8 que a CISA não confirmou desce.

O CVE-2024-3094 é o caso que quebra uma regra simples. Os dados da CISA não o listam, mas o EPSS dele é 0,909 e o CVSS é 10.0. Nesta máquina a versão não é afetada, então a linha fecha. Em um host com xz 5.6.1, a mesma linha vai para o topo, porque a pontuação diz que a atividade de exploração é muito provável e a falha é crítica.

#Erros comuns

• Ordenar só pelo CVSS. A pontuação mede impacto, não uso. Coloque ao lado as colunas do KEV e do EPSS.
• Tratar o KEV como lista completa. Uma entrada ausente significa que a CISA não confirmou a exploração. Não significa que a falha é inofensiva.
• Ler o EPSS como impacto ou prova. O EPSS estima atividade de exploração. Ele não diz que a falha está na sua rede.
• Copiar prazos federais. A BOD 22-01 foi revogada. A BOD 26-04 se aplica às agências federais. Fora desse escopo, os prazos dela são um modelo, e você deve definir os seus a partir do seu risco.
• Consultar a API em massa. A FIRST criou a API do EPSS para consultas pontuais. Para o conjunto completo, baixe o CSV diário.
• Esquecer a data. As pontuações do EPSS mudam todo dia, e o KEV cresce toda semana. Escreva a data ao lado de cada tabela.
• Confiar em números de versão sem o aviso do fabricante. Backports e opções de build mudam o que é afetado.
• Pular a coluna de exposição. Uma tabela sem dados de ativos é uma opinião sobre as falhas, não uma lista de prioridade para os seus sistemas.

#Como ir além

• Leia a página de metodologia do EPSS em https://www.first.org/epss/how-it-works, que trata de calibração e limites.
• Use o CSV diário do EPSS em https://epss.empiricalsecurity.com/epss_scores-current.csv.gz e junte-o ao arquivo do KEV pelo cveID. Assim você confere centenas de CVEs de uma vez.
• Leia a BOD 26-04 e a Tabela 1 dela. A diretiva cita o programa Vulnrichment da CISA como fonte do status no KEV, da automação da exploração e do impacto técnico dos CVEs com identificador.
• Acrescente duas colunas dos seus próprios registros: se o ativo está exposto à internet e quanto ele vale para você. Essas duas colunas costumam reordenar mais a lista do que as pontuações.

#Fontes

Os dados deste artigo foram lidos em 2026-11-08 a partir das fontes listadas nos metadados do artigo. Os números do KEV e as pontuações do EPSS mudam com o tempo, então confira a data na sua própria execução.