Qual a diferença entre SAST, DAST e SCA no contexto de CI/CD?

SAST (Static Application Security Testing) analisa o código-fonte sem executar a aplicação, detectando falhas como injeção SQL, XSS e uso inseguro de criptografia diretamente no repositório. DAST (Dynamic Application Security Testing) interage com a aplicação em execução — normalmente em staging — simulando ataques externos como um scanner de vulnerabilidades faria. SCA (Software Composition Analysis) não analisa o código que você escreveu, mas as bibliotecas de terceiros que você usa: mapeia CVEs conhecidos, licenças problemáticas e dependências transitivas. As três abordagens são complementares: SAST encontra o que você criou de errado, SCA detecta o que você importou de errado, DAST confirma o que ainda é explorável em produção.

Em que etapa do pipeline cada ferramenta deve ser executada?

SAST roda no commit ou no pull request, antes do merge para a branch principal — o custo de corrigir uma falha é menor quando o desenvolvedor ainda tem contexto do código. SCA executa junto ao SAST ou imediatamente após, pois analisa o manifesto de dependências (package.json, pom.xml, go.sum, requirements.txt) que já existe no repositório. Secret scanning também pertence a esta etapa: ferramentas como Gitleaks ou Trufflehog varrem cada commit em busca de chaves de API e credenciais expostas. IaC scanning (Checkov, KICS, Terrascan) deve rodar sempre que arquivos Terraform, CloudFormation, Helm ou Kubernetes forem modificados. Container scanning (Trivy, Grype) atua no build da imagem Docker, antes do push para o registry. DAST vai para depois do deploy em staging, quando a aplicação está de fato rodando e acessível.

O que é um security gate e como configurá-lo sem travar o time?

Um security gate é uma condição de parada no pipeline que bloqueia o avanço do artefato quando determinado critério de segurança não é atendido. A chave para não travar o time está em dois princípios: severidade mínima e prazo de remediação. Um gate razoável bloqueia apenas falhas críticas e altas sem CVE fix disponível — falhas médias viram tickets com SLA de 30 dias, baixas entram no backlog. O segundo princípio é o baseline: na primeira execução do scanner, todo resultado existente é aceito como dívida técnica conhecida; o gate passa a bloquear apenas achados novos introduzidos naquele PR. Isso elimina o problema do 'legacy noise' que desacredita a prática. Ferramentas como Semgrep, Snyk e GitHub Advanced Security suportam esse modelo de diff-based alerting nativamente.

O que é Poisoned Pipeline Execution (PPE) e como mitigar?

Poisoned Pipeline Execution é um ataque no qual um adversário com acesso a pull requests externos — ou a uma branch sem proteção — injeta código malicioso diretamente no arquivo de definição do pipeline (como .github/workflows/ci.yml). Quando o CI executa aquele workflow, o atacante pode exfiltrar secrets do ambiente, instalar backdoors no artefato final ou escalar privilégios para o registry ou cloud. A mitigação requer: (1) nunca executar workflows de PRs externos com acesso a secrets de produção — use ambientes separados com tokens de escopo mínimo; (2) proteger branches principais com branch protection rules e required reviews; (3) fixar versões de actions de terceiros por hash de commit, não por tag semântica (uma tag pode ser reescrita); (4) auditar permissões GITHUB_TOKEN com 'permissions: read-all' por padrão e sobrescrever apenas onde necessário; (5) usar OpenID Connect (OIDC) para autenticação cloud em vez de credenciais estáticas.

Como ataques de supply chain como SolarWinds e 3CX se relacionam com o pipeline?

O ataque à SolarWinds em 2020 comprometeu o processo de build da empresa: código malicioso foi injetado na etapa de compilação, gerando um artefato assinado e legítimo que foi distribuído para 18.000 clientes. O caso 3CX em 2023 seguiu o mesmo vetor — uma dependência de terceiros comprometida contaminou o instalador oficial, que passou por verificação de assinatura sem detectar a adulteração. Ambos os casos demonstram que confiança no binário final não equivale a confiança no processo que o gerou. A resposta técnica é o framework SLSA (Supply-chain Levels for Software Artifacts): um conjunto de níveis que exige provenance verificável (quem construiu, quando, a partir de qual commit), builds herméticos e reproduzíveis, e assinatura do artefato com Sigstore/Cosign. SLSA nível 3 teria detectado e bloqueado ambos os ataques, pois a provenance assinada não bateria com o artefato adulterado.

Quais são as referências normativas para implementar DevSecOps?

As principais referências são: OWASP DevSecOps Guideline (owasp.org/www-project-devsecops-guideline), que mapeia controles de segurança para cada fase do ciclo de desenvolvimento; NIST SSDF — Secure Software Development Framework (SP 800-218), que define práticas para preparar a organização, proteger o software, produzir artefatos bem seguros e responder a vulnerabilidades pós-lançamento; SLSA (slsa.dev), framework de níveis de integridade da cadeia de suprimentos de software mantido pela Linux Foundation; CIS Software Supply Chain Security Guide; e, para ambientes regulados no Brasil, a Resolução BCB 4.658 e a Resolução CVM 35/2021 que exigem gestão de riscos no ciclo de desenvolvimento de sistemas. O alinhamento com ISO 27001 Anexo A.8 (Segurança de Ativos) e A.12 (Segurança em Operações) também é exigido em contratos enterprise.

Segurança no Pipeline CI/CD: SAST, DAST e SCA na Prática

Guia técnico completo sobre SAST, DAST e SCA no pipeline CI/CD: onde cada ferramenta age, gates de qualidade, supply chain attacks, SLSA, Sigstore e PPE.

Segurança no pipeline CI/CD significa tratar vulnerabilidades como defeitos de código — descobertos e corrigidos antes do deploy, não depois de um incidente. Essa abordagem, chamada de shift-left, move os controles de segurança para as etapas mais iniciais do ciclo de desenvolvimento, onde o custo de correção é entre 10 e 100 vezes menor do que em produção.

Por que o pipeline é uma superfície de ataque crítica

O pipeline CI/CD tem acesso privilegiado a praticamente tudo: repositório de código, credenciais de cloud, registry de containers, ambientes de staging e produção. Um atacante que compromete o pipeline não precisa explorar a aplicação — ele controla o processo que gera a aplicação. Os casos SolarWinds (2020) e 3CX (2023) demonstraram que código malicioso injetado na etapa de build pode ser assinado e distribuído como legítimo para milhares de clientes sem nenhum alarme. No SolarWinds, o artefato comprometido passou por verificação de assinatura e foi distribuído por canal oficial de atualização. No 3CX, uma dependência de terceiros contaminada foi suficiente para comprometer o instalador oficial assinado. Esses ataques de supply chain tornaram a segurança do pipeline uma prioridade equivalente à segurança da aplicação em si.

As quatro camadas de análise: SAST, SCA, DAST e IaC

Técnica	O que analisa	Quando executa	Exemplos de ferramentas
SAST	Código-fonte da aplicação (sem execução)	Commit / Pull Request	Semgrep, CodeQL, Checkmarx, SonarQube
SCA	Dependências de terceiros (CVEs, licenças)	Commit / Pull Request	Snyk, OWASP Dependency-Check, Dependabot, Grype
DAST	Aplicação em execução (staging)	Após deploy em staging	OWASP ZAP, Nuclei, Burp Suite Enterprise
IaC Scanning	Infraestrutura como código (Terraform, K8s)	Commit com mudança de infra	Checkov, KICS, Terrascan, tfsec
Container Scanning	Imagens Docker (OS packages, CVEs)	Build da imagem, antes do push	Trivy, Grype, Snyk Container
Secret Scanning	Credenciais e tokens no código	Primeiro job do pipeline	Gitleaks, Trufflehog, GitHub Secret Scanning

SAST: encontrando o que você criou de errado

Static Application Security Testing lê o código sem executá-lo, construindo um modelo do fluxo de dados e do grafo de chamadas para detectar padrões inseguros. SAST encontra injeção SQL quando uma variável não sanitizada chega a uma query, XSS quando entrada do usuário é renderizada sem escaping, uso de algoritmos criptográficos obsoletos (MD5, DES), referências a funções perigosas (strcpy, eval, exec) e configurações hardcoded como credenciais no código. O ponto fraco do SAST é a taxa de falsos positivos — ferramentas mais antigas geram ruído que desacredita o processo. A solução é usar ferramentas baseadas em regras semânticas com baixo FP (Semgrep, CodeQL) e configurar um baseline na primeira execução: todo resultado existente é aceito como dívida técnica conhecida, e o gate bloqueia apenas novos achados introduzidos no PR em revisão.

SCA: o risco que você importou

Software Composition Analysis resolve um problema crescente: a maior parte do código de uma aplicação moderna não foi escrita pelo time — são bibliotecas open source. O npm de uma aplicação Node.js típica puxa 500 a 2.000 pacotes transitivos. SCA mapeia o grafo completo de dependências, cruza com bases de CVEs (NVD, GitHub Advisory Database, OSV) e sinaliza: qual pacote está vulnerável, qual versão corrige, e se existe uma versão compatível no grafo atual. Além de CVEs, SCA verifica licenças — uma dependência GPL em um produto proprietário pode gerar passivo jurídico significativo. A integração com o pipeline deve incluir monitoramento contínuo: uma dependência que era segura na semana passada pode ter um CVE publicado hoje, sem nenhuma mudança de código da sua parte.

DAST: confirmando o que ainda é explorável

Dynamic Application Security Testing age como um pesquisador de segurança externo: interage com a aplicação em execução, envia payloads maliciosos e observa o comportamento. DAST encontra o que SAST não encontra — falhas que emergem apenas em runtime, como configurações de servidor incorretas, headers de segurança ausentes (CSP, HSTS, X-Frame-Options), endpoints não documentados que escaparam da análise estática, e vulnerabilidades de lógica de negócio que dependem de sequências de requisições. O desafio do DAST em pipelines automatizados é o tempo de execução e a cobertura: um crawl completo pode levar horas. A solução prática é uma suite de testes DAST direcionada — executada contra os endpoints críticos definidos na especificação OpenAPI da aplicação — e uma varredura passiva ampla que não injeta payloads e por isso não causa efeitos colaterais em dados de teste.

Poisoned Pipeline Execution: o ataque ao próprio CI

Poisoned Pipeline Execution (PPE) é uma classe de ataques catalogada por pesquisadores da Cider Security em 2021. A premissa é simples: se um atacante pode modificar o arquivo de definição do workflow (como .github/workflows/ci.yml) em um contexto onde o pipeline tem acesso a secrets de produção, ele pode exfiltrar credenciais, modificar artefatos durante o build ou escalar privilégios para o registry e a cloud. Esse acesso pode vir de um PR externo (fork), de uma branch sem proteção, ou de uma dependência de action de terceiro comprometida. A mitigação exige múltiplos controles: workflows de PRs externos devem usar o evento pull_request (sem secrets de produção) em vez de pull_request_target; actions de terceiros devem ser fixadas por hash de commit imutável, não por tag semântica que pode ser reescrita silenciosamente; o GITHUB_TOKEN deve ter permissões mínimas declaradas explicitamente; e autenticação para cloud deve usar OIDC em vez de credenciais estáticas armazenadas em variáveis de ambiente.

Assinatura de artefatos e o framework SLSA

A resposta técnica aos ataques de supply chain é garantir provenance verificável — evidência criptográfica de que um artefato específico foi produzido por um processo específico a partir de um commit específico. O framework SLSA (Supply-chain Levels for Software Artifacts, pronunciado salsa), mantido pela Linux Foundation e apoiado por Google, GitHub e outros, define quatro níveis de maturidade. SLSA 1 exige provenance gerado automaticamente. SLSA 2 adiciona assinatura criptográfica da provenance. SLSA 3 requer que o build seja executado em infraestrutura controlada e auditável, e que a provenance seja gerada pelo próprio sistema de build de forma não-falsificável. SLSA 4 (ainda em desenvolvimento) adiciona builds herméticos e reproduzíveis. A implementação prática usa Sigstore — um projeto open source que oferece assinatura sem gerenciamento de chaves privadas, usando certificados efêmeros vinculados a identidades OIDC — e Cosign para assinar e verificar imagens de container. Com SLSA 3 + Cosign, um sistema de deploy pode recusar qualquer imagem cuja provenance assinada não bata com o repositório e commit esperados, tornando ataques como o do SolarWinds detectáveis antes da distribuição.

Least privilege nos runners: o princípio mais negligenciado

Runners de CI são máquinas com acesso privilegiado que executam código arbitrário a cada push. Apesar disso, a maioria das organizações concede a eles permissões amplas de cloud, registry e secrets. O modelo de least privilege para runners exige: (1) usar OIDC para autenticação cloud — o runner obtém um token temporário de escopo mínimo por job, sem credenciais persistentes; (2) separar ambientes por branch — runners de PRs externos não acessam secrets de staging, apenas runners de merges na branch principal o fazem; (3) isolar runners de produção em rede separada, sem rota de saída para a internet exceto endpoints específicos; (4) usar efêmeros — runners destruídos após cada job, sem estado persistente que possa ser comprometido entre execuções; (5) auditar regularmente as permissões de IAM atribuídas a cada role de runner com ferramentas como AWS IAM Access Analyzer ou GCP IAM Recommender.

Security gates: bloqueio sem paralisar o desenvolvimento

Um security gate é uma condição de parada que impede o avanço do pipeline quando um critério de segurança não é atendido. A implementação ingênua — bloquear qualquer CVE ou qualquer achado de SAST — paralisa o desenvolvimento no primeiro dia. A implementação eficaz usa três critérios: severidade (bloquear apenas crítico/alto com fix disponível), novidade (diff-based alerting: bloquear apenas achados introduzidos no PR, não dívida técnica histórica) e prazo (achados médios viram tickets com SLA de 30 dias, baixos entram no backlog trimestral). Esse modelo permite que o time avance sem acumular novas vulnerabilidades enquanto trata a dívida existente de forma estruturada. A métrica de acompanhamento é o MTTR por severidade — Mean Time to Remediate — que deve ser monitorada e reportada mensalmente para evidenciar maturidade do programa de segurança.

Referências normativas

A implementação de DevSecOps em ambientes regulados deve se alinhar a: OWASP DevSecOps Guideline (owasp.org/www-project-devsecops-guideline), que mapeia controles de segurança para cada fase do SDLC; NIST SSDF — Secure Software Development Framework (SP 800-218), referência do governo norte-americano adotada por contratos federais e crescentemente exigida em contratos enterprise no Brasil; SLSA (slsa.dev) para integridade da cadeia de suprimentos; e, no contexto brasileiro, a Resolução BCB 4.658 e a Resolução CVM 35/2021, que exigem gestão formal de riscos no ciclo de desenvolvimento de sistemas para instituições financeiras. O alinhamento com ISO 27001:2022 Anexo A.8 (Segurança de Ativos) e A.8.25–A.8.31 (Ciclo de vida de desenvolvimento seguro) é exigido em auditorias de certificação e em contratos com grandes corporações.

Perguntas frequentes

Qual a diferença entre SAST, DAST e SCA no contexto de CI/CD?: SAST analisa o código-fonte sem executar a aplicação, detectando falhas como injeção SQL e uso inseguro de criptografia diretamente no repositório. DAST interage com a aplicação em execução em staging, simulando ataques externos. SCA não analisa o código que você escreveu, mas as bibliotecas de terceiros que você usa: mapeia CVEs conhecidos, licenças problemáticas e dependências transitivas. As três abordagens são complementares — SAST encontra o que você criou de errado, SCA detecta o que você importou de errado, DAST confirma o que ainda é explorável em runtime.
Em que etapa do pipeline cada ferramenta deve ser executada?: SAST e SCA rodam no commit ou pull request, antes do merge para a branch principal. Secret scanning deve ser o primeiro job do pipeline. IaC scanning executa sempre que arquivos Terraform, CloudFormation, Helm ou Kubernetes são modificados. Container scanning atua no build da imagem Docker, antes do push para o registry. DAST vai para depois do deploy em staging, quando a aplicação está em execução e acessível — em uma URL de ambiente isolada, não em produção.
O que é um security gate e como configurá-lo sem travar o time?: Um security gate é uma condição de parada no pipeline que bloqueia o avanço quando um critério de segurança não é atendido. A configuração que não paralisa o desenvolvimento combina três critérios: severidade mínima (bloquear apenas crítico/alto com fix disponível), diff-based alerting (bloquear apenas achados novos introduzidos no PR, não dívida técnica existente) e prazo de remediação (achados médios viram tickets com SLA de 30 dias). Ferramentas como Semgrep, Snyk e GitHub Advanced Security suportam esse modelo nativamente.
O que é Poisoned Pipeline Execution e como mitigar?: Poisoned Pipeline Execution é um ataque onde um adversário injeta código malicioso no arquivo de definição do pipeline para exfiltrar secrets ou adulterar artefatos durante o build. Mitigação requer: nunca executar workflows de PRs externos com acesso a secrets de produção; fixar actions de terceiros por hash de commit imutável; usar OIDC em vez de credenciais estáticas; e aplicar permissões mínimas explícitas no GITHUB_TOKEN de cada job.
Como ataques de supply chain como SolarWinds e 3CX se relacionam com o pipeline?: O ataque à SolarWinds injetou código malicioso na etapa de compilação, gerando um artefato assinado e legítimo distribuído para 18.000 clientes. O caso 3CX comprometeu uma dependência de terceiros que contaminou o instalador oficial assinado. Ambos demonstram que a confiança no binário final não equivale à confiança no processo que o gerou. A resposta técnica é o framework SLSA com assinatura via Sigstore/Cosign: provenance verificável e builds herméticos tornam esses ataques detectáveis antes da distribuição.
Quais são as referências normativas para implementar DevSecOps?: As principais referências são: OWASP DevSecOps Guideline (controles por fase do SDLC), NIST SSDF SP 800-218 (práticas de desenvolvimento seguro), SLSA (integridade de supply chain), CIS Software Supply Chain Security Guide, e no Brasil as Resoluções BCB 4.658 e CVM 35/2021 para instituições reguladas. O alinhamento com ISO 27001:2022 Anexo A.8.25–A.8.31 é exigido em auditorias de certificação e contratos enterprise.

Como a Decripte implementa DevSecOps

A Decripte integra práticas de DevSecOps e AppSec em organizações de todos os portes — de MEIs que precisam de um pipeline seguro para suas APIs até enterprises com mais de 100.000 colaboradores gerenciando dezenas de produtos em produção. A implementação cobre a auditoria do pipeline existente, integração de ferramentas de SAST, SCA, DAST, IaC e container scanning, definição de security gates calibrados para a maturidade do time, adoção de SLSA e Sigstore para integridade de artefatos, e treinamento de equipes de desenvolvimento em práticas seguras. O resultado é medido em MTTR, redução de vulnerabilidades introduzidas por PR e conformidade com requisitos regulatórios. Conheça os planos de implementação ou comece com uma análise do seu pipeline no nível gratuito.