Guia dos EUA sobre segurança do código aberto: a auditabilidade faz a diferença

Artigo Original: Italo Vignoli

Em 30 de julho de 2026, a Agência de Segurança Cibernética e de Infraestrutura dos Estados Unidos (CISA) publicou o documento Open Source Software: Security Principles and Practices (Software de Código Aberto: Princípios e Práticas de Segurança), um guia de 31 páginas destinado a agências civis federais. O documento está disponível gratuitamente e classificado como TLP:CLEAR, o que significa que pode ser compartilhado sem restrições.

O documento destina-se às agências federais dos EUA e cumpre com obrigações estabelecidas em dois decretos federais sobre segurança cibernética. Aborda quatro áreas: emprego de soluções de código aberto, contribuição para projetos de código aberto, produção de software de código aberto e avaliação de modelos de inteligência artificial de código aberto. As observações a seguir referem-se às três primeiras áreas.

Seu conteúdo analítico não se restringe a uma jurisdição específica; as administrações públicas de outras regiões — incluindo a Europa — perceberão que o documento articula diversos posicionamentos que a comunidade de código aberto defende há duas décadas, utilizando a terminologia de gestão de riscos.

O que o guia recomenda

A afirmação central é mais precisa do que as manchetes sugerem. A CISA não afirma que o software de código aberto é mais seguro do que o software proprietário. Inclusive que o software de código aberto (OSS) “não tem mais riscos do que outros softwares”. Mas aponta a diferença em outro aspecto: com o código aberto, uma organização pode avaliar diretamente a qualidade e a segurança do código, em vez de depender exclusivamente das garantias do fornecedor.

Trata-se de uma afirmação sobre auditabilidade, e não sobre número de bugs ou vulnerabilidades. É também a afirmação mais defensável e a que traz maiores consequências para processos de aquisição. Ao avaliar um software proprietário a agencia está avaliando a declaração do fornecedor sobre o seu próprio produto. Ao avaliar um software de código aberto, a agencia está na realidade, avaliando o produto propriamente dito.

O guia CISA conclui explicitamente: Entre os benefícios relacionados para o Estado está a redução da dependência exclusiva de fornecedores (*vendor lock-in*): padrões abertos e código modificável, escreve a CISA, protegem as agências contra “armadilhas da dependência de tecnologias proprietárias”. Coloca-se a questão da dependência exclusiva de um fornecedor (*lock-in*) no documento sobre segurança acima da política de concorrência. Tal é uma mudança significativa no contexto em que esse argumento é abordado.

O Framework C4

A parte mais prática da orientação é o Apêndice A, que estabelece o arcabouço C4 para avaliar a confiabilidade de um projeto de código aberto (*open source*). Sua premissa é que, como os colaboradores podem usar pseudônimos e não estão sujeitos a obrigações de entrega, a confiabilidade não pode ser avaliada com base em quem produziu o software. Ela deve ser avaliada com base em *como* o software foi produzido — aspecto que o desenvolvimento de código aberto torna visível de uma maneira que o desenvolvimento de código fechado não permite.

O C4 agrupa as evidências em quatro categorias:

Base de código — frequencia dos *commits*, vulnerabilidades conhecidas, atualização das dependências.
Comunidade — número de mantenedores, estrutura institucional, se o projeto está vinculado a uma fundação.
Conduta — existência de política de divulgação de vulnerabilidades, exigência de revisão de código, se os mantenedores incorporam (*merge*) seus próprios *commits*, licença, código de conduta.
Configuração — se as configurações padrão são seguras e quais medidas de reforço de segurança (*hardening*) o software suporta.

O arcabouço (framework) é aplicado em cinco etapas: identificar critérios mensuráveis, determinar a tolerância ao risco e atribuir pesos aos critérios, coletar observações (utilizando ferramentas automatizadas, quando disponíveis), avaliar cada critério e comparar o resultado com a tolerância estabelecida.

Incentivamos as administrações públicas a aplicar esse arcabouço ao LibreOffice. Todas as categorias podem ser respondidas com base em evidências públicas: histórico contínuo de *commits* desde 2010, política de segurança e processo de divulgação publicados, revisão obrigatória por pares, licença aprovada pela OSI, código de conduta documentado e uma estrutura de governança — a The Document Foundation, a fundação alemã (*Stiftung*) com Conselho de Administração eleito — que é de registro público, e não somente uma afirmação.

Incentivamos as administrações do Estado a aplicar o mesmo arcabouço a todas as soluções candidatas, inclusive as proprietárias, e a observar quais perguntas podem ser respondidas e quais não.

Contribuição e a questão do suporte

A orientação também aborda uma questão frequentemente levantada pelas administrações públicas sobre a adoção de código aberto: quem é responsável pelas correções? A resposta da CISA é que nenhuma entidade isolada é obrigada a fornecê-los e que, portanto, as agências devem planejar-se adequadamente — alocando pessoal interno, contratando terceiros ou ambos — ao mesmo tempo em que seguem dois princípios ao lidar com projetos *upstream*: colaborar em vez de exigir e promover a incorporação de correções “rio acima” (*upstream*).

O ecossistema do LibreOffice funciona desta maneira. O suporte, a manutenção de longo prazo e o desenvolvimento personalizado são fornecidos por desenvolvedores e profissionais de migração certificados, cujas contribuições retornam ao código compartilhado e beneficiam todas as outras implementações. A orientação acerta ao afirmar que há necessidade de planejamento por parte das organizações. Também acerta ao apontar que as melhorias resultantes devem ser compartilhadas, em vez de ficarem restritas a uma única entidade.

A CISA observa ainda que, caso um projeto deixe de receber manutenção, uma organização pode, como último recurso, assumir um *fork* (ramificação) do projeto. Essa possibilidade não encontra equivalente em softwares proprietários, nos quais o fim do suporte ocorre conforme o cronograma do fornecedor e não oferece nenhuma alternativa de solução.

Uma observação sobre o escopo

O documento não cita nenhum produto específico. A CISA declara explicitamente que não endossa entidades, produtos ou serviços comerciais, e nada nas orientações deve ser interpretado como uma avaliação de qualquer software em particular. O que o documento apresenta é um conjunto de critérios. A observação de que o LibreOffice atende a esses critérios é nossa e baseia-se em evidências que qualquer pessoa pode verificar. O documento Open Source Software: Security Principles and Practices (Software de Código Aberto: Princípios e Práticas de Segurança) está disponível na CISA: https://www.cisa.gov/resources-tools/resources/open-source-software-security-principles-and-practices