Introdução: Gestão de Vulnerabilidades Baseada em Riscos no Âmbito da Lei de Resiliência Cibernética
As equipes modernas já sabem que corrigir todas as vulnerabilidades é impossível. O que realmente importa é corrigir as vulnerabilidades certas. É por isso que o gerenciamento de vulnerabilidades baseado em risco se tornou a abordagem preferida para equipes DevSecOps. No entanto, na União Europeia, isso deixou de ser apenas uma boa prática. A Lei de Resiliência Cibernética introduz obrigações legais concretas, especialmente quando o software inclui problemas listados no [inserir lista de vulnerabilidades aqui]. CISCatálogo de vulnerabilidades exploradas conhecidas.
Nesse novo contexto, a priorização de vulnerabilidades deixa de ser uma escolha de segurança e passa a ser um requisito de conformidade. As equipes precisam demonstrar que entendem quais vulnerabilidades estão sendo exploradas ativamente e como decidem o que corrigir primeiro. E o prazo deixa de ser algo abstrato: As obrigações de reporte à CRA relativas a vulnerabilidades ativamente exploradas e incidentes graves aplicam-se a partir de 11 de setembro de 2026., com o conjunto completo das principais obrigações entrando em vigor em dezembro de 2027. Qualquer modelo de priorização que uma organização esteja utilizando hoje precisa ser defensável sob essa exigência de relatório em questão de semanas, não de trimestres.
Gestão de vulnerabilidades baseada em risco e vulnerabilidades exploradas conhecidas
A gestão de vulnerabilidades baseada em risco concentra-se na exposição real em vez da gravidade bruta. Em vez de tratar todas as CVEs da mesma forma, as equipes priorizam com base na exploração, alcance e impacto.
É aqui que as vulnerabilidades exploradas conhecidas desempenham um papel central. Quando uma CVE aparece no CISUm catálogo de vulnerabilidades conhecidas e exploradas confirma que os atacantes já as utilizam em ambientes reais. Esse sinal tem muito mais peso do que uma pontuação teórica.
Se você deseja uma explicação mais detalhada sobre o que são KEVs e como identificá-los, pode ler nossa publicação anterior. Vulnerabilidades conhecidas e exploradas: o que corrigir primeiroNeste artigo, focamos em como os KEVs se encaixam nos modelos de conformidade e priorização da Lei de Resiliência Cibernética.
O que a Lei de Resiliência Cibernética realmente exige
A Lei de Resiliência Cibernética é um regulamento da UE que estabelece obrigações obrigatórias de cibersegurança para produtos com elementos digitais vendidos na UE. Ela exige que os fornecedores gerenciem as vulnerabilidades ao longo de todo o ciclo de vida do produto e evitem lançar software com vulnerabilidades conhecidas e exploradas. De acordo com a lei, documentação oficial da UEOs fabricantes devem:
- Identificar e lidar com vulnerabilidades ao longo do ciclo de vida do produto.
- Impeça o envio de software com vulnerabilidades conhecidas e exploradas.
- Reportar vulnerabilidades ativamente exploradas e incidentes graves dentro de 24 horas após o conhecimento da mesma, uma obrigação de reporte que se torna obrigatória em 11 de setembro de 2026.
- Manter evidências do gerenciamento de vulnerabilidades.cisíons
Em outras palavras, assim que uma vulnerabilidade aparece no CISUm Catálogo de Vulnerabilidades Conhecidas e Exploradas (K-Exploited Vulnerabilities Catalog) é um recurso valioso. Ignorá-lo cria riscos tanto de segurança quanto regulatórios, e a partir de setembro de 2026, esse risco vem acompanhado de um prazo para notificação.
O que é a Lei de Resiliência Cibernética (CRA)?
O Lei de Resiliência Cibernética É um regulamento da UE que define requisitos obrigatórios de cibersegurança para software e produtos digitais vendidos na Europa. Exige que os fornecedores gerenciem as vulnerabilidades ao longo de todo o ciclo de vida do produto e evitem lançar software com falhas. vulnerabilidades exploradas conhecidas.
Lista de verificação para gerenciamento de vulnerabilidades baseado em risco e pronto para o CRA
Por que os KEVs são essenciais para a conformidade com a CRA
O CISUm Catálogo de Vulnerabilidades Conhecidas e Exploradas lista as CVEs que os atacantes já exploram na prática. Em outras palavras, ele elimina a ambiguidade na priorização.
Em vez de perguntar "Isso poderia ser explorado?", as equipes agora precisam fazer uma pergunta muito mais direta: "Isso já está sendo explorado e, mesmo assim, vamos lançar o produto?"
De acordo com a Lei de Resiliência Cibernética, essa distinção é legalmente relevante. Consequentemente, as vulnerabilidades essenciais (KEVs) tornam-se o principal fator a ser considerado para o cumprimento dos SLAs de remediação e o bloqueio de versões. Nesse contexto, a gestão de vulnerabilidades baseada em risco alinha-se naturalmente às expectativas regulatórias.
Abordamos o tema da notificação de incidentes com mais detalhes em uma sessão conjunta com Nariman Aga-Tagiyev, arquiteto de cibersegurança da SecureHabits.nl: 24 horas para informar: como sobreviver ao prazo de notificação da Receita Federal do Canadá (CRA).O documento descreve o ciclo de vida de incidentes em três etapas que a CRA espera que as organizações acompanhem, desde uma preocupação relatada, passando por uma investigação, até um incidente confirmado que inicia o período de notificação de 24 horas.
CVSS, EPSS e KEVs servem a propósitos diferentes.
Para priorizar corretamente, as equipes precisam primeiro entender o que cada sinal realmente representa.
- CVSS demonstra impacto potencial
- EPSS estima a probabilidade de exploração
- CISCatálogo de Vulnerabilidades Exploradas Conhecidas confirma que a exploração já acontece.
Consideradas isoladamente, cada métrica pode induzir a erros. No entanto, quando as equipes as utilizam em conjunto, obtêm um contexto muito mais claro. Por essa razão, a combinação desses sinais constitui a base de uma gestão eficaz de vulnerabilidades baseada em riscos.
Gestão de vulnerabilidades baseada em risco na prática
Na prática, um modelo de priorização baseado em risco segue um fluxo claro e repetível.
- Detectar vulnerabilidades em todo o código e suas dependências.
- Verificar correspondências com o CISCatálogo de Vulnerabilidades Exploradas Conhecidas
- Avalie a probabilidade de exploração usando o EPSS.
- Verifique a disponibilidade no seu aplicativo ou pipeline
- Aplique regras de remediação com base na exposição e na função do produto.
Como resultado, as equipes deixam de tratar as listas de vulnerabilidades como pendências estáticas e passam a tratá-las como desafios concretos de segurança.cisíons.
Diferentes modelos de priorização que as equipes usam hoje
Nem todas as equipes priorizam o risco da mesma maneira. Em geralObservamos três modelos comuns em ambientes reais.
1. Modelo de Gravidade em Primeiro Lugar
As equipes resolvem problemas com base apenas no CVSS.
Este modelo é fácil de adotar. No entanto, gera ruído e não atende às expectativas da Lei de Resiliência Cibernética.
2. Modelo baseado na probabilidade
As equipes dependem do EPSS para prever o que os invasores podem explorar em seguida.
Essa abordagem melhora o foco. Mesmo assim, ainda deixa passar vulnerabilidades que os atacantes já exploram.
3. Modelo Consciente da Exploração
As equipes combinam EPSS com o CISCatálogo de vulnerabilidades exploradas conhecidas e contexto técnico.
Em contrapartida, este modelo é o que melhor se adapta à gestão de vulnerabilidades baseada em riscos e está diretamente alinhado às obrigações da CRA (Lei de Reinvestimento Comunitário).
Como a Xygeni operacionaliza a priorização de projetos prontos para o CRA
Xygeni Ajuda as equipes a transformar a regulamentação em fluxo de trabalho diário. Em vez de depender apenas de dashboards, Xygeni impõe decisOs íons são identificados exatamente onde as alterações de código ocorrem. Como resultado, a priorização torna-se automática e consistente.
Os principais recursos incluem:
- Correlação automática com o CISCatálogo de Vulnerabilidades Exploradas Conhecidas
- Pontuação de probabilidade de exploração baseada em EPSS
- Análise de alcance para confirmar a exposição real.
- Guardrails que se fundem ou liberam blocos quando KEVs afetam código acessível.
- Remediação automatizada por meio de segurança pull requests
- Registros de auditoria completos para demonstrar a conformidade com a Lei de Resiliência Cibernética.
Resumindo, as equipes não apenas identificam os riscos, como também agem de forma repetível e auditável.
Exemplo de desenvolvedor para desenvolvedor: KEV bloqueando um lançamento
Imagine que uma atualização de dependência introduza uma vulnerabilidade CVE.
- A vulnerabilidade aparece em CISCatálogo de Vulnerabilidades Exploradas Conhecidas
- Xygeni detecta isso durante o pull request
- A análise de acessibilidade confirma que o caminho do código é executado.
- Guardrails bloquear a mesclagem automaticamente
- O bot propõe uma atualização segura e executa testes.
O desenvolvedor resolve o problema no mesmo fluxo de trabalho. A versão permanece em conformidade. Nenhuma reunião é necessária.
Em outras palavras, trata-se de gerenciamento de vulnerabilidades baseado em risco, aplicado exatamente onde os desenvolvedores já trabalham.
Por que isso importa além da conformidade?
Embora a Lei de Resiliência Cibernética tenha desencadeado essa mudança, os benefícios vão além. Equipes que priorizam o uso de KEVs, EPSS e contexto:
- Reduzir a fadiga de alerta
- Reduzir o tempo de remediação
- Evite remendos de emergência
- Envie software mais seguro com confiança.
De modo geral, a conformidade torna-se uma consequência natural de se fazer a segurança da maneira correta.
Considerações finais: A CRA torna obrigatória a gestão baseada em risco.
A Lei de Resiliência Cibernética formaliza o que as equipes de segurança já aprenderam da maneira mais difícil: nem todas as vulnerabilidades têm a mesma importância.
O CISUm Catálogo de Vulnerabilidades Conhecidas e Exploradas define o que os atacantes usam atualmente. O EPSS prevê o que eles usarão em seguida. O Contexto mostra se isso afeta você.
Juntos, eles formam a gestão moderna de vulnerabilidades baseada em risco e, a partir de 11 de setembro de 2026, ela deixará de ser opcional. As equipes que já conseguem responder à pergunta "isso foi explorado e, mesmo assim, vamos lançar o produto?" cumprirão o prazo de notificação da CRA sem dificuldades. As equipes que não conseguem estão descobrindo como 24 horas são, na realidade, um prazo curto.
A Xygeni ajuda as equipes a aplicar esse modelo de forma contínua, automática e de uma maneira que os desenvolvedores realmente aceitam.
Sobre o autor
Escrito por Fátima SaidGerente de Marketing de Conteúdo especializada em Segurança de Aplicativos na Xygeni Segurança.
Fátima cria conteúdo sobre segurança de aplicativos (AppSec) acessível a desenvolvedores e baseado em pesquisas. ASPMe DevSecOps. Ela traduz conceitos técnicos complexos em insights claros e acionáveis que conectam a inovação em cibersegurança com o impacto nos negócios.
