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

Como funciona a SCA

1. Identificar os componentes. A ferramenta lê aquilo para que é apontada: manifestos e lockfiles num repositório, pacotes instalados ou o conteúdo de uma imagem de contentor ou de um binário. O resultado é um inventário de componentes e versões, muitas vezes exportado como uma SBOM.
2. Cruzá-los com riscos conhecidos. Cada componente é procurado em bases de dados de vulnerabilidades como a GitHub Advisory Database, a OSV e a NVD, e a sua licença declarada é comparada com a sua política.
3. Priorizar. As conclusões são ordenadas por gravidade, e algumas ferramentas acrescentam análise de alcançabilidade para verificar se o seu código pode sequer chamar a função vulnerável.
4. Corrigir. Muitas ferramentas sugerem uma versão corrigida ou abrem um pull request, como fazem o Dependabot e o Renovate. Numa dependência transitiva vulnerável, a correção está normalmente no pacote que a traz, o que um grafo de dependências mostra.

O que a SCA encontra

• Vulnerabilidades conhecidas nas versões que usa, com os avisos de segurança que as descrevem.
• Risco de licenças, como uma licença copyleft num produto proprietário.
• Pacotes desatualizados e sem manutenção que não vão receber correções de segurança.
• Pacotes maliciosos, nas ferramentas que também analisam o comportamento dos pacotes em vez de se limitarem a cruzar avisos de segurança.

SCA vs SAST

A SCA e os testes estáticos de segurança de aplicações (SAST) são muitas vezes vendidos em conjunto, mas analisam código diferente e respondem a perguntas diferentes.

	SCA	SAST
O que analisa	Os componentes open source e de terceiros de que depende	O código que a sua equipa escreve
O que encontra	Vulnerabilidades conhecidas, problemas de licenças, pacotes desatualizados	Falhas no seu código, como injeção ou tratamento inseguro de entradas
O que lê	Manifestos, lockfiles, pacotes instalados, imagens ou binários	Código-fonte
O que origina uma nova conclusão	Uma alteração de dependências, ou um novo aviso de segurança para uma versão que já distribui	Uma alteração no seu código
Resultado típico	Componentes vulneráveis com versões corrigidas, e uma SBOM	Localizações no código com a falha e uma correção sugerida

Precisa de ambos. Uma base de código sem conclusões de SAST pode, ainda assim, distribuir uma dependência vulnerável, e uma árvore de dependências limpa nada diz sobre o seu próprio código. Consulte SAST vs SCA para a comparação completa. Uma diferença é importante para a forma como os executa: uma conclusão de SAST surge quando o seu código muda, ao passo que uma conclusão de SCA pode surgir numa versão que distribuiu há meses, no dia em que é publicado um novo aviso de segurança.

Onde a SCA para

Todos os resultados de SCA dependem do primeiro passo: identificar os componentes. Um componente que a ferramenta nunca identificou não pode ser cruzado, priorizado nem corrigido, e também não aparece como lacuna. Os pontos cegos habituais:

• O que os ficheiros não dizem. A maioria das ferramentas de SCA lê manifestos e lockfiles. Um lockfile em falta ou desatualizado, pacotes restaurados de caches de CI, ferramentas de build, descargas e scripts de instalação nunca chegam ao inventário. Consulte porque é que um lockfile não é um registo do que foi distribuído.
• As ferramentas discordam. Dois scanners apontados ao mesmo commit devolvem listas de componentes diferentes, porque cada um tem as suas próprias regras sobre o que ler e como lhe dar nome. Consulte o que escapa aos geradores de SBOM open source.
• Binários. O software distribuído como binário pré-compilado declara pouco ou nada que um leitor de manifestos consiga ver.
• Apenas vulnerabilidades conhecidas. A correspondência encontra o que foi publicado. Um novo pacote malicioso ou uma falha não divulgada ainda não tem aviso de segurança.
• Um instantâneo. Uma análise num pull request descreve esse momento. Os novos avisos de segurança para versões já em produção exigem algo que continue a verificar o que foi distribuído.

Isto não é uma falha de um produto. É assim que a análise funciona, comercial ou open source. O CRACI encontrou pacotes vulneráveis que o Snyk e o Aikido não reportaram, porque os componentes nunca estiveram naquilo que analisaram.

Registe o build, mantenha a sua SCA

O CRACI fecha a lacuna de identificação pelo lado do build. É um runner de GitHub Actions que regista cada pacote que cada job obtém, a qualquer profundidade da árvore e incluindo pacotes restaurados de caches de CI, numa SBOM que indica a sua própria completude. Continua a reavaliar as SBOM do que foi distribuído à medida que são publicadas novas vulnerabilidades, e o histórico de builds mostra que builds anteriores continham um pacote vulnerável.

O CRACI não faz SAST nem análise de alcançabilidade, por opção de conceção. As equipas executam-no ao lado de uma ferramenta de SCA ou de SAST que cobre os pull requests e o seu próprio código. Consulte ferramentas de SCA comparadas, onde o CRACI se enquadra junto das suas ferramentas de SCA ou marque uma demo para comparar uma SBOM registada com a sua análise atual.

Análise de composição de software: perguntas frequentes

O que é a SCA em cibersegurança?

A análise de composição de software (SCA) é a prática de encontrar os componentes open source e de terceiros do seu software e de os verificar quanto a vulnerabilidades conhecidas, problemas de licenças e versões desatualizadas. Cobre o código de que depende, por oposição ao código que escreve.

Qual é a diferença entre SCA e SAST?

O SAST analisa o código que a sua equipa escreve em busca de falhas, como erros de injeção. A SCA analisa os componentes de que depende em busca de vulnerabilidades conhecidas e problemas de licenças. Respondem a perguntas diferentes, pelo que a maioria dos programas de segurança executa ambos.

O que significa análise SCA?

Uma análise SCA lê os manifestos, os lockfiles, os pacotes instalados ou uma imagem de contentor de um projeto, determina que componentes contém e cruza-os com dados de vulnerabilidades e de licenças. O resultado é uma lista de conclusões, muitas vezes com uma SBOM dos componentes que identificou.

Uma SBOM é o mesmo que SCA?

Não. Uma SBOM é um inventário: a lista de componentes de uma versão. A SCA é a análise: identificar componentes e verificar os respetivos riscos. Muitas ferramentas de SCA produzem uma SBOM pelo caminho, e uma SBOM pode alimentar a monitorização de vulnerabilidades após o lançamento.

Quais são as limitações da SCA?

Só analisa os componentes que consegue identificar, normalmente a partir de manifestos e lockfiles. Os pacotes restaurados de caches de CI, as ferramentas de build, as descargas e os binários sem metadados de pacotes podem escapar-lhe. Encontra vulnerabilidades conhecidas, não desconhecidas, e uma análise é um instantâneo, a menos que a ferramenta continue a reverificar o que foi distribuído.

Quais são as melhores ferramentas de SCA?

Depende daquilo de que precisa para além do essencial: análise de alcançabilidade, deteção de pacotes maliciosos, política de licenças ou fluxo de trabalho dos programadores. Consulte a nossa comparação de 13 ferramentas de SCA para ver o que cada uma cobre e onde para.