CISA KEV: o catálogo Known Exploited Vulnerabilities

O que é o catálogo CISA KEV?

O catálogo Known Exploited Vulnerabilities (KEV) é mantido pela Cybersecurity and Infrastructure Security Agency (CISA) dos EUA. A CISA apresenta-o como a fonte de referência das vulnerabilidades exploradas no terreno e incentiva vivamente todas as organizações a dar prioridade à sua remediação.

A CISA criou o catálogo em novembro de 2021, a par da Binding Operational Directive 22-01. Na versão do catálogo de 24 de setembro de 2026, contém 1.723 vulnerabilidades. É uma parte ínfima de todas as CVE publicadas, e é exatamente por isso que é útil: uma entrada KEV não é uma previsão nem uma classificação de gravidade, é um registo de exploração.

Como uma vulnerabilidade é adicionada

A CISA adiciona uma vulnerabilidade quando esta cumpre três critérios:

1. Tem um identificador CVE.
2. Está a ser ativamente explorada, com provas fiáveis de que foi ou está a ser explorada.
3. Existem orientações claras de remediação, uma ação clara para as organizações afetadas, como uma atualização do fornecedor.

O terceiro critério importa na prática: uma vulnerabilidade pode ser explorada durante algum tempo antes de aparecer no KEV, porque não havia uma correção para indicar. Qualquer pessoa pode propor uma vulnerabilidade através de um formulário disponível na página KEV da CISA.

O que contém cada entrada KEV

Campo	O que contém
cveID	O identificador CVE
vendorProject, product	Quem faz o software afetado, e qual o produto
vulnerabilityName, shortDescription	Um nome e uma descrição breve
dateAdded, dueDate	Quando a CISA a adicionou e o prazo de remediação para as agências federais dos EUA
requiredAction	O que fazer, normalmente aplicar as atualizações ou mitigações do fornecedor, ou deixar de usar o produto
knownRansomwareCampaignUse	"Known" se tiver sido usada numa campanha de ransomware, caso contrário "Unknown"
forensicTriage	"Yes" se a BOD 26-04 exigir triagem forense para essa vulnerabilidade
notes, cwes	Referências e tipos de fragilidade

Atualmente, 361 entradas estão marcadas como usadas em campanhas de ransomware. Se tiver de ordenar dentro do KEV, estas vêm primeiro.

BOD 26-04: prazos KEV para as agências federais

Para as agências federais civis do poder executivo dos EUA, o KEV não é um conselho. A Binding Operational Directive 26-04, emitida a 10 de junho de 2026, define a rapidez com que têm de remediar. Revogou a BOD 22-01, que dava duas semanas para a maioria das entradas KEV e seis meses para CVE atribuídas antes de 2021, e a BOD 19-02. Os critérios para adicionar uma vulnerabilidade ao KEV não mudaram.

A BOD 26-04 define cada prazo a partir de quatro perguntas, com base no modelo de decisão SSVC da CISA:

• Exposição pública: o ativo pode ser alcançado a partir de redes públicas?
• Estado KEV: a vulnerabilidade consta do catálogo?
• Automatização da exploração: um atacante pode automatizar a exploração?
• Impacto técnico: a exploração dá controlo parcial ou total?

As respostas dão prazos que vão de 3 dias, com triagem forense para verificar se o sistema já tinha sido comprometido, até à correção na atualização seguinte do sistema. A diretiva não se aplica a empresas fora do governo federal, a menos que um contrato o estabeleça. Ainda assim, é uma referência útil para a sua própria política.

Como usar o KEV se desenvolve software

A maioria das entradas KEV diz respeito a produtos de grandes fornecedores: só a Microsoft representa 388, seguida da Cisco, da Apple, da Adobe e da Google. O open source também aparece, e quando aparece está dentro de produtos de terceiros. O Log4Shell (CVE-2021-44228) é o exemplo de que todos se lembram.

Os pipelines de build não são exceção. As GitHub Actions comprometidas tj-actions/changed-files (CVE-2025-30066) e reviewdog/action-setup (CVE-2025-30154) constam ambas do catálogo: uma vulnerabilidade com exploração conhecida pode estar no workflow que compila o seu produto, não apenas no produto.

1. Compare o KEV com o que distribui, não com o que os seus repositórios declaram. Uma biblioteca vulnerável trazida de forma transitiva, ou descarregada por um script de build, continua a estar no produto.
2. Trate uma correspondência como um incidente, não como um item do backlog. Corrija-a, ou mitigue-a e registe porquê.
3. Verifique o seu período de exposição. Que lançamentos distribuíram a versão vulnerável, e desde quando? É isso que os clientes perguntam.
4. Tenha em conta o prazo de notificação. Ao abrigo do Cyber Resilience Act da UE, uma vulnerabilidade ativamente explorada num produto desencadeia para o fabricante uma obrigação de alerta precoce em 24 horas.
5. Ordene tudo o resto com o EPSS e o CVSS. Priorização de vulnerabilidades explica o método.

Como obter os dados KEV

• CISA: a página do catálogo, mais CSV, JSON e um esquema JSON.
• GitHub: cisagov/kev-data replica os ficheiros de dados e é atualizado quando o catálogo é atualizado.
• Email: a CISA oferece uma subscrição das atualizações do catálogo.
• As suas ferramentas: muitos scanners e plataformas de gestão de vulnerabilidades assinalam as entradas KEV, entre eles o Grype, a Tenable, a Qualys e a Rapid7.

Como o CRACI ajuda

O KEV diz-lhe que vulnerabilidades são exploradas. O CRACI diz-lhe onde estão. Executa os seus jobs de GitHub Actions e regista os pacotes que cada job realmente obteve, incluindo dependências transitivas, pacotes em cache e dependências ocultas que nenhum lockfile lista, e reavalia continuamente as SBOM monitorizadas.

• Que builds são afetados. O histórico de builds mostra que builds anteriores continham a dependência vulnerável, direta ou transitiva, para que conheça o período de exposição.
• Quem a corrige. As equipas de segurança fazem a triagem das conclusões e enviam cada uma para a equipa responsável pela correção.
• Impedir que volte a ser distribuída. Os policy gates podem bloquear um build que contenha uma CVE específica.
• Reportá-la. Para vulnerabilidades ativamente exploradas ao abrigo do CRA, o CRACI submete as notificações às autoridades em nome do fabricante.

CISA KEV: perguntas frequentes

O que é o CISA KEV?

O catálogo Known Exploited Vulnerabilities (KEV) é a lista da CISA de vulnerabilidades exploradas no terreno. A CISA apresenta-o como a fonte de referência das vulnerabilidades exploradas e incentiva todas as organizações a dar prioridade à sua remediação.

Quantas vulnerabilidades constam do catálogo KEV?

1.723 na versão do catálogo de 24 de setembro de 2026, entre as centenas de milhares de CVE publicadas. 361 delas estão marcadas como tendo sido usadas em campanhas de ransomware.

O que faz uma vulnerabilidade ser adicionada ao KEV?

Três critérios: tem um identificador CVE, existem provas fiáveis de que foi ou está a ser explorada e existem orientações claras de remediação, como uma atualização do fornecedor.

As empresas privadas têm de cumprir os prazos do KEV?

Não. Os prazos vinculam as agências federais civis do poder executivo dos EUA ao abrigo da Binding Operational Directive 26-04. Todos os outros podem usar o catálogo como sinal de priorização, e muitos clientes e auditores contam com isso.

O que substituiu a BOD 22-01?

A BOD 26-04, emitida a 10 de junho de 2026, revogou a BOD 22-01 e a BOD 19-02. Em vez de duas semanas fixas para as entradas KEV, define prazos que vão de 3 dias até à atualização seguinte do sistema, com base no estado KEV, na exposição pública, na possibilidade de automatizar a exploração e no impacto técnico.

Qual é a diferença entre KEV e EPSS?

O KEV regista vulnerabilidades já exploradas. O EPSS estima a probabilidade de qualquer CVE publicada ser explorada nos próximos 30 dias. Use primeiro o KEV e, depois, o EPSS para ordenar tudo o resto.