Serviços públicos, bancos, indústrias e plataformas de nuvem dependem de componentes open source. A questão não é transformar todo projeto em empresa, mas garantir governança, capacidade de manutenção e resposta de segurança compatíveis com a importância que cada organização atribui ao software.
Open source costuma ser tratado como estoque gratuito: instala-se um pacote, executa-se um scanner e presume-se que outra pessoa cuidará da manutenção. Mas uma dependência pode ser o projeto individual de alguém, uma iniciativa de fundação ou um produto com suporte comercial. A licença permite certos usos do código; ela não promete prazo de resposta, releases compatíveis ou uma equipe de segurança financiada.
Em junho de 2026, a Comissão Europeia anunciou uma nova Estratégia de Open Source no pacote de soberania tecnológica, destacando apoio a soluções, competências, infraestrutura e reutilização pela administração pública. Isso indica uma direção de política, não comprova que um mantenedor ou biblioteca específica receberá recursos. As equipes ainda precisam conhecer sua exposição e suas responsabilidades de contratação.
Downloads e estrelas são indicadores fracos de importância operacional. Uma pequena biblioteca criptográfica pode estar no caminho crítico de milhares de produtos; uma ferramenta de interface popular pode ser substituível. Monte um grafo a partir de SBOMs e evidências de runtime e acrescente criticidade do serviço, superfície de ataque alcançável, dados tratados, restrições de atualização, suporte e alternativas. Priorize consequências e exposição, não apenas a contagem de CVEs.
| Sinal | O que registrar | Por que importa |
|---|---|---|
| Papel operacional | Serviços, produtos, limites de segurança e caminhos de dados | Estima o impacto de falha ou comprometimento. |
| Manutenção | Releases, branches suportadas, concentração de mantenedores e resposta | Indica se correções podem chegar e ser adotadas. |
| Processo de segurança | Canal de divulgação, política de correção, proveniência e builds | Reduz incerteza durante resposta a vulnerabilidades. |
| Alternativas | Custo de fork, compatibilidade, substituição e migração | Transforma dependência em decisão recuperável. |
Mantenedores precisam de tempo para revisar contribuições, triar relatos, testar releases, publicar avisos e cuidar da infraestrutura de build. O apoio pode incluir bolsas recorrentes, contratos de manutenção, horas pagas por empregadores, suporte fiscal de fundações, auditorias de segurança, builds reproduzíveis ou capacidade compartilhada de resposta. O acordo deve dar transparência a entregas e governança sem tornar um único patrocinador a autoridade da comunidade.
Quem depende de uma biblioteca pode contribuir upstream em vez de acumular patches privados. Um plano prático pode financiar manutenção, corrigir um bug difícil, ampliar testes, documentar atualizações ou manter uma branch compatível. Respeite a governança do projeto e não publique dados confidenciais de clientes ou detalhes de segurança sem coordenação.
O Cyber Resilience Act europeu distingue responsabilidades comerciais de produtos e atividades de stewardship de open source; o papel exato depende das circunstâncias. Evite simplificações como “todo mantenedor é fabricante” ou “open source está isento de tudo”. Fabricantes devem mapear os componentes incorporados, definir tratamento de vulnerabilidades, preservar evidências técnicas e avaliar seu papel com apoio jurídico qualificado. A licença pública não transfere as obrigações do fabricante do produto a colaboradores voluntários.
Governança requer contatos de escalonamento, política de versões suportadas, expectativas de divulgação e coordenação de correções entre usuários downstream. Para projetos críticos, uma política de segurança objetiva e releases assinados podem valer mais do que um selo sem manutenção.
Compradores públicos podem exigir padrões abertos, dados exportáveis, disponibilidade do código quando apropriado, opções para contribuir upstream e planos de suporte de longo prazo. Os requisitos devem valorizar interoperabilidade e manutenção sem impor uma licença específica sem considerar o contexto. Uma contratação pode financiar suporte ou uma bolsa comum, mas precisa definir resposta de segurança, propriedade de releases, propriedade intelectual e o que ocorre quando o financiamento termina.
Meça resultados verificáveis: dependências críticas com responsáveis nomeados, tempo de correção, cobertura de versões suportadas, patches aceitos upstream, releases reproduzíveis, alternativas documentadas e horas financiadas. Isso é mais útil que contar repositórios ou anunciar que a organização “usa open source”.
Conectaria a geração de SBOM à propriedade de serviços e a um registro de risco de dependências. Cada componente crítico teria responsável interno, contato upstream, situação de suporte, fluxo de correção e divulgação, janela de atualização, fallback e custo de saída. Uma revisão trimestral confrontaria criticidade com capacidade real dos mantenedores e apoio disponível; compras veria os riscos pendentes antes da renovação contratual. Patrocínio e contribuições seriam tratados como resiliência, não marketing.
Para projetos apoiados, publicaria governança, trabalho financiado, critérios de release e processo para conflitos de interesse. Preservaria a independência dos contribuidores, manteria relatos de segurança confidenciais até a divulgação coordenada e evitaria prometer níveis de serviço que a comunidade não consegue cumprir.
Sustentabilidade open source é uma questão operacional: software crítico precisa de manutenção, processo de segurança, governança e recuperação plausível. O novo interesse político europeu pode ajudar a criar demanda e infraestrutura comum, mas cada organização ainda precisa financiar e gerir as dependências das quais depende. Mapeie o risco a partir do inventário, contribua upstream, contrate suporte com clareza e mantenha precisos os papéis legais.
Nota editorial: Este texto é sobre engenharia de software, não aconselhamento jurídico. Obrigações do CRA dependem do produto e do papel dos envolvidos; consulte especialistas para casos concretos.