OpenSSF define três papéis para ajudar projectos de código aberto a cumprir o EU Cyber Resilience Act

O Cyber Resilience Act (CRA) da União Europeia introduz um conjunto de obrigações de segurança para produtos que contêm componentes digitais, e a lei tem implicações de grande alcance para a cadeia de abastecimento de código aberto. Para desmistificar estas 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 as responsabilidades que cada um deve cumprir.

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

O guia separa o ecossistema em (1) mantenedores ou contribuidores, (2) responsáveis de código aberto e (3) fabricantes de produtos que incorporam código aberto. Esta taxonomia foi concebida para corresponder à linguagem legal do CRA, que distingue entre as partes que apenas contribuem com código e as que comercializam produtos acabados.

A maioria dos contribuidores não comerciais está fora da definição de “fabricante” ao abrigo do CRA, o que significa que não estão automaticamente sujeitos às amplas obrigações de reporte e remediação da lei. A sua responsabilidade principal continua a ser 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 responsável

Um responsável de código aberto é definido como uma entidade legal que fornece suporte a longo prazo para projectos utilizados em atividades comerciais. Os responsáveis assumem funções de coordenação, governação e segurança, como a manutenção de uma política de segurança, a gestão de divulgações de vulnerabilidades e a facilitação da cooperação entre utilizadores a jusante.

Embora o CRA não imponha obrigações específicas aos responsáveis até 11 de dezembro de 2027, a OpenSSF recomenda que já implementem contactos de segurança, caminhos de escalonamento e processos colaborativos segundo as melhores práticas. Esta postura proativa ajuda os fabricantes a jusante a cumprir os seus próprios prazos do CRA.

Fabricantes enfrentam o calendário mais rigoroso

Um fabricante que vende um produto sob a sua própria marca é a parte com 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 destes prazos pode resultar em multas e restrições de mercado ao abrigo do CRA.

• Manter um ficheiro SECURITY.md atualizado em cada repositório
• Disponibilizar um endereço de contacto de segurança monitorizado continuamente
• Adotar ferramentas de atestação da cadeia de abastecimento como SLSA, Sigstore, GUAC e OSPS Baseline
• Documentar procedimentos de escalonamento e partilhá‑los com parceiros a jusante

O guia também sublinha a importância de integrar estas ferramentas em pipelines automatizados de CI/CD. Ao gerar registos criptográficos de proveniência (SLSA) e assinar artefactos (Sigstore), os projectos podem provar a integridade das suas compilações, exigência que os fabricantes terão de demonstrar quando auditados pelas autoridades da UE.

Como uma única organização pode ocupar mais de um papel, o guia recomenda um mapeamento interno claro das responsabilidades. Por exemplo, uma empresa que tanto contribui para uma biblioteca de código aberto como vende um dispositivo 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 a sua própria lista de verificação de conformidade.

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

Para as organizações de língua portuguesa, o impacto prático é claro: devem identificar qual dos três papéis ocupam, adotar a documentação e as ferramentas de segurança sugeridas pela OpenSSF e estabelecer processos de reporte rápido de vulnerabilidades. Ao fazê‑lo, reduzem o risco de penalizações por não conformidade e contribuem para uma cadeia de abastecimento de código aberto mais resiliente no mercado da UE.