É provável que a maioria das empresas brasileiras não saiba, hoje, quantos componentes de software existem dentro de seus próprios sistemas. Não por negligência, mas porque a forma como o software corporativo é construído mudou profundamente nos últimos anos, e a gestão de segurança, em muitos casos, não acompanhou essa mudança.
É importante entender de que “software desconhecido” estamos falando. Não se trata apenas de um programa instalado sem autorização na máquina de um funcionário. O ponto cego atual está dentro do próprio produto digital da empresa: dependências diretas e transitivas, imagens-base de contêineres, SDKs, plug-ins, scripts externos, componentes embutidos em frameworks, ações de automação usadas no pipeline e bibliotecas puxadas automaticamente por gerenciadores de pacotes.
O relatório OSSRA 2025 (Open Source Security and Risk Analysis), publicado pela Black Duck com base na análise de mais de mil bases de código comerciais, mostra que 97% das aplicações corporativas auditadas contêm componentes open source, e que entre 70% e 90% de todo o código em uso nas empresas vem de bibliotecas, frameworks e módulos de terceiros.
O ponto que merece atenção não é a presença de código de terceiros em si. Open source é a base da inovação tecnológica contemporânea, e poucas empresas teriam a capacidade ou a razão econômica para desenvolver tudo do zero. O problema é que 64% dessas dependências são transitivas, conforme o mesmo relatório da Black Duck — ou seja, são componentes puxados automaticamente por outros componentes, sem que o desenvolvedor os tenha escolhido ou, muitas vezes, sequer saiba que estão ali.
Este mesmo estudo também revelou que o número de arquivos open source por aplicação triplicou desde 2020, com crescimento de 30% apenas no último ano, impulsionado em parte pelo uso de ferramentas de desenvolvimento assistidas por inteligência artificial. Essa camada de invisibilidade cria uma superfície de ataque que a segurança tradicional não alcança. E os criminosos já entenderam isso.
SBOM: se tornando uma regra global
O conceito que vem ganhando tração como resposta a essa crise é o de SBOM, sigla em inglês para Software Bill of Materials — essencialmente, uma lista de ingredientes do software. Assim como a indústria farmacêutica ou alimentícia exige rastreabilidade de cada componente de um produto, o SBOM documenta formalmente cada biblioteca, módulo e dependência presente em uma aplicação. Quando uma vulnerabilidade como o Log4Shell é descoberta, a empresa que possui um SBOM atualizado sabe em minutos quais sistemas são afetados. Sem issi, a busca pode levar semanas.
Na Europa, o Cyber Resilience Act, aprovado em 2024, tornará SBOMs obrigatórios para todos os produtos digitais vendidos na União Europeia a partir de dezembro de 2027, com multas de até 15 milhões de euros. Nos Estados Unidos, a exigência introduzida pela administração Biden em 2021 foi flexibilizada em 2026 pela administração Trump, que tornou SBOMs discricionários para agências federais.
No Brasil, não existe regulação específica que exija SBOMs – mas a LGPD cria uma responsabilidade indireta: se dados pessoais são expostos por meio de um componente de software desconhecido ou não autorizado, a responsabilidade recai sobre a empresa, não sobre o desenvolvedor que incorporou a dependência.
A resposta a essa questão bastante complexa não começa pela aquisição de ferramentas, mas pela construção de visibilidade. Não é possível proteger o que não se consegue mapear. Inventariar os componentes que compõem os sistemas em uso, adotando práticas de SBOM e ferramentas de análise de composição de software, é o primeiro passo nesta direção. Além disso, também é preciso integrar a verificação de segurança diretamente ao processo de desenvolvimento, tratando cada dependência incorporada como uma decisão que precisa ser gerenciada.
O recado, portanto, é menos sobre tecnologia isolada e mais sobre governança de confiança. A pergunta que separa organizações resilientes das demais já não é apenas “nosso código é seguro?”, mas “sabemos exatamente que código, de quem, em que versão e com quais dependências está operando com a nossa confiança neste momento?”. Quem consegue responder a isso reduz tempo de exposição, acelera reação a incidentes, negocia melhor com fornecedores e evita que um pacote obscuro se transforme em crise de negócio. Quem não consegue segue apostando que o software invisível continuará invisível. Em segurança, esse costuma ser o tipo de aposta que cobra caro.
Alexandre Theodoro é diretor de Negócios e Soluções da Faiston
