Pular para o conteúdo principal

Software Composition Analysis

Pense no desenvolvimento de software hoje em dia como construir algo com blocos de LEGO. Em vez de fabricar cada pequeno bloco do zero, você usa blocos prontos (componentes de código aberto, bibliotecas, frameworks) para montar sua aplicação muito mais rápido.

O SCA é, essencialmente, a ferramenta que analisa todos esses blocos de LEGO que você usou para garantir que eles não tenham defeitos perigosos.

Análise de Composição de Software (SCA) é um processo automatizado que identifica os componentes de software de código aberto (open source) em uma base de código. O objetivo principal é avaliar esses componentes para encontrar vulnerabilidades de segurança, problemas de conformidade de licença e analisar a qualidade geral do código que você está "importando" para o seu projeto.

Estima-se que entre 80% e 90% do código em aplicações modernas seja de código aberto. Ao importar bibliotecas de código aberto, as vulnerabilidades contidas nelas passam a ser suas também

  • Vulnerabilidades Herdadas: Se você usa uma biblioteca vulnerável, sua aplicação se torna vulnerável. O exemplo mais famoso e recente foi a vulnerabilidade Log4Shell (CVE-2021-44228) na biblioteca Java Log4j. Empresas no mundo todo entraram em pânico para descobrir se e onde usavam essa biblioteca. Ferramentas de SCA foram essenciais para essa identificação rápida.
  • Dependências Transitivas: A biblioteca que você adiciona (dependência direta) pode depender de outras dez bibliotecas (dependências transitivas). Uma vulnerabilidade em qualquer uma delas afeta você, mesmo que você nunca tenha ouvido falar daquele pacote. O SCA mapeia toda essa árvore de dependências.
  • Conformidade de Licenças: Componentes de código aberto vêm com licenças (MIT, Apache, GPL, etc.). Algumas dessas licenças têm restrições sobre como você pode usar o código, especialmente em produtos comerciais. O uso indevido pode levar a problemas legais sérios. O SCA verifica essas licenças e alerta sobre conflitos.

O Processo​

  1. Escaneamento (Scan): A ferramenta analisa os arquivos de manifesto do seu projeto (como package.json em Node.js, pom.xml em Java/Maven, requirements.txt em Python, etc.). Esses arquivos declaram as dependências diretas do projeto.

  2. Identificação e Mapeamento: A ferramenta constrói um inventário completo de todos os componentes, incluindo as dependências transitivas. O resultado dessa etapa é, idealmente, um SBOM (Software Bill of Materials).

  3. Análise de Vulnerabilidades: Cada componente identificado é comparado com bancos de dados de vulnerabilidades conhecidas, como o NVD (National Vulnerability Database), GitHub Advisories, e bancos de dados privados da própria ferramenta. Ele busca por CVEs (Common Vulnerabilities and Exposures) associados àquela versão específica do componente.

  4. Análise de Licenças: As licenças de cada componente são identificadas e comparadas com as políticas definidas pela sua empresa para garantir a conformidade.

  5. Relatório e Alertas: A ferramenta gera um relatório detalhado com:

    • Lista de componentes vulneráveis.
    • A severidade de cada vulnerabilidade (geralmente usando o score CVSS, ou Common Vulnerability Scoring System).
    • Informações sobre como corrigir (ex: "atualize a biblioteca X da versão 1.2.3 para 1.2.5").
    • Alertas sobre licenças incompatíveis.

Principais Benefícios do SCA no SDLC​

  • Visibilidade: Você finalmente sabe o que está dentro do seu código.
  • Segurança "Shift-Left": Ao integrar o SCA nas fases iniciais do desenvolvimento (no ambiente do desenvolvedor, no repositório de código), você encontra e corrige problemas de segurança mais cedo, quando são mais fáceis e baratos de resolver. Isso é um pilar do DevSecOps.
  • Redução de Risco: Evita que vulnerabilidades conhecidas cheguem à produção.
  • Velocidade: Permite que as equipes de desenvolvimento usem componentes de código aberto com confiança, sem retardar o processo de inovação.
  • Compliance: Garante a conformidade com as licenças de software e com regulações de segurança.

Ferramentas Populares de SCA​

Existem diversas ferramentas no mercado, tanto comerciais quanto de código aberto:

Comerciais:

  • Snyk Open Source: Muito popular entre desenvolvedores pela sua integração e facilidade de uso.
  • Veracode Software Composition Analysis: Parte de uma suíte de segurança de aplicações mais ampla.
  • Sonatype Nexus Lifecycle: Focado em governança de componentes em todo o ciclo de vida.
  • Checkmarx SCA (antigo CxSCA): Integrado com a solução de SAST (Static Application Security Testing) da Checkmarx.
  • Sonarqube: Oferece SCA nativo a partir de suas edições pagas (Developer Edition em diante). A edição Community gratuita foca em análise de código estático (SAST).

Código Aberto (Open Source):

  • OWASP Dependency-Check: Uma ferramenta clássica e amplamente utilizada que pode ser integrada em pipelines de CI/CD.
  • Trivy: Uma ferramenta versátil que, além de contêineres, também pode escanear dependências de aplicações. Já temos documentação sobre ela aqui no site.

SBOM (Software Bill of Materials)​

O SBOM é um resultado direto e crucial do processo de SCA. Fazendo uma excelente analogia com o ecossistema Node.js, o SBOM é como se fosse um package-lock.json portátil e agnóstico de linguagem.

Enquanto o package-lock.json descreve a árvore de dependências exata para um projeto Node.js, um SBOM faz o mesmo de forma padronizada (usando formatos como CycloneDX ou SPDX) para qualquer tipo de software. Ele é, literalmente, uma "lista de ingredientes" formal e estruturada de todos os componentes que formam uma aplicação.

O grande poder de um arquivo SBOM está em sua portabilidade, permitindo que ele seja usado como fonte de dados para diversas ferramentas de segurança. Por exemplo, o Trivy pode tanto gerar um SBOM a partir de um projeto, quanto analisar um SBOM já existente em busca de vulnerabilidades. Dessa forma, um inventário gerado por uma ferramenta pode ser consumido por outra, como o OWASP Dependency-Check, otimizando o processo de análise.

É fundamental entender que o SBOM é o inventário de componentes, não o relatório de vulnerabilidades. No entanto, é com base nesse inventário preciso que podemos gerar relatórios de riscos, analisar o impacto de novas ameaças e, crucialmente, gerenciar a conformidade de licenças.

Nesse contexto, o SBOM torna-se a melhor ferramenta moderna para o disclosure de licenças. A tarefa de verificar a conformidade legal deixa de ser um processo manual e se torna uma análise automatizada sobre um artefato de engenharia. Embora não exista uma lei universal que obrigue toda empresa a fazer o disclosure de seus componentes em todos os casos, isso já é uma exigência em muitos contratos B2B e para a venda de software para setores governamentais, tornando o SBOM uma necessidade de negócio.