Você Controla o Que Compõe Seu Produto? Como e Por Que Realizar Análise de Código Aberto

Olá! Meu nome é Ruslan, sou engenheiro no departamento de desenvolvimento de processos de segurança da YADRO. Hoje, vamos falar sobre código aberto (open source). No mundo do desenvolvimento moderno, ele é usado em quase todos os aplicativos: bibliotecas, frameworks e componentes open source ajudam a acelerar o desenvolvimento e torná-lo muito mais conveniente.

Mas há um problema: cada dependência não é apenas "vantagens", mas também riscos adicionais. Se uma vulnerabilidade aparecer no open source que você usa, você terá que corrigi-la com urgência - e dificilmente levará alguns minutos. Há também riscos legais - por exemplo, o autor do open source pode enviar uma solicitação para divulgar a parte do código que você modificou, e isso pode ser informações confidenciais para você. Como resultado, você não poderá fornecer parte do código, e a outra parte terá o direito total de ir ao tribunal.

A Análise de Código Aberto (Open Source Analysis, OSA) ajuda a evitar esses riscos. Vamos descobrir o que é e como executá-la.

Open Source - Tanto Risco Quanto Benefício

De acordo com o relatório Census III of Free and Open Source Software, de 70 a 96% do código em aplicativos modernos são componentes open source. Um serviço comum arrasta centenas de dependências transitivas para o projeto, das quais o desenvolvedor pode nem estar ciente.

Isso acarreta problemas:

• Uma vulnerabilidade que pode estar em uma biblioteca open source se torna uma vulnerabilidade do seu aplicativo.
• Os usuários confiam seus dados a você e esperam a segurança de seus serviços. Eles interagem com seu aplicativo, não diretamente com uma biblioteca separada. Quando ocorre um vazamento de dados ou um ataque, é você quem assume os riscos de reputação e legais. Adicione a isso possíveis perdas financeiras e a variedade de ataques - desde o roubo de dados até a introdução de código malicioso e o controle do sistema. E há também as "bombas dormentes": você pode não saber sobre a vulnerabilidade por anos, até que os invasores encontrem uma maneira de explorá-la. Poderíamos continuar assustando por muito tempo, mas vamos para o próximo ponto.
• A atualização de uma dependência geralmente precisa ser adiada "para mais tarde", porque primeiro você precisa verificar se ela não vai quebrar o aplicativo.
• Atualizações adiadas levam ao acúmulo de dívida técnica. Além disso, você pode continuar a usar código com vulnerabilidades já conhecidas e se privar de novas funções úteis que os desenvolvedores adicionaram.
• Você pode violar acidentalmente o contrato de licença.
• Infelizmente, as licenças de open source geralmente são lidas depois que a biblioteca é adicionada ao produto, ou não são lidas de forma alguma. Isso ameaça a empresa com ações judiciais, processos subsequentes e possíveis multas.

Como escrevi acima, a Análise de Código Aberto ajuda a evitar esses problemas. Acredito que ela deve se tornar uma prática comum - vamos falar sobre isso a seguir.

Quais tarefas a Análise de Código Aberto resolve

Vamos começar com o básico.

Open Source Analysis (OSA) é a análise de componentes open source que são usados em um aplicativo. A tarefa dessa análise é responder à pergunta:

"Quais riscos herdamos ao conectar outra biblioteca?"

A OSA se concentra em vários aspectos: vulnerabilidades, licenças, relevância e suporte de componentes, riscos para a cadeia de suprimentos (Supply Chain). Muitas vezes é usado com análise de composição (SCA). A combinação dessas práticas ajuda a avaliar a segurança do uso de open source de forma abrangente.

Com quais tarefas específicas a OSA ajuda:

1. Encontrar vulnerabilidades - incidentes que já aconteceram.

Com a OSA, você identifica oportunamente vulnerabilidades em componentes abertos que podem levar a incidentes graves.

Como exemplo, sugiro que você se lembre do Log4Shell (CVE-2021-44228) - uma das vulnerabilidades mais significativas dos últimos anos. Essa vulnerabilidade RCE (Remote Code Execution) permitiu que invasores executassem código arbitrário em um servidor atacado por meio de uma simples solicitação de texto. Incidentes foram registrados em todo o mundo, e os desenvolvedores tiveram que lançar patches de emergência e desativar serviços. Depois desse caso, muitas empresas de desenvolvimento se perguntaram pela primeira vez se usavam Log4j em seus produtos. Aqueles que já tinham um processo de OSA construído foram capazes de responder a essa pergunta muito rapidamente. Outros gastaram dias e semanas.

E mais alguns exemplos:

• XZ Utils Backdoor (CVE-2024-3094). Em março de 2024, tornou-se conhecido sobre a vulnerabilidade sob o codinome "XZ backdoor". Foi descoberto acidentalmente nas populares bibliotecas de compactação de dados XZ (liblzma). Qual foi a razão? O mantenedor não pôde mais se envolver no projeto e transferiu os direitos para um usuário de iniciativa, que acabou sendo o invasor. O resultado é um Supply Chain Attack, um backdoor incorporado no liblzma (xz-utils). Todos os modernos distribuições Linux foram afetadas - Debian, Fedora, Ubuntu e outros. O caso destacou a vulnerabilidade de projetos com um único mantenedor.
• Trivy (CVE-2026-33634). Em março de 2026, o grupo TeamPCP implementou um ataque semelhante ao "efeito dominó", comprometendo vários projetos open source um após o outro. Primeiro, os hackers invadiram o Trivy - um popular scanner de vulnerabilidades usado em pipelines CI/CD. Eles introduziram código malicioso que roubava senhas e chaves de API diretamente durante a operação. Os tokens de acesso roubados dos usuários do Trivy foram usados para atacar o próximo alvo - a biblioteca para trabalhar com IA LiteLLM. Os invasores conseguiram publicar duas versões de pacote infectadas no PyPI em nome dos desenvolvedores. O código malicioso no LiteLLM foi oculto em um arquivo .pth. Esse arquivo é executado automaticamente no início do interpretador Python, o que significa que nem mesmo era necessário chamar explicitamente a biblioteca no código para a infecção. O caso com Trivy é um exemplo vívido de um ataque de vários níveis à cadeia de suprimentos (Supply Chain Attack).
• Axios (CVE-2026-40175). Em março de 2026, Axios - uma das bibliotecas JavaScript mais populares para solicitações HTTP - foi atacada. Os invasores não invadiram diretamente o repositório GitHub - eles usaram engenharia social complexa para obter acesso ao computador do principal desenvolvedor do projeto. Os hackers entraram em contato com ele, fingindo ser funcionários de uma empresa de tecnologia, e o convidaram para uma reunião online. Quando o desenvolvedor tentou se conectar, foi-lhe oferecido para instalar uma "atualização" para o programa de videoconferência, que na verdade acabou sendo um cavalo de Troia de acesso remoto (RAT). Tendo assumido o controle do computador do mantenedor, os hackers publicaram versões maliciosas do Axios no registro npm. Ao instalar, essas versões executaram um cavalo de Troia multiplataforma que roubava credenciais e dava acesso oculto ao sistema.

1. Identificar ataques à cadeia de suprimentos (Supply Chain Attacks).

Isso não é mais teoria, mas prática: os invasores os usam ativamente. Exemplos:

• Carregamento de pacotes substituídos de repositórios públicos (Dependency Confusion);
• Comprometimento de contas de mantenedores de projetos;
• Introdução de código malicioso em atualizações.

Com a ajuda da OSA, você pode descobrir onde está a fonte da dependência e quem e como a mantém.

1. Gerenciar riscos de licença já no estágio de desenvolvimento.

Um exemplo simples da prática. O produto já está pronto para lançamento, mas no estágio de verificação para entrega, de repente, fica claro que ele tem componentes distribuídos sob a licença GPL, e ela exige a divulgação do código-fonte do produto. Nessa situação, resta refazer o produto com urgência, transferir o lançamento e se preparar para uma possível perda de cliente.

A OSA permite tomar decisões de forma planejada. Durante a análise, as licenças dos componentes open source são verificadas. Se as licenças copyleft forem encontradas, uma substituição com condições mais "amigáveis" poderá ser encontrada para esses componentes open source.

Com a teoria clara, mas como essa análise se parece na prática?

Como a Análise de Código Aberto é conduzida

Passo um: inventário e SBOM.

A tarefa é entender quais componentes são usados no produto. Para isso, um Software Bill of Materials (SBOM) é formado. Os arquivos de manifesto (package.json, pom.xml), arquivos de bloqueio (package-lock.json) e imagens de contêiner são analisados. Como resultado, você obtém uma lista de dependências diretas e transitivas, indicando suas versões.

Passo dois: pesquisa e avaliação de vulnerabilidades conhecidas.

Todas as dependências são comparadas com bancos de dados de vulnerabilidades conhecidos - por exemplo, BDU FSTEC, NVD, CVE, GitHub Security Advisories. Se uma vulnerabilidade for detectada durante a verificação, um Application Security Engineer a analisa, determina se ela pode ser explorada por um invasor e filtra os falsos positivos dos scanners.

Passo três: análise de licenças.

Na maioria dos casos, as empresas têm uma política de uso de licenças: licenças permitidas (MIT, BSD, Apache 2.0), condicionalmente permitidas (LGPL), proibidas (GPL/AGPL). A OSA ajuda a identificar possíveis conflitos e faz você pensar em como usar, distribuir e modificar legalmente componentes open source em seu projeto.

Passo quatro: avaliação do suporte de componentes.

Ao escolher novos componentes, é importante avaliar não apenas as vulnerabilidades, mas também o suporte: quando a última versão foi lançada, quantos contribuidores ativos há no componente, se os desenvolvedores rastreiam as vulnerabilidades nas dependências de seu aplicativo e com que rapidez eles reagem aos problemas de segurança em seu produto. Uma biblioteca abandonada ou arquivada é um risco potencial de segurança.

Passo cinco: integração no CI/CD.

A aplicação da OSA na equipe pode ser desenvolvida:

• Executando automaticamente em cada compilação do produto;
• Bloqueando a compilação do produto se vulnerabilidades de nível crítico e alto forem encontradas;
• Garantindo monitoramento constante e atualização das dependências existentes.

Como resultado, a integração da OSA no CI/CD permite automatizar verificações manuais e economizar o tempo de trabalho dos engenheiros.

A análise pode ser realizada com a ajuda de um grande número de ferramentas - tanto comerciais quanto open source. Entre elas: OWASP Dependency-Check, OWASP Dependency-Track, Snyk, Trivy, Code Scoring, GitHub Dependabot / Security Advisories. Qual ferramenta escolher depende do nível da empresa, da maturidade dos processos de desenvolvimento seguro, dos requisitos de licenciamento, do orçamento alocado e dos objetivos da equipe. Mas para começar a aplicar essa prática, ferramentas open source são suficientes.

Como conclusão, resumirei que a OSA dá ao desenvolvedor:

• Transparência da composição dos componentes que são usados no aplicativo;
• Compreensão do potencial vetor de ataque ao aplicativo em desenvolvimento;
• A capacidade de reagir rapidamente a novas vulnerabilidades;
• A capacidade de gerenciar riscos de licença;
• Alto nível de segurança do produto em desenvolvimento.

Das listadas, as vantagens competitivas decorrem: você reduz a probabilidade de ataques e tempo de inatividade do equipamento, o que os incidentes poderiam levar. Portanto, a Análise de Código Aberto é uma prática de engenharia necessária. Essa análise ajuda a responder honestamente à pergunta: "Quão bem você realmente controla o que compõe seu produto?"

É claro que a implementação da OSA requer tempo e recursos - por exemplo, você definitivamente precisará de sessões regulares de conscientização com as equipes de desenvolvimento. Mas os esforços não serão em vão: da próxima vez, em vez de usar uma biblioteca open source com uma licença inadequada, os desenvolvedores escolherão imediatamente uma substituição ou pensarão na possibilidade de escrever um componente por conta própria. E, portanto, não haverá necessidade de resolver as consequências desagradáveis.