O Cyber Resilience Act (CRA), Regulamento (UE) 2024/2847, não é apenas uma exigência documental. Ele conecta requisitos de segurança do produto, tratamento de vulnerabilidades, suporte, atualização e comunicação de incidentes ao acesso ao mercado europeu.
Nota de escopo: este texto resume implicações técnicas gerais para empresas de software e não substitui uma avaliação jurídica sobre o enquadramento, as exceções ou as obrigações contratuais de um produto específico.
O que muda na prática
A lógica central do CRA é tratar cibersegurança como propriedade do produto durante seu ciclo de vida. A Comissão Europeia resume que dispositivos e software precisam ser projetados, atualizados e mantidos de forma segura. Isso desloca a conversa de uma verificação pontual antes do lançamento para um processo contínuo de engenharia e resposta.
Para uma empresa de software, quatro frentes tendem a se encontrar:
- desenvolvimento seguro: requisitos e controles incorporados ao processo de engenharia;
- visibilidade de componentes: capacidade de identificar componentes e dependências incluídos no produto;
- tratamento de vulnerabilidades: receber, avaliar, corrigir e comunicar falhas durante o período de suporte;
- evidência de conformidade: registros que demonstrem decisões, testes, correções e controle de mudanças.
Os marcos que exigem atenção agora
| Data | Marco |
|---|---|
| 11 jun 2026 | Passaram a valer as disposições sobre notificação de organismos de avaliação da conformidade. |
| 11 set 2026 | Entram em aplicação as obrigações de reporte de vulnerabilidades ativamente exploradas e incidentes severos. |
| 11 dez 2027 | O regulamento passa a ser aplicado integralmente. |
Segundo a Comissão Europeia, o reporte previsto para setembro de 2026 inclui um alerta inicial em até 24 horas após a ciência e uma notificação completa em até 72 horas. O fluxo usa a Single Reporting Platform e não deve ser tratado como uma tarefa que começa somente quando um incidente ocorre.
Cumprir uma janela curta de reporte depende de inventário, ownership, classificação e processo de resposta já operacionais.
Onde o impacto aparece na engenharia
Inventário não é uma planilha produzida no fim
A organização precisa conseguir relacionar produto, versão, componentes, dependências e responsáveis. Uma SBOM pode apoiar essa visibilidade, mas seu valor depende de atualização, identificadores consistentes e integração com o processo de vulnerabilidades. O inventário precisa acompanhar o artefato realmente entregue, não apenas o manifesto de uma etapa anterior do build.
Vulnerability handling precisa de entrada e saída claras
Receber um relato é apenas o início. O processo deve definir triagem, severidade, confirmação de impacto, correção, distribuição de atualização, comunicação e preservação das evidências. Sem uma ligação entre PSIRT, desenvolvimento, produto, suporte e jurídico, o relógio regulatório avança enquanto a organização ainda procura o responsável.
O pipeline passa a produzir evidência
Resultados de testes, políticas de aprovação, proveniência, assinatura e histórico de promoção ajudam a responder duas perguntas: “o que foi entregue?” e “quais controles foram executados?”. Isso não significa guardar todo log indefinidamente. Significa definir evidências proporcionais ao risco e protegê-las contra alteração ou perda.
Como verificar o nível de preparo
Uma avaliação inicial pode começar com perguntas concretas:
- Quais produtos e versões podem estar no escopo e quem responde por cada um?
- Qual período de suporte foi comunicado e como atualizações de segurança são distribuídas?
- É possível gerar um inventário reproduzível a partir do artefato entregue?
- Existe canal para receber vulnerabilidades e um processo para confirmar exploração ativa?
- Quem inicia o reporte e quais dados consegue reunir nas primeiras 24 horas?
- Os repositórios e pipelines preservam logs, aprovações e proveniência suficientes?
- Uma correção pode ser construída, testada, assinada e distribuída sem improviso?
- 01Produtoescopo, versão e responsável definidos
- 02Inventáriocomponentes relacionados ao artefato entregue
- 03Monitoramentovulnerabilidades e incidentes acompanhados continuamente
- 04Triagem e correçãoimpacto confirmado, contido e tratado
- 05Comunicaçãoreporte e atualização das partes envolvidas
- 06Evidênciaregistros preservados para melhoria do processo
O que uma ferramenta isolada não resolve
SCA ajuda a identificar componentes e vulnerabilidades conhecidas. SAST, DAST e outros controles ampliam a cobertura técnica. Nenhum deles, sozinho, define escopo regulatório, ownership, período de suporte, processo de reporte ou critérios de aceitação de risco. O CRA exige conexão entre governança de produto, engenharia, AppSec e resposta a incidentes.
Também é importante acompanhar orientações oficiais e atos de implementação. A Comissão Europeia continua publicando materiais de apoio; portanto, controles e interpretações devem ser revisados ao longo da preparação.
Fontes e referências
- Comissão Europeia — Cyber Resilience Act: implementation
- Comissão Europeia — CRA reporting obligations
- Comissão Europeia — resumo do texto legislativo
- EUR-Lex — Regulamento (UE) 2024/2847
Como isso se aplica ao seu ciclo de software?
A Xmart apoia equipes na avaliação de controles, evidências e arquitetura de AppSec e Software Supply Chain — do inventário à operação.
