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 gestão de vulnerabilidades baseada em risco tornou-se a abordagem preferida para equipes DevSecOps. No entanto, na União Europeia, isso já não é apenas uma boa prática. Lei de Resiliência Cibernética introduz obrigações legais concretas, especialmente quando o software inclui problemas listados no 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.
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 é onde vulnerabilidades exploradas conhecidas desempenham um papel central. Quando uma CVE aparece no CISCatálogo de Vulnerabilidades Exploradas ConhecidasIsso confirma que os atacantes já o 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 sob o [texto ilegível]. Lei de Resiliência Cibernética.
O que a Lei de Resiliência Cibernética realmente exige
O método da Lei de Resiliência Cibernética Estabelece obrigações obrigatórias de cibersegurança para Produtos com elementos digitais vendidos na UE. De acordo com a documentação oficial da UE:
- https://www.european-cyber-resilience-act.com/
- https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
Os fabricantes devem:
- Identificar e lidar com vulnerabilidades ao longo do ciclo de vida do produto.
- Evite o envio de software com vulnerabilidades exploradas conhecidas
- Aplique medidas corretivas em tempo hábil assim que a exploração for conhecida.
- Manter evidências do gerenciamento de vulnerabilidades.cisíons
Em outras palavras, assim que uma vulnerabilidade aparece no CISCatálogo de Vulnerabilidades Exploradas ConhecidasIgnorá-lo cria tanto de segurança quanto de risco regulatório.
O que é a Lei de Resiliência Cibernética (CRA)?
O método da 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 priorização de vulnerabilidades em conformidade com a CRA
| Exigência | O que a CRA espera | Melhores práticas para equipes |
|---|---|---|
| Aproveite a conscientização | Impeça o envio de software com vulnerabilidades conhecidas e exploradas. | Comparar automaticamente as descobertas com o CISCatálogo de Vulnerabilidades Exploradas Conhecidas |
| priorização baseada em risco | Concentre-se nas vulnerabilidades que criam riscos reais de segurança. | Combine KEVs, EPSS, acessibilidade e exposição de ativos. |
| Remediação oportuna | Aplique as correções sem demora injustificada assim que a vulnerabilidade for descoberta. | Defina SLAs de correção imediata para KEVs acessíveis e aplique-os em CI/CD |
| Monitoramento contínuo | Gerenciar vulnerabilidades ao longo de todo o ciclo de vida do produto. | Execute verificações contínuas no código, nas dependências e pipelines |
| Controles de liberação | Evite lançar produtos com falhas de segurança ainda exploradas. | Fusões ou implantações de blocos quando KEVs afetam código acessível. |
| Decisrastreabilidade iônica | Prove como a vulnerabilidade decisíons foram produzidos | Mantenha registros de auditoria para detecção, priorização e ações corretivas. |
| Integração de desenvolvedores | As medidas de segurança não devem interromper os fluxos de trabalho de desenvolvimento. | priorização de superfície diretamente em pull requests e CI pipelines |
| Responsabilidade do ciclo de vida | Manter a segurança após o lançamento. | Acompanhe as alterações de KEVs e EPSS para as versões enviadas. |
Por que os KEVs são essenciais para a conformidade com a CRA
O método da CISCatálogo de Vulnerabilidades Exploradas Conhecidas A lista inclui as CVEs que os atacantes já exploram na prática. Em outras palavras, 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 continuar enviando?”
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.
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
A Xygeni ajuda as equipes a transformar a regulamentação em fluxo de trabalho diário.
Ao invés de confiando apenas em dashboards, Xygeni impõe decisíons exatamente onde ocorrem as alterações de código. 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 comprovar Lei de Resiliência Cibernética O compliance
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 o Lei de Resiliência Cibernética Ao desencadear essa mudança, os benefícios vão muito 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.
O método da 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 método da CISCatálogo de Vulnerabilidades Exploradas Conhecidas Define o que os atacantes usam hoje. O EPSS prevê o que eles usarão em seguida. O contexto mostra se isso afeta você.
Juntos, eles formam o moderno gestão de vulnerabilidades baseada em risco.
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.
