Do esforço comunitário ao mandato legal
O mundo digital roda em software de código aberto. Ele está nos apps do dia a dia e na infraestrutura que sustenta serviços críticos. Essa onipresença, porém, elevou a régua de segurança. Incidentes como SolarWinds e a falha no XZ Utils evidenciaram que o problema não é teórico. A comunidade open source tem histórico de colaboração e resiliência, mas um novo movimento regulatório está redistribuindo responsabilidades. O Ato de Resiliência Cibernética da União Europeia (CRA) chega para exigir segurança ao longo de todo o ciclo de vida de produtos de hardware e software com elementos digitais comercializados na UE.
Durante décadas, a segurança em open source foi tratada como um esforço compartilhado: mantenedores e colaboradores cuidavam do “rio acima” (upstream), enquanto muitas empresas consumiam componentes e só adicionavam “remendos” perto do lançamento. Essa abordagem tardia limitou a adoção de práticas como segurança da cadeia de suprimentos. O argumento “sempre funcionou assim” ignora um ponto básico: segurança não elimina riscos; dificulta a vida do atacante quando o ataque acontece.
O CRA busca corrigir esse descompasso. A lei define obrigações de segurança por design e por padrão a fabricantes ao longo do ciclo do produto. A aplicação completa está prevista para dezembro de 2027, mas obrigações de reportede vulnerabilidades exploradas e incidentes graves começam já em setembro de 2026. O intervalo entre a publicação dos documentos de implementação e a fiscalização será curto. Portanto, é hora de entender a intenção da lei — e o que ela significa para todo o ecossistema open source.
Responsabilidade compartilhada, de fato
A ambição do CRA é acelerar, em poucos anos, práticas que a indústria vem discutindo há décadas. Ele também joga luz sobre novas obrigações de stewardship (tutela/zeladoria). Pela primeira vez, surge em lei europeia a figura do Open Source Software Steward. Ainda que projetos comunitários, sem monetização direta, fiquem tecnicamente fora do escopo, a prática é mais sutil: sempre que empresas ou indivíduos monetizam tecnologias abertas incorporando projetos upstream, esses projetos passam a orbitar a esfera do CRA — direta ou indiretamente.
Isso tem gerado um choque cultural. Mesmo antes do CRA, alguns projetos recebiam pedidos de “compliance” sem compreensão de como o desenvolvimento aberto funciona. Agora, multiplicam-se solicitações com mentalidade de “checklist” que deslocam o ônus para os mantenedores, em vez de as empresas implementarem os controles de que precisam — ou contribuírem tais melhorias de volta ao upstream. Esse equívoco deturpa o modelo de responsabilidade compartilhada, no qual o adotante de open source deve assegurar a segurança necessária na forma como usa o software.
De padrões desalinhados a um caminho “open source-first”
Profissionais da Red Hat e de outras organizações têm participado da formulação de políticas do CRA (por associações e fundações) e da elaboração de normas técnicas nas ESOs (European Standardization Organizations). Ainda assim, muitos padrões corporativos são complexos, extensos e pagos, o que não se traduz bem ao mundo aberto. Projetos comunitários, com recursos limitados, não conseguem absorver uma “enciclopédia” de requisitos pensados para ambientes centralizados e proprietários — frequentemente baseados em um modelo “caixa-preta” distante da realidade colaborativa e transparente do open source.
Reconhecer as características do desenvolvimento aberto é crucial: colaboração pública, construção por componentes, diversidade de maturidade e a inexistência de “obrigações contratuais” além da licença. Também é preciso encarar o déficit de talentos em segurança e a tensão entre práticas tradicionais (por exemplo, security-through-obscurity) e o ethos de transparência.
Uma resposta pragmática é o Open Source Project Security (OSPS) Baseline: um conjunto de critérios “open source-first” que traduz exigências corporativas em orientações claras, relevantes e aplicáveis por mantenedores e colaboradores. Os Baselines consideram “eras” e perfis de projetos — como são desenvolvidos, governados e distribuídos — para que cada um possa elevar sua segurança respeitando valores e motivações.
Os Baselines não resolvem sozinhos o CRA. Falta ferramental aberto, centrado no desenvolvedor — interoperável — para produzir informações de segurança como metadados de cadeia de suprimentos e SBOM (bill of materials), independentemente do repositório. Com isso, fabricantes e consumidores enxergam o que já foi feito e o que falta no seu contexto. É a chance de continuar o avanço em supply chain security por dois lados: de baixo para cima(comunidade/projeto) e de cima para baixo (padrões/regulação) — de modo significativo, gerando software mais seguro para todos.
Stewardship: transformar ônus legal em oportunidade
O CRA pode elevar a segurança em empresas e no open source. Ele incentiva boas práticas, diligência e reportes ao longo da cadeia, promovendo o diálogo entre todos os atores. O que ele não deve fazer é converter mantenedores em “fornecedores” de empresas comerciais. Usar o CRA para transferir obrigações dessa forma é inadequado
Aqui entra o stewardship. A visão da Red Hat não trata a tutela como fardo, mas como oportunidade positiva — ainda que exija colaboração real com a comunidade tutelada. Leis como o CRA servem de catalisador para priorizar segurança, algo que muitas vezes fica para depois. Na prática, isso significa oferecer suporte sistemático a projetos: canais de divulgação de vulnerabilidades, documentação acessível, e proteção contra demandas externas desalinhadas, trabalhando junto à comunidade para incorporar segurança em design, governança, desenvolvimento e disponibilidade.
A abordagem da Red Hat é comunitária, buscando mínima sobrecarga para os projetos e produzindo materiais e modelos práticos que geram “segurança real”. Essa postura é defendida em ecossistemas como OpenSSF Global Cyber Policy WG e Eclipse ORC WG, entre outros. A meta vai além da conformidade com o CRA: é um convitepara o ecossistema open source agir e se apoiar mutuamente.
Responsabilidade coletiva: participação ativa, não consumo passivo
No open source, consumo passivo nunca foi o ideal. A segurança é uma expectativa compartilhada e dinâmica, que requer participação ativa ao longo do ciclo do produto. Adotantes de open source têm o dever de se engajar e contribuir conforme a cultura e as regras de cada projeto.
Não se trata de apontar culpados, e sim de reconhecer a necessidade de evoluir: sair da segurança “tardia” de ontem para a segurança por padrão exigida por um mundo hiper-dependente. Mantenedores são espinha dorsal do digital. Se recriássemos o open source do zero, o custo estimado seria de US$ 8,8 trilhões (Harvard, 2024). Aproveite o momento para elevar a segurança dos seus projetos nos seus termos — não só por conformidade, mas pela saúde e resiliênciade todo o ecossistema.
