Empresas brasileiras podem desconhecer softwares perigosos em seus sistemas, elevando o risco de vulnerabilidades e ataques.
A maioria das empresas brasileiras pode não ter clareza sobre a quantidade exata de componentes de software operando em seus ambientes de Tecnologia da Informação (TI). Essa desinformação não se deve necessariamente à negligência, mas sim a uma profunda transformação na maneira como o software corporativo é desenvolvido, uma evolução que, em muitos casos, a gestão de segurança ainda não conseguiu acompanhar.
O conceito de “software desconhecido” vai além de um programa instalado sem permissão na máquina de um colaborador. A verdadeira cegueira atual reside no interior dos próprios produtos digitais da empresa. Isso inclui dependências diretas e transitivas, imagens-base de contêineres, kits de desenvolvimento de software (SDKs), plugins, scripts externos, componentes embutidos em frameworks, ações de automação utilizadas no pipeline de desenvolvimento e bibliotecas carregadas automaticamente por gerenciadores de pacotes.
Um estudo de referência, o relatório OSSRA 2025 (Open Source Security and Risk Analysis), conduzido pela Black Duck com a análise de mais de mil bases de código comerciais, revela um cenário preocupante: 97% das aplicações corporativas auditadas contêm componentes de código aberto (open source). Mais alarmante ainda é o fato de que entre 70% e 90% de todo o código em uso nas empresas provém de bibliotecas, frameworks e módulos desenvolvidos por terceiros.
O ponto crucial de atenção não é a simples presença de código de terceiros. O código open source é, de fato, o alicerce da inovação tecnológica contemporânea. Poucas organizações teriam a capacidade ou a justificativa econômica para desenvolver todas as suas soluções internamente, do zero. O cerne da questão é que 64% dessas dependências são transitivas, de acordo com o mesmo relatório da Black Duck. Isso significa que são componentes acionados automaticamente por outros componentes, sem que o desenvolvedor tenha feito uma escolha explícita por eles, ou, em muitos casos, sem que sequer tenha conhecimento de sua existência.
Este mesmo estudo aponta um crescimento expressivo: o número de arquivos open source por aplicação triplicou desde 2020, com um aumento de 30% apenas no último ano. Esse crescimento acelerado é, em parte, impulsionado pelo uso de ferramentas de desenvolvimento auxiliadas por inteligência artificial. Essa camada de invisibilidade cria uma superfície de ataque que a segurança de TI tradicional, muitas vezes, não consegue alcançar. E os agentes maliciosos já exploram essa brecha.
SBOM: A Nova Norma Global de Segurança de Software
Em resposta a essa crescente crise de segurança, o conceito de SBOM (Software Bill of Materials) vem ganhando força. Essencialmente, o SBOM funciona como uma lista de ingredientes para o software. Assim como as indústrias farmacêutica e alimentícia exigem rastreabilidade completa de cada componente de seus produtos, o SBOM documenta formalmente cada biblioteca, módulo e dependência presente em uma aplicação. A grande vantagem é a agilidade: quando uma vulnerabilidade crítica como a Log4Shell é descoberta, uma empresa que mantém um SBOM atualizado consegue identificar em minutos quais sistemas são afetados. Sem essa documentação, a busca por esses sistemas pode se estender por semanas.
A nível internacional, a adoção do SBOM está se tornando uma exigência cada vez mais presente. Na Europa, o Cyber Resilience Act, aprovado em 2024, tornará os SBOMs obrigatórios para todos os produtos digitais comercializados na União Europeia a partir de dezembro de 2027, com a previsão de multas que podem chegar a 15 milhões de euros. Nos Estados Unidos, a exigência inicial introduzida pela administração Biden em 2021 foi sujeita a uma flexibilização em 2026 pela administração Trump, que tornou os SBOMs discricionários para agências federais, embora a recomendação de adoção permaneça.
No Brasil, ainda não existe uma legislação específica que obrigue a utilização de SBOMs. No entanto, a Lei Geral de Proteção de Dados (LGPD) estabelece uma responsabilidade indireta significativa. Caso dados pessoais sejam expostos em decorrência de um componente de software desconhecido ou não autorizado, a responsabilidade legal recai sobre a empresa, e não sobre o desenvolvedor que incorporou a dependência. Isso impõe às empresas a necessidade de conhecerem a fundo os componentes que utilizam.
Visibilidade e Governança: Pilares da Nova Segurança
A solução para essa questão complexa não reside unicamente na aquisição de novas ferramentas, mas fundamentalmente na construção de visibilidade. A premissa básica é: não é possível proteger aquilo que não se consegue mapear. O primeiro passo essencial é o inventário detalhado dos componentes que integram os sistemas em uso. Isso envolve a adoção de práticas de SBOM e a utilização de ferramentas de análise de composição de software. Além disso, é crucial integrar a verificação de segurança diretamente ao processo de desenvolvimento, tratando cada dependência incorporada como uma decisão estratégica que necessita de gerenciamento contínuo.
A mensagem central, portanto, transcende a tecnologia isolada, focando na construção de uma governança de confiança robusta. A pergunta que, atualmente, diferencia as organizações resilientes daquelas que correm maiores riscos já não é meramente “nosso código é seguro?”. A questão mais pertinente é: “sabemos exatamente que código, desenvolvido por quem, em qual versão e com quais dependências está operando sob nossa confiança neste exato momento?”. Empresas capazes de responder a essa pergunta conseguem reduzir significativamente o tempo de exposição a riscos, aceleram a capacidade de reação a incidentes, negociam de forma mais vantajosa com seus fornecedores e evitam que um componente obscuro se transforme em uma crise empresarial de grandes proporções. Aquelas que não conseguem, infelizmente, seguem apostando que o software invisível permanecerá invisível. Na área de segurança, esse tipo de aposta é invariavelmente cara.
