O que é análise de composição de software (SCA)?

As ferramentas de SCA operam verificando o código-fonte do software, coletando-o em um banco de dados, comparando-o com bancos de dados de vulnerabilidades conhecidas, verificando atualizações ou problemas de licenciamento e, em seguida, produzindo um relatório. 

Embora a análise de composição de software possa verificar todos os tipos de elementos de software, incluindo componentes proprietários e imagens de contêineres, ela é mais comumente utilizada para analisar bibliotecas de código aberto. Componentes de código aberto estão incluídos, até certo ponto, em quase todas as bases de código modernas. E, como as vulnerabilidades em seu código são de conhecimento público, é especialmente importante manter o software de código aberto atualizado e transparente.

As ferramentas de SCA gerenciam os riscos de vulnerabilidades de segurança de componentes de software de origem desconhecida, problemas de compatibilidade entre diferentes licenças de código aberto e documentação ou suporte incompletos ou insuficientes para bibliotecas de código aberto.  

A análise de composição de software faz parte do pipeline de DevOps nativo da nuvem que integra o processo de desenvolvimento de software às operações de TI. A SCA também é compatível com a postura de segurança da organização como parte do pipeline de DevSecOps, que integra segurança com desenvolvimento e operações. As ferramentas de SCA podem ser implementadas em um ambiente de desenvolvimento integrado (IDE), oferecendo análise de código em tempo real durante o processo de desenvolvimento.

A SCA difere de outras formas de verificação de vulnerabilidades, como testes estáticos de segurança de aplicações (SAST), testes dinâmicos de segurança de aplicações (DAST) e verificação de dependências.

As equipes de TI geralmente usam ferramentas de SCA para gerar uma lista de materiais de software (SBOM). A SBOM lista todos os componentes, bibliotecas e módulos em um produto de software em um formato legível por máquina para conformidade e segurança da cadeia de suprimentos. As SBOMs também podem informar ainda mais as políticas de verificação da SCA.

De acordo com dados de uma pesquisa da International Data Corporation, 93% das empresas com pelo menos 100 funcionários usaram software de código aberto em 2024, o que destaca a necessidade generalizada de soluções de SCA.¹

A SCA trabalha coletando código-fonte, comparando-o com bancos de dados de vulnerabilidades, analisando a base de código para possíveis problemas de conformidade, removendo falsos positivos e criando um relatório para equipes de cibersegurança e desenvolvimento. 

As ferramentas de SCA verificam e analisam ativamente o código durante o desenvolvimento como parte do pipeline de integração e entrega contínuas (CI/CD) em todo o ciclo de vida do desenvolvimento, focando principalmente em componentes de código aberto e dependências de terceiros.

Para fazer isso, as ferramentas de SCA listam primeiro os elementos básicos de todo o software no ambiente de TI, incluindo seus componentes, frameworks, bibliotecas, imagens de contêineres, módulos e dependências. As duas formas principais de verificação de SCA são: 

• Verificação estática ou de manifesto, que lê arquivos de configuração e metadados para encontrar os elementos explicitamente descritos lá.

• Verificação dinâmica, ou de tempo de execução, que identifica as bibliotecas conforme elas são executadas em tempo real por meio da verificação do código binário. 

Ambos os tipos de verificações têm vantagens e desvantagens. Uma verificação estática pode incluir vulnerabilidades de componentes de terceiros no código-fonte que não estão realmente implementados no ambiente de tempo de execução, criando falsos positivos. Uma verificação dinâmica, por outro lado, pode nunca ser completamente completa, pois nem todos os elementos do código são executados no ambiente de tempo de execução. Muitas organizações usam uma combinação de ambas.

Depois que uma ferramenta de SCA termina de coletar o código, ela cria uma lista de materiais de software (SBOM) e compara os componentes da SBOM com bancos de dados que descrevem vulnerabilidades comuns e riscos de segurança de software modernos.

As equipes de segurança comparam a SBOM tanto com bancos de dados proprietários de vulnerabilidades de segurança conhecidas quanto com bancos de dados públicos, como o National Vulnerability Database (NVD) ou a lista Vulnerabilidades e exposições comuns (CVE) . Uma vez sinalizadas as possíveis vulnerabilidades, a ferramenta de SCA atribui a cada uma delas uma pontuação de ameaça (geralmente usando o Common Vulnerability Scoring System, ou CVSS), que permite à equipe de cibersegurança priorizar a remediação.

Algumas ferramentas de segurança automatizam o gerenciamento de vulnerabilidades aplicando a correção ou atualização apropriada como parte do pipeline de CI/CD. As equipes de segurança normalmente monitoram esse processo para garantir que as alterações aplicadas não afetem as dependências ou funcionalidades existentes.

As ferramentas de SCA também verificam a SBOM em relação às políticas e leis da empresa sobre licenciamento de software para garantir a conformidade.

A Iniciativa de Código Aberto lista mais de 100 licenças de código aberto aprovadas, algumas das quais permitem a criação de produtos proprietários a partir de código aberto. No entanto, nem todos são compatíveis, o que significa que as organizações são responsáveis por garantir que seus produtos estejam em conformidade.

As soluções de SCA podem verificar se todo software de código aberto carrega a atribuição necessária, ou que elementos sujeitos a "copyleft" (que proíbe seu uso em software proprietário e protegido por direitos autorais) não estão incluídos no desenvolvimento desse software. 

A análise de composição de software também pode detectar dependências entre componentes do projeto, uma fonte importante de vulnerabilidades potenciais.

As ferramentas de SCA podem detectar tanto dependências diretas (onde os componentes de software são usados diretamente uns pelos outros no nível de código) quanto dependências transitivas. Uma dependência transitiva ocorre quando um software se torna indiretamente dependente de um componente de software do qual uma de suas dependências diretas depende. Por exemplo: o componente A depende do componente B, que é dependente do componente C. Nesse cenário, o componente A é transitivamente dependente do componente C.

As ferramentas de SCA devem determinar quais dependências introduzem vulnerabilidades e quais não, para reduzir o número de alertas falsos. Eles fazem isso avaliando a cadeia de suprimentos de software e determinando se uma vulnerabilidade no código é "alcançável", ou seja, se ela será chamada em um ambiente de tempo de execução, dada a configuração atual da rede. 

Os resultados da análise de composição de software são, então, compilados em um relatório e, muitas vezes, apresentados em um dashboard proprietário, dados brutos, como um arquivo JSON, uma nova SBOM ou alguma combinação de todos os três.

Nos últimos anos, os desenvolvedores fizeram avanços na redução de falsos positivos nesses relatórios.

• A análise de método vulnerável rastreia os caminhos de chamada dos componentes de software para garantir que as vulnerabilidades detectadas sejam alcançáveis.

• O aprendizado de máquina e a inteligência artificial contribuíram para a identificação de falsos positivos. Com o treinamento certo, os modelos podem identificar com precisão se uma vulnerabilidade é alcançável ou não. O processamento de linguagem natural também é usado para analisar mensagens de commit de controle de versão de repositórios como o GitHub, para detectar possíveis problemas não identificáveis no código. 

Algumas ferramentas de SCA incluem monitoramento contínuo e funcionalidades de remediação automática, que integram ainda mais a prática ao fluxo de trabalho de desenvolvimento de DevSecOps. A remediação automática é comumente feita iniciando solicitações de pull que notificam os desenvolvedores para aplicar correções de licenciamento ou aplicar novos patches de segurança.

Os benefícios da SCA incluem maior confiança nas posturas de conformidade e cibersegurança de uma organização, bem como maior automação dos fluxos de trabalho de TI.

Ao garantir que todos os componentes de código aberto no ecossistema de TI sejam usados de acordo com seus requisitos de licenciamento e conformidade, a SCA pode ajudar as organizações a reduzir os riscos legais.

Identificar vulnerabilidades de rede criadas pela imprevisibilidade dos componentes de software de código aberto é uma parte essencial do gerenciamento de riscos de TI. Ao tornar a cadeia de suprimentos de software de código aberto mais transparente, as organizações podem desfrutar dos benefícios da personalização e reduzir os custos, enquanto permanecem confiantes de que reduziram os riscos de segurança resultantes.

Ao automatizar grandes partes do rastreamento de vulnerabilidades, dependências e conformidade, as soluções de SCA liberam as equipes de TI para realizar outras tarefas. Essa ampla automação também ajuda a reforçar as práticas de DevOps da organização.

Alguns dos desafios impostos pela análise de composição de software incluem a falta de abrangência no rastreamento de vulnerabilidades, na limitação de falsos positivos e no gerenciamento do escopo da análise.

A análise de composição de software é diferente do DAST e do SAST, dois métodos de teste adicionais usados para identificar vulnerabilidades de segurança em aplicações modernas. 

Enquanto a SCA fornece às equipes de TI um mapa abrangente de componentes de software, dependências e vulnerabilidades, o DAST e o SAST se concentram e revelam as falhas individuais nesses componentes e nas aplicações de software maiores que eles constituem.

A diferença entre DAST e SAST é semelhante à diferença entre a verificação estática e a dinâmica no SCA. O teste dinâmico de segurança de aplicações (DAST) avalia as aplicações em seus ambientes de produção, imitando usuários maliciosos e ataques cibernéticos para ajudar a identificar problemas de segurança. Os testes estáticos de segurança de aplicações (SAST) são aprofundados no código-fonte de um aplicativo, procurando vulnerabilidades no código à medida que ele é escrito.  

Enquanto a SCA se concentra em enumerar e analisar os componentes de um determinado software, o DAST e o SAST se concentram especificamente em testar esse software quanto a vulnerabilidades de segurança, seja em tempo de execução no caso do primeiro ou no código-fonte no caso do segundo. Ambos são frequentemente usados em conjunto com a SCA, mas também podem ser praticados de forma independente. 

A SCA é diferente do mapeamento de dependências, que é o processo de identificar, entender e visualizar as relações entre aplicações, sistemas e processos nas operações de TI de uma organização.

As ferramentas de SCA fornecem uma visão geral das dependências dos componentes e identificam possíveis vulnerabilidades que podem surgir delas, mas o mapeamento de dependências refere-se a uma categoria mais ampla de práticas de observabilidade que identificam dependências em todo o ambiente de TI.

O mapeamento de dependência pode se concentrar em dependências dentro e entre aplicações, mas também pode ser mais abrangente, procurando dependências na infraestrutura de rede ou em sistemas inteiros do mundo real, como uma rede elétrica inteligente. O mapeamento de dependência costuma ser um componente das práticas de SCA, mas pode ser executado por conta própria, independentemente das soluções de SCA.