O uso de bibliotecas de código aberto é uma prática consolidada no desenvolvimento de software. Essa estratégia permite acelerar o tempo de entrega, aproveitar funcionalidades já testadas pela comunidade e reduzir custos de desenvolvimento, evitando reinventar soluções que já existem.
E cada vez mais as bibliotecas vêm sendo utilizadas para acelerar o desenvolvimento de novas features. Dados do relatório State of the Software Supply Chain Report 2024, da Sonatype, mostram que 6,6 trilhões de downloads de software de código aberto foram feitos em 2024. E segundo o estudo, até 90% de uma aplicação moderna é composta por componentes OSS (bibliotecas). Consequentemente, foi detectado um aumento de 156% apenas de pacotes maliciosos no periodo de um ano (cerca de 512 mil).
A famosa biblioteca Log4j, ainda recebe 13% de seus downloads totais nas versões vulneráveis pelos CVEs conhecidos, mesmo após três anos do incidente Log4Shell.
Já no relatório anual da Veracode, o State of Software Security 2025, mais de 1,3 milhão de aplicações foram analisadas e 126,4 milhões de vulnerabilidades foram detectadas durante as análises. O estudo constatou que cerca de 80% das aplicações testadas continham ao menos uma falha de segurança (vulnerabilidade), sendo que 56% tinham vulnerabilidades altas ou críticas, considerando a combinação dos tipos de análise SAST, DAST e SCA. Isso significa que mais da metade das aplicações analisadas apresentam riscos significativos à segurança.
Mais achados relevantes
Um dos pontos principais levantados no estudo foi a “security debt”, ou “dívida de segurança”. Elas são vulnerabilidades que permanecem sem correção por longos períodos, acumulando riscos enormes ao longo do tempo. Em 2025, 74% das organizações carregam algum nível dessa “dívida”, e metade delas enfrenta o cenário mais preocupante: vulnerabilidades críticas não corrigidas há mais de um ano. Para piorar, o tempo médio para corrigir falhas cresceu 47% desde 2020, passando de 171 para 252 dias.
Outro achado relevante está no código de terceiros, especialmente bibliotecas open source (OSS). Embora apenas 11% da “dívida” venha de dependências externas, o impacto é muito mais grave quando se trata de falhas críticas: 70% estão ligados a componentes de terceiros. Isso mostra que a software supply chain é hoje um dos pontos mais vulneráveis na criação de aplicações modernas.
A melhor forma de sanitizar as ameaças do top 6 global de vulnerabilidades de aplicações, que são as vulnerabilidades em open sources, é realizar uma gestão proativa de dependências diretas e transitivas. Isso equivale tanto a ter uma solução de SCA (Software Composition Analysis) integrada nas IDEs e nas esteiras de desenvolvimento, quanto realizar uma gestão do SBOM (Software Bill of Materials) dos projetos. Segundo o estudo da Sonatype, realizar uma gestão de SBOMs pode reduzir em até 264 dias o tempo médio de correção das vulnerabilidades e falhas causadas pelo uso irregular de bibliotecas.
Quais são as principais vulnerabilidades em aplicações?
Diante desse cenário, é fundamental conhecer algumas das principais vulnerabilidades que afetam nossas aplicações web. Dentre elas, podemos destacar as seguintes:
1. Security Misconfiguration
São configurações incorretas ou negligenciadas, padrões fracos de configurações, que permitem a exploração de vulnerabilidades mesmo sem um “bug de código”.
Nesse tipo de falha, o atacante pode explorar diversos caminhos, como:
- Configuração insegura de diretório: a opção directory listing habilitada no servidor permite que qualquer usuário veja e baixe arquivos que não deveriam estar públicos;
- Exposição de informações sensíveis: a versão do servidor web é revelada, aumentando a superfície de ataque (o atacante pode buscar CVEs específicas em poucos minutos);
- Falta de hardening: quando não há aplicação de boas práticas, como desabilitar listagem, restringir acesso, ou headers de segurança.
2. SQL Injection
Ocorre quando uma aplicação não valida ou sanitiza corretamente a entrada de dados do usuário e essa entrada é usada diretamente em consultas SQL.
Isso permite que o atacante injete comandos maliciosos na query para manipular o banco de dados. As consequências podem variar de bypass de autenticação até exclusão de registros.
Ataques de SQL Injection podem contemplar:
- Bypass de autenticação (login sem senha);
- Exfiltração de dados sensíveis (dados de clientes, cartões, senhas);
- Modificação ou exclusão de dados (DROP TABLE, UPDATE).
- Escalada de privilégios (ganhar acesso de admin);
- Além disso, até mesmo a destruição de evidências e logs para cobrir os rastros deixados após o ataque à aplicação/banco de dados.
3. Command Injection
Ocorre quando uma aplicação pega dados fornecidos pelo usuário e os utiliza diretamente em comandos do sistema operacional (shell), sem validação.
Isso permite que o atacante injete comandos maliciosos. Nesse tipo de falha, ele pode realizar:
- Exfiltração de informações sensíveis (ex.: arquivos do sistema);
- Execução de comandos arbitrários (criar arquivos, instalar backdoors);
- Escalada de privilégios;
- Tomada de controle total do servidor.
4. Vulnerable and Outdated Components
Esse tipo de vulnerabilidade está ligado a bibliotecas, frameworks, plugins, imagens de container, pacotes do sistema ou qualquer dependência usada pela aplicação que contém falhas conhecidas (CVE) ou que não recebe manutenção/patches. Esses componentes podem estar diretamente referenciados pelo projeto (dependências diretas) ou inseridos indiretamente via dependências de dependências (dependências transitivas).
Esse tipo de vulnerabilidade pode permitir com que o atacante:
- Execute RCEs, caso uma biblioteca utilizada tenha CVEs cadastradas que permitam isso;
- Backdoors: componentes ou pacotes maliciosos introduzidos propositalmente vulnerabilidades deste tipo;
- Escalada de privilégios: bugs em componentes que rodem com permissões elevadas podem ser usados para subir de nível e controlar recursos críticos;
- Impacto regulatório e reputacional: exploração de componentes conhecidos pode gerar vazamento de dados que acarretam multas, sanções e perda de confiança de clientes/parceiros.
RedTalks: Hands-on Security
No RedTalks “Hands-on Security: explorando e corrigindo vulnerabilidades”, segundo webinar da Trilha de DevSecOps,mostramos como funcionam essas vulnerabilidades, como podem ser exploradas por atacantes – e como corrigi-las.
A Redbelt Security pode apoiar sua empresa na implementação de práticas de DevSecOps, integrando segurança ao ciclo de desenvolvimento sem comprometer a agilidade das entregas. Solicite agora o contato com um de nossos especialistas.
Julio Raveli – Consultor DevSecOps III
