# Segurança de Pipelines DevOps em 2026: SAST, DAST, Supply Chain e Perguntas de Entrevista > Guia completo para proteger pipelines CI/CD em 2026. Aborda SAST, DAST, SCA, geração de SBOM, procedência SLSA e perguntas práticas de entrevista DevSecOps. - Published: 2026-09-15 - Updated: 2026-09-15 - Author: Anthony Fillion-Maillet - Tags: devops, security, cicd, devsecops, sast, dast - Reading time: 12 min --- A segurança de pipelines DevOps exige a integração de controles de segurança em cada etapa do fluxo de trabalho CI/CD, desde hooks pre-commit até o monitoramento em produção. O [relatório Datadog State of DevSecOps 2026](https://www.datadoghq.com/state-of-devsecops/) revela que 87% das organizações executam serviços com pelo menos uma vulnerabilidade explorável conhecida, enquanto os ataques à cadeia de suprimentos de software agora custam mais de 80 bilhões de dólares por ano à economia global. > **A Ordem de Prioridade das Ferramentas de Segurança** > > Comece com a detecção de secrets (maior impacto, menor taxa de falsos positivos), depois adicione SCA para CVEs conhecidos, SAST com ajustes, scanning IaC e finalmente DAST. Cada ferramenta deve demonstrar valor antes de adicionar a próxima. ## SAST: Análise Estática que Detecta Vulnerabilidades Antes do Merge Static Application Security Testing (SAST) analisa o código-fonte sem executá-lo. A ferramenta faz o parse da base de código, constrói uma árvore de sintaxe abstrata e compara padrões com assinaturas de vulnerabilidades conhecidas. Executar SAST em cada pull request detecta injeções SQL, XSS e credenciais hardcoded antes que o código chegue à branch principal. O Semgrep tornou-se a ferramenta SAST open-source de referência em 2026. Ao contrário dos scanners baseados em regex, o Semgrep entende a estrutura do código e suporta regras personalizadas em YAML. ```yaml # .github/workflows/sast.yml name: SAST Scan on: pull_request: branches: [main, develop] jobs: semgrep: runs-on: ubuntu-latest container: image: semgrep/semgrep:latest steps: - uses: actions/checkout@v4 - name: Run Semgrep run: semgrep scan --config=auto --sarif --output=semgrep.sarif - name: Upload SARIF uses: github/codeql-action/upload-sarif@v3 with: sarif_file: semgrep.sarif ``` A flag `--config=auto` carrega as regras da comunidade que correspondem às linguagens detectadas. A saída SARIF se integra com a aba Security do GitHub para rastrear descobertas ao longo do tempo. ## DAST: Testes em Runtime que Encontram o que a Análise Estática Não Detecta Dynamic Application Security Testing (DAST) ataca uma aplicação em execução para encontrar vulnerabilidades que só se manifestam em runtime. Falhas de autenticação, defeitos de autorização e bugs de lógica de negócio requerem requisições HTTP reais para serem detectados. SAST não consegue detectar que um endpoint de admin não tem controle de acesso apropriado, mas DAST tentará acessá-lo sem credenciais e sinalizará a exposição. [OWASP ZAP](https://www.zaproxy.org/) continua sendo a ferramenta DAST open-source mais implantada. O ZAP 3.0, lançado no início de 2026, adicionou suporte nativo para scanning de GraphQL e gRPC. ```yaml # .github/workflows/dast.yml name: DAST Scan on: deployment: types: [created] jobs: zap-scan: runs-on: ubuntu-latest steps: - name: ZAP Full Scan uses: zaproxy/action-full-scan@v0.12.0 with: target: ${{ secrets.STAGING_URL }} rules_file_name: '.zap/rules.tsv' cmd_options: '-a -j -l WARN -z "-config api.disablekey=true"' - name: Upload Report uses: actions/upload-artifact@v4 with: name: zap-report path: report_html.html ``` DAST é executado pós-deploy porque precisa de um alvo ativo. O ambiente de staging serve como superfície de teste, mantendo a produção isolada do tráfego de scanning. > **DAST em Produção** > > Executar scans DAST ativos contra produção arrisca ativar limites de taxa, corromper dados ou alertar o monitoramento de segurança. Use um ambiente de staging que replique a configuração de produção. ## SCA: Scanning de Dependências para Vulnerabilidades Conhecidas Software Composition Analysis (SCA) escaneia dependências contra bancos de dados de vulnerabilidades como a [National Vulnerability Database](https://nvd.nist.gov/) e o GitHub Advisory Database. Uma única dependência transitiva vulnerável pode expor toda a aplicação. O relatório Datadog 2026 descobriu que 42% dos serviços dependem de bibliotecas que não são mais ativamente mantidas. O Trivy escaneia containers, sistemas de arquivos e repositórios git para vulnerabilidades em um único binário. Ele gera SBOMs nos formatos CycloneDX e SPDX. ```yaml # .github/workflows/sca.yml name: Dependency Scan on: push: branches: [main] schedule: - cron: '0 6 * * *' # Diário às 6h jobs: trivy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Run Trivy vulnerability scanner uses: aquasecurity/trivy-action@0.28.0 with: scan-type: 'fs' scan-ref: '.' format: 'sarif' output: 'trivy-results.sarif' severity: 'CRITICAL,HIGH' - name: Upload Trivy scan results uses: github/codeql-action/upload-sarif@v3 with: sarif_file: 'trivy-results.sarif' ``` O scan diário agendado detecta CVEs recém-divulgados mesmo sem mudanças de código. Filtrar por severidades CRITICAL e HIGH previne a fadiga de alertas de descobertas de baixo risco. ## Segurança da Supply Chain: SBOM e Procedência SLSA O [EU Cyber Resilience Act](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act), com obrigações de relatório entrando em vigor em setembro de 2026, exige a geração de Software Bill of Materials (SBOM) para produtos vendidos na UE. Um SBOM lista cada componente do software, incluindo dependências diretas, transitivas e suas versões. [SLSA](https://slsa.dev/) (Supply-chain Levels for Software Artifacts) complementa o SBOM verificando como o software foi construído. SBOM responde "quais componentes estão neste software?" enquanto SLSA responde "pode-se confiar no processo de build?" ```yaml # .github/workflows/supply-chain.yml name: Supply Chain Security on: push: tags: - 'v*' jobs: build-with-provenance: runs-on: ubuntu-latest permissions: contents: read id-token: write attestations: write steps: - uses: actions/checkout@v4 - name: Build container image run: docker build -t myapp:${{ github.ref_name }} . - name: Generate SBOM uses: anchore/sbom-action@v0.17.0 with: image: myapp:${{ github.ref_name }} format: cyclonedx-json output-file: sbom.json - name: Sign with Cosign uses: sigstore/cosign-installer@v3.7.0 - name: Sign image and attach SBOM run: | cosign sign --yes myapp:${{ github.ref_name }} cosign attach sbom --sbom sbom.json myapp:${{ github.ref_name }} cosign sign --yes --attachment sbom myapp:${{ github.ref_name }} ``` O Cosign do Sigstore assina artefatos usando assinatura sem chaves respaldada pela autoridade de certificação Fulcio. A assinatura vincula o artefato ao workflow de CI que o produziu, permitindo verificar que a imagem veio de um pipeline confiável. ## Detecção de Secrets: A Primeira Linha de Defesa Secrets hardcoded continuam sendo a descoberta de segurança mais comum em bases de código. Chaves de acesso AWS, senhas de banco de dados e tokens de API commitados no controle de versão causaram brechas em todas as escalas. A detecção de secrets é executada em pre-commit para bloquear credenciais antes que entrem no repositório. [Gitleaks](https://github.com/gitleaks/gitleaks) detecta secrets usando padrões regex e análise de entropia. Um hook pre-commit previne que secrets sejam commitados. ```yaml # .pre-commit-config.yaml repos: - repo: https://github.com/gitleaks/gitleaks rev: v8.21.2 hooks: - id: gitleaks args: ['--verbose'] ``` ```yaml # .github/workflows/secrets.yml name: Secrets Detection on: pull_request: jobs: gitleaks: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: fetch-depth: 0 - name: Gitleaks scan uses: gitleaks/gitleaks-action@v2 env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} ``` A opção `fetch-depth: 0` clona o histórico completo, permitindo que o Gitleaks escaneie todos os commits do PR, não apenas o mais recente. ## Perguntas de Entrevista DevSecOps: O que os Recrutadores Perguntam Entrevistas DevSecOps avaliam tanto conhecimento de segurança quanto experiência prática em CI/CD. As perguntas abaixo aparecem frequentemente em entrevistas de 2026 para cargos senior de DevOps e engenharia de plataforma. Veja mais perguntas sobre segurança de pipelines no [módulo de entrevista CI/CD Pipeline Security](/technologies/devops/interview-questions/cicd-pipeline-security). ### "Como você implementaria segurança shift-left em um pipeline existente?" Segurança shift-left move os testes para mais cedo no ciclo de desenvolvimento. A implementação prática envolve adicionar hooks pre-commit para detecção de secrets, scans SAST em pull requests e verificações SCA na fase de build. A chave é a adoção incremental: começar com detecção de secrets porque tem a menor taxa de falsos positivos e o maior sinal, depois adicionar SCA para CVEs conhecidos, depois ajustar as regras SAST para reduzir ruído antes de habilitá-lo como controle bloqueante. ### "Explique a diferença entre SAST e DAST. Quando você usaria cada um?" SAST analisa código-fonte sem execução. Encontra injeção SQL, XSS e criptografia insegura por correspondência de padrões contra a estrutura do código. SAST é executado cedo, em cada PR, porque só precisa do código. DAST ataca uma aplicação em execução. Encontra bypasses de autenticação, controle de acesso quebrado e vulnerabilidades de injeção que só se manifestam em runtime. DAST é executado pós-deploy contra um ambiente de staging. Os dois se complementam. SAST detecta erros de codificação antes do merge; DAST verifica que a aplicação deployada se comporta de forma segura. Um pipeline maduro executa ambos. ### "O que é um SBOM e por que é necessário?" Um Software Bill of Materials lista cada componente do software, incluindo dependências diretas e transitivas com versões exatas. Requisitos regulatórios como o EU Cyber Resilience Act exigem geração de SBOM para produtos entrando no mercado europeu a partir de setembro de 2026. Praticamente, SBOM permite resposta rápida a incidentes. Quando um novo CVE é divulgado, a equipe de segurança pode consultar o banco de dados SBOM para identificar cada serviço executando o componente vulnerável em vez de escanear todos os repositórios manualmente. ### "Como prevenir a fadiga de alertas em ferramentas de segurança?" A fadiga de alertas ocorre quando desenvolvedores ignoram descobertas de segurança porque a relação sinal-ruído é muito baixa. A prevenção requer ajustar cada ferramenta antes de habilitar controles bloqueantes. Para SAST, desabilitar regras que produzem falsos positivos na base de código e habilitá-las gradualmente após a limpeza. Para SCA, focar em descobertas de severidade CRITICAL e HIGH com exploits conhecidos. Para DAST, configurar scans de referência para excluir falsos positivos de execuções futuras. A métrica a rastrear é o tempo de correção para vulnerabilidades reais. Se esse número aumenta, os desenvolvedores estão ignorando os alertas. > **Preparação para Entrevistas** > > Essas perguntas testam experiência prática. Prepare exemplos de pipelines reais, incluindo ferramentas específicas, decisões de configuração e métricas antes e depois da implementação. ## Segurança de Containers e Runtime O scanning de imagens de containers detecta vulnerabilidades antes do deploy. A segurança de runtime monitora containers em produção por comportamento anômalo. A combinação aborda tanto vulnerabilidades conhecidas (CVEs em imagens base) quanto ameaças desconhecidas (containers comprometidos, criptomineradores). O Trivy escaneia imagens como parte do pipeline de build. [Falco](https://falco.org/) monitora comportamento em runtime usando eBPF. ```yaml # .github/workflows/container-security.yml name: Container Security on: push: branches: [main] jobs: scan-image: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Build image run: docker build -t myapp:${{ github.sha }} . - name: Scan image uses: aquasecurity/trivy-action@0.28.0 with: image-ref: myapp:${{ github.sha }} format: 'table' exit-code: '1' severity: 'CRITICAL' ignore-unfixed: true ``` A flag `ignore-unfixed: true` pula vulnerabilidades sem patches disponíveis. Isso previne bloquear deploys por CVEs que atualmente não podem ser remediados. Para segurança de runtime, as regras Falco detectam atividade suspeita em containers em execução. O [módulo de segurança de supply chain de containers](/technologies/devops/interview-questions/container-supply-chain) cobre assinatura de imagens e controle de admissão em profundidade. ## Segurança IaC: Escaneando Terraform e Manifests Kubernetes Infrastructure as Code introduz riscos de segurança na camada de configuração. Políticas IAM muito permissivas, buckets S3 acessíveis publicamente e bancos de dados não criptografados resultam de valores padrão inseguros em templates IaC. [Checkov](https://www.checkov.io/) escaneia Terraform, CloudFormation, Kubernetes, Helm e Dockerfiles para configurações incorretas. ```yaml # .github/workflows/iac-scan.yml name: IaC Security Scan on: pull_request: paths: - 'terraform/**' - 'k8s/**' - 'helm/**' jobs: checkov: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Run Checkov uses: bridgecrewio/checkov-action@v12 with: directory: . framework: terraform,kubernetes,helm output_format: sarif output_file_path: checkov.sarif soft_fail: false - name: Upload SARIF uses: github/codeql-action/upload-sarif@v3 with: sarif_file: checkov.sarif ``` O filtro de path garante que os scans IaC só sejam executados quando arquivos de infraestrutura mudam, reduzindo o tempo de CI para mudanças apenas de aplicação. ## O Pipeline DevSecOps Completo para 2026 Um pipeline DevSecOps pronto para produção em 2026 integra essas ferramentas em cada etapa: - **Pre-commit**: Gitleaks (secrets), SAST local opcional - **Pull request**: Semgrep (SAST), Trivy (SCA), Checkov (IaC) - **Build**: Scanning de imagens de containers, geração SBOM - **Pre-deploy**: Assinatura de imagens com Cosign, controle de admissão com Kyverno - **Post-deploy**: DAST com ZAP contra staging - **Runtime**: Falco para monitoramento de containers, gerenciamento de postura de segurança cloud A stack gratuita (Semgrep, Trivy, ZAP, Gitleaks, Checkov, Falco) cobre cada categoria. As ferramentas comerciais adicionam dashboards centralizados, gerenciamento de políticas e esforço de ajuste reduzido, mas a cobertura de segurança é alcançável sem custos de licença. Organizações se preparando para cargos DevSecOps devem praticar construindo esses pipelines em projetos pessoais. O [módulo de gerenciamento de identidades cloud e secrets](/technologies/devops/interview-questions/cloud-identity-secrets) cobre o lado de gerenciamento de secrets da equação. --- Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack. HTML version of this page: https://sharpskill.dev/pt/blog/devops/devops-pipeline-security-sast-dast-2026