OpenSSF define três papéis para ajudar projetos de código aberto a atender ao EU Cyber Resilience Act

O Cyber Resilience Act (CRA) da União Europeia impõe um conjunto de obrigações de segurança para produtos que contêm componentes digitais, e a lei tem implicações de longo alcance para a cadeia de suprimentos de código aberto. Para desmistificar essas obrigações, a Open Source Security Foundation (OpenSSF) publicou, em setembro de 2026, um caminho de preparação que identifica três papéis distintos dentro da comunidade de código aberto e descreve os deveres de cada um.

Três papéis, três conjuntos de responsabilidades

O guia separa o ecossistema em (1) mantenedores ou contribuidores, (2) stewards de código aberto e (3) fabricantes de produtos que incorporam código aberto. Essa taxonomia foi criada para corresponder à linguagem legal do CRA, que diferencia entre partes que apenas contribuem com código e aquelas que comercializam produtos finais.

A maioria dos contribuidores não comerciais fica fora da definição de “fabricante” segundo o CRA, o que significa que não estão automaticamente sujeitos às amplas obrigações de relato e remediação da lei. Sua responsabilidade principal continua sendo garantir a qualidade e a segurança do código que produzem, sem o pesado fardo de conformidade imposto aos atores comerciais.

O que faz um steward

Um steward de código aberto é definido como uma entidade jurídica que fornece suporte de longo prazo para projetos usados em atividades comerciais. Os stewards assumem funções de coordenação, governança e segurança, como manter uma política de segurança, gerenciar divulgações de vulnerabilidades e facilitar a cooperação entre usuários downstream.

Embora o CRA não imponha obrigações específicas aos stewards até 11 de dezembro de 2027, a OpenSSF recomenda que eles já implementem contatos de segurança, caminhos de escalonamento e processos colaborativos baseados nas melhores práticas. Essa postura proativa ajuda os fabricantes downstream a cumprir seus próprios prazos do CRA.

Fabricantes enfrentam o cronograma mais rígido

Um fabricante que vende um produto sob sua própria marca tem o conjunto mais amplo de obrigações. Desde 11 de setembro de 2026, os fabricantes devem relatar qualquer vulnerabilidade ativamente explorada ou incidente grave dentro de 24 horas e emitir uma notificação formal aos clientes dentro de 72 horas. O não cumprimento desses prazos pode resultar em multas e restrições de mercado previstas no CRA.

• Manter um arquivo SECURITY.md atualizado em cada repositório
• Disponibilizar um endereço de contato de segurança monitorado continuamente
• Adotar ferramentas de atestação da cadeia de suprimentos como SLSA, Sigstore, GUAC e OSPS Baseline
• Documentar procedimentos de escalonamento e compartilhá‑los com parceiros downstream

O guia também enfatiza a importância de integrar essas ferramentas em pipelines automatizados de CI/CD. Ao gerar registros criptográficos de proveniência (SLSA) e assinar artefatos (Sigstore), os projetos podem comprovar a integridade de suas compilações, exigência que os fabricantes precisarão demonstrar quando auditados pelas autoridades europeias.

Como uma única organização pode ocupar mais de um papel, o guia recomenda um mapeamento interno claro de responsabilidades. Por exemplo, uma empresa que tanto contribui para uma biblioteca de código aberto quanto vende um dispositivo de hardware que a incorpora deve tratar a parte de contribuição como atividade de mantenedor e a parte do dispositivo como atividade de fabricação, cada uma com sua própria lista de verificação de conformidade.

As recomendações da OpenSSF não constituem aconselhamento jurídico, mas visam ajudar a comunidade a alinhar‑se ao espírito do CRA. A fundação incentiva as partes interessadas a consultar assessoria jurídica para interpretações definitivas, especialmente à medida que os mecanismos de aplicação do CRA evoluem.

Para organizações brasileiras, o impacto prático é claro: identificar qual dos três papéis ocupa, adotar a documentação de segurança e as ferramentas sugeridas pela OpenSSF e estabelecer processos rápidos de relato de vulnerabilidades. Ao fazer isso, reduzem o risco de penalidades por não conformidade e contribuem para uma cadeia de suprimentos de código aberto mais resiliente no mercado da União Europeia.