Análise SCA

O que acontece numa análise SCA

1. Ler o alvo. O scanner lê manifestos e lockfiles como package-lock.json, poetry.lock ou Cargo.lock, ou desempacota uma imagem de contentor.
2. Construir a lista de componentes. Converte o que encontrou em nomes e versões, normalmente incluindo as dependências transitivas.
3. Cruzar os dados. Cada componente é procurado em fontes como a GitHub Advisory Database, a OSV e a NVD, e a sua licença é comparada com a sua política.
4. Reportar. As conclusões surgem ordenadas por gravidade, normalmente com uma versão corrigida. Na CI, uma política pode fazer o job falhar.

Para a prática mais ampla em que isto se insere, consulte o que é a análise de composição de software.

Onde executar análises SCA

Uma análise num único ponto deixa lacunas. Cada fase responde a uma pergunta diferente, pelo que a maioria das equipas executa mais do que uma.

Onde	A que responde	O que lhe escapa
Máquina do programador ou IDE	Este pacote é seguro para adicionar?	Tudo aquilo em que o programador não a executa
Pull request	Esta alteração acrescenta um risco conhecido?	Novos avisos de segurança para código que não mudou
Build de CI	O que contém a versão?	Tudo o que o scanner não consegue ver no build
Registo de contentores	O que está nesta imagem?	Código compilado e ferramentas de build que não deixam rasto
Após o lançamento	O que distribuímos é afetado por algo novo?	Nada, se o registo do que foi distribuído estiver completo

A última linha é a que a maioria dos programas ignora. Um novo aviso de segurança afeta uma versão que distribuiu há meses, e nenhum pull request vai desencadear uma análise para isso.

Como ler os resultados de uma análise SCA

A primeira análise de um projeto real devolve muitas vezes centenas de conclusões. Trate-as por esta ordem:

1. Comece pelo que está a ser explorado. Uma conclusão que consta do catálogo KEV da CISA passa à frente de uma pontuação CVSS mais alta sem exploração conhecida. Consulte como priorizar vulnerabilidades.
2. Verifique se se aplica. As dependências exclusivas de desenvolvimento não são distribuídas. Algumas ferramentas acrescentam análise de alcançabilidade para verificar se o código vulnerável pode sequer ser chamado.
3. Corrija ao nível certo. Numa conclusão transitiva, a correção está normalmente no pacote que a traz, o que um grafo de dependências mostra.
4. Registe o que não vai corrigir. Uma conclusão que decidiu aceitar deve indicar porquê, caso contrário a pessoa seguinte repete o trabalho. O VEX é a forma normalizada de o registar.

Porque é que uma análise limpa não significa software limpo

• Vê o que está declarado. Um scanner lê os ficheiros que tem à frente, pelo que um repositório que não inclui nenhum lockfile lhe dá pouco com que trabalhar, e o código obtido por um hook de instalação nunca aparece.
• Vê aquilo para onde o apontou. A imagem base, as ferramentas de build e as GitHub Actions do seu pipeline estão separadas do manifesto da sua aplicação.
• Só conhece o que está publicado. Um novo pacote malicioso ainda não tem aviso de segurança.
• A lista não é o build. Os builds resolvem as versões quando são executados, pelo que o que a análise leu e o que a versão contém podem diferir.

Estes são limites da própria análise, 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.

Scanners gratuitos e comerciais

As opções gratuitas cobrem bem o essencial. Os alertas do Dependabot vêm com o GitHub, o OWASP Dependency-Check e o Trivy são open source, e o Grype funciona em conjunto com o gerador de SBOM Syft. As ferramentas comerciais acrescentam políticas, priorização, alcançabilidade e fluxos de trabalho para muitas equipas. A página As melhores ferramentas de SCA comparadas abrange 13 delas, e este guia mostra porque é que os geradores gratuitos discordam entre si.

Análise SCA e registo durante o build

O CRACI não é um scanner, e não tem de abdicar do seu. É 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, e depois continua a reavaliar as SBOM do que foi distribuído à medida que são publicadas novas vulnerabilidades. O seu scanner cobre os pull requests e as máquinas dos programadores. O CRACI cobre o build e tudo o que vem depois. Consulte onde o CRACI se enquadra junto das suas ferramentas de SCA.

Análise SCA: perguntas frequentes

O que é uma análise SCA?

Uma análise SCA lê os manifestos, os lockfiles ou a imagem de contentor de um projeto, determina que componentes open source usa e verifica-os face a dados de vulnerabilidades e de licenças.

SCA é o mesmo que análise de dependências?

Quase. A análise de dependências significa normalmente verificar as dependências quanto a vulnerabilidades conhecidas. SCA é o termo mais amplo e abrange também licenças, pacotes desatualizados e a produção de um inventário, como uma SBOM.

Quando devem ser executadas as análises SCA?

Nos pull requests, para impedir a entrada de novos riscos; no build de CI, para descrever a versão; e continuamente após o lançamento, porque novos avisos de segurança afetam software que já distribuiu.

Quanto tempo demora uma análise SCA?

Normalmente, entre segundos e alguns minutos, porque lê metadados em vez de analisar todo o seu código. Isso torna prático executá-la em cada pull request.

Porque é que os scanners SCA reportam resultados diferentes?

Cada um tem as suas próprias regras sobre o que ler, como dar nome aos componentes e que dados de vulnerabilidades usar. O mesmo commit pode produzir listas de componentes e conclusões diferentes.

A análise SCA encontra malware?

A correspondência com avisos de segurança só encontra versões maliciosas depois de existir um aviso. As ferramentas que analisam o comportamento dos pacotes conseguem apanhar algumas mais cedo. Um novo pacote malicioso não tem aviso no dia em que surge.