Este artigo faz parte do guia completo de DevSecOps.
SCA: dependências
A análise de composição de software (SCA) verifica as bibliotecas e dependências do projeto em busca de vulnerabilidades conhecidas. Boa parte do código de um produto moderno vem de terceiros — e é aí que entram muitos riscos.
O SCA responde: usamos alguma versão com falha conhecida? Quão crítica é? Há correção disponível?
SAST: o código
A análise estática (SAST) examina o código-fonte em busca de padrões inseguros, sem executar a aplicação. Ela pega problemas como injeções, uso incorreto de funções e fluxos de dados perigosos.
Como lê o código, o SAST tende a gerar mais falsos positivos — por isso precisa de calibração para não virar ruído ignorado.
Secrets scanning: credenciais
O secrets scanning procura chaves, senhas e tokens que possam ter sido commitados por engano. É barato de rodar e de altíssimo impacto: um segredo exposto pode dar acesso direto a sistemas.
Além de detectar, é preciso ter um processo para revogar e rotacionar o segredo — detectar sem agir não resolve.
- Alto impacto e baixo esforço de adoção.
- Deve rodar cedo (pre-commit e no pipeline).
- Exige processo de revogação/rotação.
Por que combinar as três
Cada verificação cobre uma classe de risco. SCA protege as dependências, SAST protege o código escrito pelo time e secrets scanning protege as credenciais. Combinadas, reduzem muito o que chega à produção — e nenhuma substitui as outras.
Perguntas frequentes
SAST substitui o SCA?
Não. São complementares: o SAST analisa o seu código; o SCA analisa as dependências de terceiros.