Tag: governança

CRA da UE e segurança de código aberto: o que muda (e por quê)

[vc_row][vc_column][vc_column_text]

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.

[/vc_column_text][vc_row_inner][vc_column_inner][us_separator][vc_column_text]

• Quer aprender a desenvolver softwares? A Fast Lane oferece um portfólio de treinamentos e certificações líder de mercado. Confira aqui.

• Assine a newsletter da TechTalk e fique informado de tudo.

[/vc_column_text][us_separator][/vc_column_inner][/vc_row_inner][vc_column_text]

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

[/vc_column_text][vc_row_inner][vc_column_inner][us_separator][vc_column_text]

• Fast Lane oferece treinamentos de Inteligência Artificial e Machine Learning dos principais fabricantes

• Assine a newsletter da TechTalk e fique informado de tudo

[/vc_column_text][us_separator][/vc_column_inner][/vc_row_inner][vc_column_text]

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.

[/vc_column_text][/vc_column][/vc_row]