O Cyber Resilience Act da União Europeia não transforma automaticamente todo mantenedor voluntário em fabricante de produto. O desafio de engenharia é identificar o papel de cada organização na cadeia e fazer a resposta a vulnerabilidades funcionar entre quem desenvolve e quem distribui software.
Escopo: este é um panorama prático de engenharia, não aconselhamento jurídico. A classificação depende dos fatos: quem disponibiliza o produto no mercado da UE, se há atividade comercial, quem responde pelo produto e que apoio contínuo uma organização presta. Para avaliar um produto ou entidade específicos, consulte profissionais jurídicos qualificados.
O CRA regula produtos com elementos digitais disponibilizados no mercado da UE e concentra as obrigações de conformidade do produto nos fabricantes. Software de código aberto disponibilizado no contexto de uma atividade comercial pode estar no escopo; software desenvolvido ou fornecido fora dessa atividade recebe tratamento diferente. Contribuir com código para um projeto aberto, sem responsabilidade pelo software, não transforma automaticamente uma pessoa em fabricante.
A lei define o steward de software de código aberto como uma pessoa jurídica que, sem ser fabricante, oferece apoio sistemático e contínuo a um software livre e aberto específico destinado a atividades comerciais e garante sua viabilidade. É um papel organizacional mais delimitado, não um sinônimo de qualquer mantenedor individual. Já uma empresa que integra uma biblioteca a um produto que coloca no mercado pode ter responsabilidades de fabricante por esse produto, mesmo que os componentes venham de uma comunidade.
Os papéis se conectam. Um steward pode coordenar a resposta compartilhada a uma falha upstream, enquanto o fabricante downstream continua responsável por avaliar seu produto, identificar versões afetadas, informar usuários e cumprir notificações aplicáveis. Ter uma dependência listada na SBOM não transfere responsabilidade; receber uma correção upstream tampouco prova que o produto distribuído foi corrigido.
Em 28 de setembro de 2026, os materiais de implementação da Comissão Europeia indicam que as obrigações de notificação do Artigo 14 para fabricantes passaram a valer em 11 de setembro de 2026. As obrigações correspondentes dos stewards começam em 11 de dezembro de 2027, data de aplicação geral do CRA. Não replique o prazo do fabricante em uma lista para mantenedores como se todos os projetos tivessem a mesma obrigação.
| Marco | Quem / o quê | Implicação para engenharia |
|---|---|---|
| 11 de setembro de 2026 | Passam a valer as notificações do Artigo 14 para fabricantes. | Times de produto precisam avaliar, encaminhar e notificar vulnerabilidades exploradas ativamente e incidentes graves que estejam no escopo. |
| 11 de dezembro de 2027 | Aplicação geral do CRA; começam as obrigações de notificação dos stewards. | Organizações que se enquadrem na definição de steward devem ter política documentada e fluxo funcional de vulnerabilidades. |
| 11 de dezembro de 2027 | Aplicação geral das obrigações do CRA para produtos. | Fabricantes precisam de evidências de conformidade por produto, avaliação de risco e processos de suporte e atualização. |
Para fabricantes, o Artigo 14 define etapas com prazos específicos, incluindo um alerta inicial em até 24 horas e uma notificação em até 72 horas para vulnerabilidades exploradas ativamente e incidentes graves abrangidos. Isso não é um SLA genérico de resposta a incidentes para todo mantenedor de código aberto. Defina quem avalia a aplicabilidade e quem envia a notificação; utilize a plataforma europeia de notificação quando o dever e o processo forem aplicáveis.
Estruture o registro da vulnerabilidade: identificador, relator, horário de recebimento, faixas afetadas, reprodução, justificativa de severidade, evidência de exploração, partes envolvidas, commits, versões corrigidas, avisos e evidência de encerramento. Restrinja o acesso enquanto a correção é coordenada; depois da divulgação, mantenha referências suficientes para reconstruir o que mudou e quais produtos foram afetados.
O Artigo 24 prevê que stewards documentem uma política de cibersegurança verificável, voltada ao desenvolvimento seguro e ao tratamento eficaz de vulnerabilidades, incentivem relatos voluntários, tratem e corrijam falhas identificadas, compartilhem informações relevantes e cooperem com autoridades de fiscalização de mercado. A política deve considerar a natureza e a estrutura da organização. Não significa criar um departamento corporativo em torno de um pequeno projeto.
Para uma biblioteca ou componente mantido, eu montaria um processo leve usando ferramentas que o projeto já conhece: formulário ou e-mail privado, rastreador de acesso restrito, índice de SBOMs e dependências por release, CI que registre testes e procedência, além de um feed assinado de avisos. Um serviço simples poderia cruzar coordenadas e faixas de versão com manifestos dos consumidores, abrindo tarefas para os responsáveis por cada produto.
O objetivo é rastreabilidade, não prometer que todos os consumidores são conhecidos. Acompanhe o tempo até a confirmação do relato, a identificação das versões afetadas, a publicação da correção e a confirmação dos consumidores downstream. Publique as limitações com clareza. A classificação legal e as decisões de notificação devem ficar com a organização que possui o papel jurídico pertinente.
| Falha | Sinal | Controle |
|---|---|---|
| Todo mantenedor é tratado como steward | A política atribui deveres a indivíduos sem verificar os critérios de pessoa jurídica. | Registre as premissas sobre o papel e peça avaliação jurídica da organização e da atividade. |
| Patch upstream é confundido com correção do produto | O aviso é encerrado, mas produtos distribuídos continuam em versões vulneráveis. | Rastreie a dependência até a versão do produto e exija uma decisão downstream. |
| A caixa de relatos não tem responsável | Relatos ficam parados durante ausências ou são publicados em issues abertas. | Teste o roteamento titular/suplente e monitore confirmações pendentes. |
| A SBOM existe, mas não pode ser consultada | Não é possível encontrar releases afetados na janela curta de notificação. | Armazene SBOMs legíveis por máquina por digest imutável e automatize a busca por componente e versão. |
| O relógio do incidente começa tarde | O primeiro momento de ciência se perde entre suporte, segurança e jurídico. | Persista o horário inicial de conhecimento e escale eventos regulatórios potenciais de imediato. |
O CRA é uma regulação de segurança de produtos com papéis distintos, não uma regra que transforma cada contribuidor de repositório em fabricante. Stewards de código aberto têm deveres próprios quando atendem à definição legal; fabricantes continuam responsáveis pelo produto. Comece pelos mecanismos compartilhados: relato privado, triagem reproduzível, rastreabilidade de dependências e releases, correção coordenada e passagem clara para os consumidores. Depois valide o papel e os prazos da organização com fontes oficiais e orientação jurídica.
Nota editorial: Este artigo resume materiais da União Europeia para discussão de engenharia, com referência em 28 de setembro de 2026. Não é aconselhamento jurídico nem determina se uma entidade ou produto específico está sujeito ao CRA.