O que é SCA? O software moderno raramente é construído do zero. A maior parte do código que roda em produção hoje combina código proprietário com uma camada extensa de componentes de terceiros: bibliotecas open source, frameworks, utilitários e dependências gerenciadas via npm, Maven, PyPI, NuGet e similares. Essa prática é legítima, eficiente e praticamente universal no mercado.
O problema está na invisibilidade. Quando um time adiciona uma dependência ao projeto, raramente alguém mapeia o que aquela dependência traz consigo, quais são suas licenças, se ela está sendo mantida ativamente ou se possui vulnerabilidades conhecidas. Com o tempo, o software acumula um inventário de componentes que ninguém documenta com precisão, e esse inventário se torna um passivo.
É exatamente essa lacuna que o Software Composition Analysis (SCA) resolve. Neste artigo, explicamos o que é SCA, porque o uso de componentes open source introduz riscos que precisam ser gerenciados, como a Black Duck trata esse problema na prática, e o que as organizações brasileiras precisam considerar nesse contexto.
O que é SCA – Software Composition Analysis?
Software Composition Analysis é a disciplina de identificar, catalogar e analisar todos os componentes de terceiros presentes em uma aplicação. O foco principal recai sobre componentes open source, mas a prática se estende a qualquer código que não tenha sido escrito internamente: dependências comerciais, bibliotecas incorporadas diretamente ao repositório, snippets reutilizados e, cada vez mais, código produzido por assistentes de inteligência artificial.
O objetivo do SCA é responder, de forma automatizada e contínua, a perguntas que a maioria dos times não consegue responder hoje:
- Quais componentes estão efetivamente presentes no meu código, incluindo as dependências que ninguém declarou explicitamente?
- Algum deles possui vulnerabilidades conhecidas e exploráveis?
- As licenças desses componentes são compatíveis com o modelo de distribuição da minha empresa?
- Algum componente está abandonado, sem mantenedor ativo, ou rodando uma versão significativamente defasada?
A palavra “efetivamente” é importante. Ferramentas que analisam apenas arquivos de manifesto (como package.json ou pom.xml) enxergam somente o que foi declarado. Mas uma parcela relevante do open source presente em aplicações corporativas entra por outros caminhos: vendor code copiado diretamente para o repositório, binários incluídos sem o código-fonte correspondente, snippets extraídos de projetos externos, ou código sugerido por assistentes de IA cujo treinamento inclui projetos com licenças restritivas. Uma ferramenta SCA completa precisa ir além do manifesto.
Orefere assistir? Veja a versão em vídeo completa abaixo:
Por que componentes open source representam risco?
Existe um equívoco persistente nas equipes de segurança: tratar o código de terceiros como menos crítico do que o código proprietário. Na prática, ocorre o oposto. A maior parte da superfície de ataque de uma aplicação moderna não está no código que o time escreveu, mas no código que ele importou.
Vulnerabilidades conhecidas e não corrigidas
Componentes open source são públicos. Isso significa que as vulnerabilidades descobertas neles são documentadas publicamente, com detalhes técnicos disponíveis para qualquer pessoa. Uma vulnerabilidade em uma biblioteca amplamente utilizada pode afetar simultaneamente dezenas de milhares de aplicações ao redor do mundo, incluindo a sua, caso o componente não seja atualizado.
O desafio prático é que manter dependências atualizadas é mais difícil do que parece. Atualizações de versão frequentemente introduzem mudanças incompatíveis de API. Atualizar um componente pode conflitar com os requisitos de versão de outro, por exemplo. Cada atualização exige ciclos de teste. Em ambientes de entrega contínua, com dezenas de serviços e centenas de dependências, essa manutenção tende a ficar para segundo plano.
Dependências transitivas: o que você não escolheu
Quando um desenvolvedor adiciona uma biblioteca ao projeto, ela traz consigo as próprias dependências. Essas dependências têm as delas. O grafo de dependências de uma aplicação moderna cresce rapidamente, e a maior parte dos componentes presentes em produção nunca foi selecionada conscientemente pelo time de desenvolvimento.
Isso cria uma responsabilidade sem visibilidade. O time é responsável por tudo que roda em sua aplicação, mas não tem um inventário preciso do que está lá. Uma vulnerabilidade em uma dependência transitiva, três ou quatro níveis abaixo da dependência direta, pode ser tão explorável quanto uma no código principal.
Componentes abandonados e dívida de manutenção
Open source depende de contribuidores. Quando um projeto perde tração, fica sem financiamento ou o mantenedor para de contribuir, o código não desaparece dos registros de pacotes. Ele continua disponível para instalação, continua sendo importado por outras bibliotecas, e continua rodando em produção. O problema surge quando uma vulnerabilidade é descoberta nesse componente: não há ninguém para corrigi-la.
Esse tipo de componente, que existe e é usado mas não recebe manutenção ativa, representa um risco estrutural. Não basta saber que uma vulnerabilidade existe se não há caminho claro de remediação. O SCA precisa identificar não apenas vulnerabilidades, mas também o status de manutenção de cada componente, para que o time possa tomar decisões informadas: corrigir internamente, substituir por uma alternativa ativa, ou aceitar o risco conscientemente.
Ataques à cadeia de suprimentos de software
A segurança de uma aplicação não depende apenas do que o time de desenvolvimento faz internamente. Ela depende também das práticas de segurança dos mantenedores dos componentes que a aplicação utiliza. Um componente legítimo pode ser comprometido por um atacante que assume o controle da conta do mantenedor e publica uma versão maliciosa. Um nome de pacote popular pode ser imitado com pequenas variações tipográficas para induzir desenvolvedores a instalar código malicioso.
Esses ataques à cadeia de suprimentos de software têm se tornado mais sofisticados. A dificuldade é que o código malicioso frequentemente parece inofensivo em uma análise estática superficial. Ele pode ser ativado durante a instalação, ou condicionado a variáveis de ambiente específicas que indicam um alvo de interesse. Sem visibilidade contínua sobre o que está presente na base de código e sem inteligência atualizada sobre pacotes comprometidos, é impossível detectar esse tipo de comprometimento a tempo.
Risco de licenciamento e propriedade intelectual
Além disso, licenças open source não são equivalentes entre si. Elas variam de licenças permissivas, que permitem uso comercial com obrigações mínimas, até licenças copyleft fortes, que podem exigir que qualquer software derivado seja distribuído sob os mesmos termos da licença original e a empresa tenha que disponibilizar publicamente o seu código fonte. Para empresas que desenvolvem software proprietário, incorporar inadvertidamente um componente com licença GPL pode gerar obrigações jurídicas significativas.
Esse risco é agravado pelas dependências transitivas: o time pode escolher cuidadosamente as dependências diretas, mas não controla as licenças das dependências das dependências. Além disso, a proliferação de assistentes de IA para geração de código cria um problema adicional. O modelo não entende licenças. Ele gera código a partir de padrões aprendidos em repositórios públicos, sem registrar a proveniência. Um trecho gerado por IA pode ser estruturalmente idêntico a código de um projeto GPL, sem que nada na saída indique essa origem.
O que são os BDSAs (Black Duck Security Advisories)?
A principal fonte pública de vulnerabilidades de software é o National Vulnerability Database (NVD), que mantém o registro de CVEs (Common Vulnerabilities and Exposures). O NVD é um recurso valioso, mas apresenta duas limitações relevantes para equipes de AppSec: cobertura incompleta e latência na análise.
Muitas vulnerabilidades demoram de semanas até meses para serem processadas e publicadas no NVD desde o momento em que foram descobertas. Durante esse intervalo, a vulnerabilidade pode já estar sendo explorada em ataques ativos. Além disso, o NVD não cobre pacotes maliciosos, porque eles não recebem CVEs, e há classes de vulnerabilidades que circulam em bases de dados especializadas antes de chegarem ao NVD.
Os Black Duck Security Advisories (BDSAs) são avisos de segurança produzidos e curados pela equipe de pesquisa da Black Duck. Eles ampliam a cobertura do NVD em três dimensões:
- Velocidade: a Black Duck analisa e publica informações sobre vulnerabilidades significativamente antes do NVD, o que reduz a janela de exposição das organizações que utilizam a plataforma.
- Cobertura além do CVE: os BDSAs incluem vulnerabilidades que ainda não possuem CVE atribuído, além de informações de explorabilidade e orientações de remediação mais detalhadas do que as disponíveis no NVD.
- Pacotes maliciosos: a Black Duck cria BDSAs para pacotes maliciosos identificados em ecossistemas open source. Essa categoria de risco não tem cobertura no NVD, mas representa uma ameaça ativa para qualquer organização que consuma dependências de registros públicos como npm e PyPI.
A base por trás dos BDSAs é a Black Duck KnowledgeBase, construída ao longo de mais de 20 anos de curadoria contínua. Ela indexa mais de 10 milhões de projetos open source a partir de mais de 58.000 fontes (o GitHub é uma dessas fontes), rastreia mais de 3.000 licenças e mantém um repositório de mais de 317.000 vulnerabilidades documentadas – totalizando mais de 1.75 Petabyes de informações.
Como funciona a detecção automática de licenças e vulnerabilidades?
Uma solução SCA que analisa apenas arquivos de manifesto é insuficiente para aplicações corporativas. A Black Duck emprega quatro métodos de detecção complementares para garantir cobertura abrangente:
- Análise de dependências examina gerenciadores de pacotes e arquivos de manifesto para mapear as dependências declaradas. É o método mais direto e o ponto de partida de qualquer análise.
- CodePrint analysis compara arquivos contra a Black Duck KnowledgeBase usando impressões digitais de código, identificando componentes mesmo quando foram modificados, renomeados ou parcialmente integrados ao código proprietário.
- Análise de snippets identifica fragmentos de código que correspondem a projetos open source conhecidos. Isso é especialmente relevante para detectar código copiado manualmente de projetos externos, incluindo código sugerido por assistentes de IA, que não apareceria em nenhum manifesto.
- Análise binária inspeciona código compilado para identificar componentes open source mesmo quando o código-fonte não está disponível. Útil para dependências distribuídas como bibliotecas pré-compiladas.
Após a identificação, cada componente é cruzado com a KnowledgeBase para obter dados de vulnerabilidade (com informações de explorabilidade e guia de remediação), classificação de licença, avaliação de risco de conformidade e status de manutenção. O resultado é uma SBOM (Software Bill of Materials) super completa, que inclui dependências diretas e transitivas, e que pode ser exportada nos formatos CycloneDX e SPDX.
Black Duck SCA e Polaris: como funcionam na prática?
A Black Duck disponibiliza o SCA em dois formatos, adaptados a perfis operacionais distintos.
Black Duck SCA on-premises
Para organizações que precisam manter toda a análise dentro da própria infraestrutura, seja por exigência regulatória, política de segurança corporativa ou requisitos de soberania de dados, o Black Duck SCA on-premises é a opção mais adequada.
A plataforma se integra com os principais repositórios de código, ferramentas de CI/CD (Jenkins, Azure DevOps, GitHub Actions, GitLab CI) e sistemas de gestão de issues (Jira, ServiceNow). As políticas de aprovação e bloqueio são configuráveis por severidade, tipo de licença, dados do componentes, das vulnerabilidades e status de manutenção do componente. A inteligência de vulnerabilidade é atualizada regularmente a partir da KnowledgeBase, mantida localmente.
Polaris: SCA em formato SaaS
O Polaris é a plataforma SaaS da Black Duck para Application Security Testing. Ele consolida em um único ambiente: análise estática de código (SAST), SCA, análise dinâmica (DAST), detecção de segredos expostos e segurança de Infrastructure-as-Code (IaC).
O módulo SCA do Polaris utiliza a mesma KnowledgeBase e os mesmos BDSAs da versão on-premises, sem exigir infraestrutura própria. As atualizações de vulnerabilidades e licenças são automáticas. Os dashboards unificados permitem que o time de AppSec visualize o risco de toda a organização em um único painel, com rastreabilidade por produto, equipe e severidade.
Para times que precisam implementar SCA rapidamente sem investimento em infraestrutura, o Polaris é o caminho mais direto. Para organizações com requisitos estritos de isolamento de dados, o Black Duck SCA on-premises oferece a mesma profundidade de análise dentro do perímetro corporativo.
Integração ao ciclo de desenvolvimento
Ambas as soluções se integram ao fluxo de trabalho onde o time já opera:
- IDEs: o plugin Code Sight exibe alertas de vulnerabilidade e licença em tempo real enquanto o desenvolvedor escreve o código, antes mesmo do commit.
- Pull Requests: resultados de análise aparecem diretamente nas revisões de código no GitHub, GitLab e Azure DevOps.
- CI/CD: políticas configuráveis podem bloquear builds ou deploys que violem critérios pré-definidos de segurança ou conformidade.
- ASPM: integração com o SRM (Software Risk Manager) oferece visão executiva consolidada de risco de aplicação em toda a organização.
Conheça mais sobre as soluções Black Duck.
SCA no contexto brasileiro: LGPD e CMN 4.893
O Brasil não possui uma regulação específica para segurança de software comparável ao EU Cyber Resilience Act europeu, mas o quadro normativo vigente já impõe obrigações que tornam o SCA relevante do ponto de vista de conformidade.
A Resolução CMN 4.893 do Banco Central exige que instituições financeiras mantenham uma política de segurança cibernética que inclua a gestão de riscos em serviços de terceiros e na cadeia de fornecimento de tecnologia. Componentes open source são, na prática, fornecedores de tecnologia. Sem um inventário preciso e uma análise contínua dessas dependências, é impossível demonstrar a gestão de risco exigida pela norma.
A LGPD, por sua vez, responsabiliza os controladores de dados por incidentes que resultem de negligência técnica. Uma vulnerabilidade conhecida em um componente open source, não identificada porque a organização não possui uma ferramenta SCA, é um exemplo direto de negligência que pode fundamentar responsabilidade em caso de vazamento de dados pessoais.
Para o time técnico, o SCA é a ferramenta de visibilidade. Para o CISO, é a evidência de due diligence. Para o jurídico e o compliance, é a documentação de que a organização está gerenciando ativamente os riscos de sua cadeia de fornecimento de software.
Conclusão
Open source é, e continuará sendo, parte fundamental do desenvolvimento de software moderno. O objetivo do SCA não é restringir o uso de componentes de terceiros, mas garantir que esse uso seja feito com visibilidade e controle adequados.
Saber o que está no seu software, quais vulnerabilidades existem, quais licenças se aplicam e quais componentes não estão mais sendo mantidos não é uma questão de boas práticas opcionais. É o mínimo necessário para gerenciar um ativo de software de forma responsável.
O Black Duck, com a profundidade da sua KnowledgeBase, a cobertura dos BDSAs e a capacidade de análise multifatorial que vai além dos manifests, oferece esse nível de visibilidade. Tanto em formato on-premises, para organizações com requisitos de isolamento, quanto via Polaris, para times que precisam de agilidade de implantação.
Quer entender como o Black Duck SCA ou o Polaris se aplicam ao contexto da sua organização?
A FCBR é parceira oficial Black Duck no Brasil desde 2017. Cuidamos de todo o processo de licenciamento, prova de conceito, implementação, treinamento e suporte, tudo em português e diretamente do Brasil, com mais oito anos de experiência e tendo trabalhado com empresas de diversos setores e tamanhos no Brasil.
Entre em contato: contato@fcbr.com.br | fcbr.com.br/contato | +55 11 95117-6020