Ouviu-nos no FOSS Weekly? Comece por aqui.

O CRA e o open source: em que papel fica o seu projeto

A Folhas Etéreas é uma consultoria portuguesa de segurança de produto, vinda do pentest e do red team, que prepara fabricantes para o Cyber Resilience Act e faz avaliações ofensivas do firmware às instalações. Esta página existe porque o CRA diz respeito a muita gente que faz open source, e a maior parte ainda não sabe em que papel.

O CRA e o open source, em quatro factos

Software livre e open source fornecido fora de uma atividade comercial está fora do âmbito. Um projeto mantido sem contrapartida, publicado para quem o quiser usar, não é «disponibilizado no mercado» no sentido do regulamento, porque falta a atividade comercial (artigo 2.º, n.º 1, e artigo 3.º, ponto 22), e por isso as obrigações de fabricante não se lhe aplicam.
«Grátis» não significa «não comercial». Vender suporte acima do custo real, uma edição enterprise ou monetizar dados do software é atividade comercial, e a partir daí o projeto passa a produto, com um fabricante responsável. O artigo 07 desenha a fronteira com exemplos.
Pessoas coletivas que apoiam de forma sistemática e continuada software livre e de código aberto destinado a atividades comerciais, como certas fundações, têm um regime próprio, mais leve. O regulamento chama-lhes «administradores de software de código-fonte aberto» (artigo 24.º): política de cibersegurança e cooperação com as autoridades de fiscalização do mercado. O reporte de vulnerabilidades ativamente exploradas só se lhes aplica na medida em que estejam envolvidos no desenvolvimento, e o de incidentes graves só quando estes afetem as redes e os sistemas de informação que fornecem para esse desenvolvimento (artigo 24.º, n.º 3). Não há marcação CE nem avaliação de conformidade. Estas obrigações só se aplicam a partir de 11 de dezembro de 2027 (artigo 71.º, n.º 2); o reporte dos fabricantes aplica-se desde 11 de setembro de 2026.
Quem integra open source num produto responde por ele. O fabricante que mete uma biblioteca no firmware tem de a inventariar na SBOM, acompanhar as suas vulnerabilidades e corrigi-las no produto. As obrigações de fabricante não sobem para quem mantém a biblioteca fora de uma atividade comercial; ficam com quem a vende dentro de um produto. O fabricante tem, ainda assim, deveres para com quem mantém o componente: se encontrar nele uma vulnerabilidade, tem de a comunicar a essa pessoa ou entidade e, se desenvolver uma correção, partilhar com ela o código ou a documentação (artigo 13.º, n.º 6, aplicável a partir de 11 de dezembro de 2027). Se a biblioteca for ela própria um produto comercial, quem a fabrica tem obrigações próprias, que não dispensam as do integrador. O artigo 09 aplica isto a um caso concreto: as falhas do PHP e do Node.js, dois projetos open source, corrigidas a 21 de outubro de 2026.

Como este site pratica o que diz

O código deste site é público. Publicamos um security.txt com chave PGP para relatórios de vulnerabilidades, montado como descrevemos no artigo 08. A política de segurança de conteúdo fecha o site ao próprio domínio, e não há analítica nem cookies. O nosso produto, o Aeromate, tem uma edição Community aberta, e a sua preparação para o CRA está documentada em público no diário de bordo, com as falhas incluídas.

O que fazemos, em três linhas

Segurança de produto e preparação para o CRA, do protótipo ao produto vendável. Avaliações ofensivas: pentest whitebox de firmware e sistema, modelação de ameaças e intrusão física em instalações, sempre com âmbito e autorização escritos. E o Aeromate, que passa pelo mesmo crivo que aconselhamos. O detalhe está em serviços.

Primeira leitura para projetos, sem custo

Descreva-nos o projeto ou o produto por email, o que é, como se distribui, se há dinheiro envolvido e como, e em cinco dias úteis devolvemos uma nota escrita, de duas páginas, com três coisas: se o CRA lhe chega e em que papel (fabricante, administrador de código aberto ou fora de âmbito), as datas que se aplicam, e as três decisões mais urgentes. Sem chamada, sem reunião e sem seguimento comercial, a não ser que o peça.

Para que fique claro à partida. A leitura baseia-se apenas na informação que nos enviar. Não é uma auditoria, não é um parecer jurídico e não é uma avaliação de conformidade. Não envie código, credenciais nem documentação confidencial; uma descrição funcional e o modelo de distribuição chegam bem.

Para pedir: oi@folhas.io com o assunto "Primeira leitura (open source)".

Não medimos visitas. Se veio do podcast, diga-o no email: é a única forma de sabermos.