SAST vs SCA

A diferença em resumo

	SAST	SCA
Significa	Static application security testing (testes estáticos de segurança de aplicações)	Software composition analysis (análise de composição de software)
Analisa	O seu próprio código-fonte	Componentes open source e de terceiros
Encontra	Injeção, tratamento inseguro de dados de entrada, padrões inseguros	Vulnerabilidades conhecidas, problemas de licenças, pacotes desatualizados
Baseia-se em	Regras ou modelos que descrevem o mau código	Bases de dados de avisos de segurança publicados
Uma conclusão surge quando	O seu código muda	Uma dependência muda ou é publicado um novo aviso de segurança
Ruído habitual	Falsos positivos em código que é realmente seguro	Correspondências reais que não afetam a forma como usa o pacote
Correção	Alterar o seu código	Atualizar ou substituir o componente

O que faz o SAST

Uma ferramenta de SAST lê o código-fonte sem o executar e acompanha a forma como os dados circulam nele. Se os dados introduzidos pelo utilizador chegarem a uma consulta de base de dados sem serem sanitizados, reporta o ficheiro e a linha. Como trabalha sobre o seu código, consegue encontrar falhas que ninguém publicou. É também a origem das queixas sobre falsos positivos, uma vez que raciocina sobre o que o código poderia fazer e não sobre o que faz.

O que faz a SCA

Uma análise SCA identifica os componentes de um projeto e procura-os em dados de vulnerabilidades e de licenças. Não analisa a sua lógica. Sabe que uma versão tem uma falha publicada, pelo que os seus resultados costumam ser factuais, mas diz menos sobre se a falha lhe importa, a menos que a ferramenta acrescente análise de alcançabilidade. Consulte o que é a análise de composição de software para o quadro completo.

Porque precisa de ambos

As duas falhas são independentes. 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 não diz nada sobre uma injeção de SQL no seu próprio handler.

O momento também difere. Uma conclusão de SAST surge quando alguém altera o código, pelo que uma verificação no pull request apanha a maioria delas. 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, sem nenhum commit que desencadeie o que quer que seja. Por isso, a SCA precisa de algo que continue a verificar o que foi distribuído.

Onde se enquadra o DAST

Os testes dinâmicos de segurança de aplicações (dynamic application security testing) atacam uma aplicação em execução a partir do exterior, como faria um atacante real. Encontram o que só se manifesta em tempo de execução, como problemas de autenticação e de configuração, sem ler o código.

	SAST	SCA	DAST
Precisa de	Código-fonte	Manifestos, imagens ou um registo do build	Uma aplicação em execução
É executado	Em pull requests	Em pull requests, em builds e após o lançamento	Num ambiente de testes
Destaca-se em	Falhas no seu código	Riscos conhecidos em dependências	Falhas de execução e de configuração

Qual deve executar primeiro?

Para a maioria das equipas, a SCA. É rápida de configurar, é executada em segundos ou minutos e cobre a maior parte do que distribui, porque a maior parte de uma aplicação moderna são dependências. Acrescente depois o SAST, nos pull requests, e ajuste-o às regras que importam para a sua stack. Acrescente o DAST quando tiver um ambiente de testes estável para o qual o apontar.

Deve comprar uma plataforma ou várias ferramentas?

Plataformas como o Snyk, o Checkmarx e o GitHub Advanced Security reúnem SAST e SCA, o que significa um contrato e um fluxo de trabalho. As ferramentas separadas podem ser mais fortes em cada área. O que mais importa são os dados de entrada: ambos os tipos de scanner trabalham a partir do que está declarado ou escrito, e nenhum vê o que o build efetivamente trouxe.

O que nenhum deles cobre

Tanto o SAST como a SCA leem ficheiros. Nenhum deles observa o build, pelo que o código obtido por um hook de instalação, os pacotes restaurados de caches de CI e as próprias ferramentas de build podem ficar fora de vista. É dessa lacuna que trata a segurança da cadeia de abastecimento de software.

O CRACI cobre essa parte e deixa a análise de código para as ferramentas criadas para isso. Por opção de conceção, não faz SAST nem deteção de segredos, e há muitas excelentes ferramentas de SAST que funcionam a par dele. É um runner de GitHub Actions que regista o que cada job obtém numa SBOM e continua a verificar as SBOM do que foi distribuído face a novas vulnerabilidades. Consulte as melhores ferramentas de SCA e onde o CRACI se enquadra junto delas.

SAST vs SCA: perguntas frequentes

Qual é a diferença entre SAST e SCA?

O SAST analisa o código que a sua equipa escreve à procura de falhas como injeção. A SCA analisa os componentes open source e de terceiros de que depende à procura de vulnerabilidades conhecidas e de problemas de licenças.

A SCA substitui o SAST?

Não. Analisam código diferente. A SCA não encontra uma falha na sua própria lógica, e o SAST não lhe diz que uma dependência tem uma vulnerabilidade publicada.

Qual é a diferença entre SAST, DAST e SCA?

O SAST lê o seu código-fonte. A SCA verifica as suas dependências. O DAST testa uma aplicação em execução a partir do exterior. Cada um encontra problemas que escapam aos outros dois.

O Snyk é SAST ou SCA?

Ambos. O Snyk começou com a análise de dependências open source e oferece também SAST, bem como análise de contentores e de infraestrutura como código.

O SonarQube é SAST ou SCA?

O SonarQube é mais conhecido pela análise estática do seu próprio código, que é SAST. Verifique nas edições atuais o que mais incluem.

O que vem primeiro, SAST ou SCA?

A SCA é normalmente o ganho mais rápido, porque é simples de configurar e cobre a maior parte do que distribui. O SAST exige mais ajustes para manter os falsos positivos baixos.