# Segurança de Pipelines DevOps em 2026: Melhores Práticas DevSecOps e Perguntas de Entrevista > Guia completo sobre segurança de pipelines CI/CD em 2026. Conheça as melhores práticas DevSecOps, ferramentas SAST/DAST/SCA e as perguntas de entrevista técnica mais frequentes. - Published: 2026-09-08 - Updated: 2026-09-08 - Author: Anthony Fillion-Maillet - Reading time: 5 min --- A segurança de pipelines DevOps tornou-se um diferencial crítico para organizações que implantam software em escala. O [OWASP Top 10 CI/CD Security Risks](https://owasp.org/www-project-top-10-ci-cd-security-risks/) identifica as vulnerabilidades mais perigosas em pipelines modernos, desde controle de fluxo insuficiente até dependências de build comprometidas. Este guia aborda as práticas DevSecOps essenciais que os entrevistadores esperam que os candidatos conheçam em 2026. > **Segurança Shift-Left** > > DevSecOps integra verificações de segurança em cada estágio do ciclo de vida de entrega de software. Em vez de tratar a segurança como um portão final antes da produção, as práticas shift-left detectam vulnerabilidades durante o desenvolvimento, quando as correções custam menos e são entregues mais rapidamente. ## Compreendendo a Superfície de Ataque CI/CD Os pipelines CI/CD modernos apresentam uma superfície de ataque complexa que abrange repositórios de código-fonte, runners de build, registros de artefatos e alvos de implantação. O comprometimento do tj-actions/changed-files em março de 2025 vazou segredos de mais de 23.000 repositórios ao injetar código malicioso em uma GitHub Action amplamente utilizada. O ataque TanStack no início de 2026 publicou mais de 170 pacotes npm envenenados com procedência SLSA Build Level 3 válida, demonstrando que até mesmo atestações criptográficas podem ser contornadas quando os atacantes controlam o processo de build. Esses incidentes destacam três pontos de controle críticos: - **Integridade do código-fonte**: Regras de proteção de branches, commits assinados e revisões de código obrigatórias impedem que alterações não autorizadas alcancem o pipeline de build - **Isolamento do build**: Runners efêmeros, permissões mínimas e verificação de artefatos limitam o raio de explosão de dependências comprometidas - **Higiene de segredos**: Credenciais de curta duração, federação OIDC e varredura de segredos eliminam os tokens estáticos que os atacantes procuram Os entrevistadores frequentemente pedem aos candidatos que tracem os limites de confiança em um pipeline de implantação típico. Uma resposta sólida mapeia cada estágio onde um atacante poderia injetar código ou exfiltrar credenciais. ## SAST e SCA: Detectando Vulnerabilidades Cedo Static Application Security Testing (SAST) analisa o código-fonte em busca de falhas de segurança sem executar o programa. Software Composition Analysis (SCA) identifica vulnerabilidades conhecidas em dependências de terceiros. Executar ambos em cada pull request detecta a maioria dos problemas de segurança comuns antes que o código seja mesclado. ```yaml # .github/workflows/security.yml name: Security Scan on: pull_request: branches: [main] jobs: sast: runs-on: ubuntu-latest permissions: contents: read security-events: write steps: - uses: actions/checkout@v4 - name: Run CodeQL uses: github/codeql-action/analyze@v3 with: languages: javascript,typescript queries: security-extended sca: 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: . severity: HIGH,CRITICAL exit-code: 1 ``` O workflow acima executa CodeQL para SAST e Trivy para SCA. Definir `exit-code: 1` no Trivy faz o build falhar quando vulnerabilidades altas ou críticas aparecem. GitHub Advanced Security e GitLab Ultimate incluem capacidades SAST integradas que se integram com seus respectivos fluxos de trabalho de merge request. ## Gerenciamento de Segredos com Federação OIDC Credenciais de longa duração armazenadas em plataformas CI/CD continuam sendo o vetor de ataque mais explorado em comprometimentos de pipelines. [GitHub Actions OIDC](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-cloud-providers) substitui segredos estáticos por tokens de curta duração emitidos pelo provedor de nuvem em tempo de execução. ```yaml # .github/workflows/deploy.yml name: Deploy to AWS on: push: branches: [main] jobs: deploy: runs-on: ubuntu-latest permissions: id-token: write # Required for OIDC contents: read steps: - uses: actions/checkout@v4 - name: Configure AWS credentials via OIDC uses: aws-actions/configure-aws-credentials@v4 with: role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsRole aws-region: us-east-1 # No AWS_ACCESS_KEY_ID or AWS_SECRET_ACCESS_KEY stored anywhere - name: Deploy to ECS run: aws ecs update-service --cluster prod --service api --force-new-deployment ``` A política de confiança do role AWS IAM restringe quais repositórios e branches podem assumir o role: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" }, "StringLike": { "token.actions.githubusercontent.com:sub": "repo:my-org/my-repo:ref:refs/heads/main" } } } ] } ``` A condição restringe a emissão de credenciais à branch `main` de um repositório específico. Azure e GCP oferecem capacidades de federação OIDC equivalentes. Para segredos que precisam existir, [HashiCorp Vault](https://www.vaultproject.io/) e opções cloud-native como AWS Secrets Manager fornecem rotação centralizada e registro de acessos. ## Segurança de Containers e Geração de SBOM Imagens de containers introduzem dependências além do código da aplicação. Imagens base, pacotes de sistema e ferramentas de build todos carregam vulnerabilidades potenciais. Escanear imagens durante o processo de build e gerar um Software Bill of Materials (SBOM) fornece visibilidade sobre a cadeia completa de dependências. ```yaml # GitLab CI container security container_scanning: stage: test image: registry.gitlab.com/gitlab-org/security-products/analyzers/container-scanning:7 variables: CS_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA CS_DOCKERFILE_PATH: Dockerfile script: - /analyzer run artifacts: reports: container_scanning: gl-container-scanning-report.json cyclonedx: gl-sbom.cdx.json ``` O artefato SBOM no formato CycloneDX permite que consumidores downstream verifiquem vulnerabilidades recém-divulgadas sem reconstruir. Frameworks de segurança de cadeia de suprimentos como SLSA exigem a geração de SBOM como controle de linha de base. ## Testes de Segurança Dinâmicos em Staging Ferramentas DAST testam aplicações em execução para detectar vulnerabilidades que a análise estática não consegue detectar, incluindo falhas de autenticação, vulnerabilidades de injeção e configurações incorretas de segurança. Executar DAST contra um ambiente de staging antes da implantação em produção detecta problemas que sobrevivem aos portões anteriores. ```yaml # .gitlab-ci.yml dast: stage: dast image: registry.gitlab.com/gitlab-org/security-products/analyzers/dast:5 variables: DAST_WEBSITE: https://staging.example.com DAST_AUTH_URL: https://staging.example.com/login DAST_USERNAME: $DAST_USER DAST_PASSWORD: $DAST_PASSWORD DAST_AUTH_VERIFICATION_URL: https://staging.example.com/dashboard script: - /analyze artifacts: reports: dast: gl-dast-report.json rules: - if: $CI_COMMIT_BRANCH == "main" ``` [OWASP ZAP](https://www.zaproxy.org/) fornece uma alternativa gratuita para equipes sem GitLab Ultimate. Varreduras autenticadas testam funcionalidades atrás de muros de login onde operações sensíveis tipicamente residem. Para [ambientes Kubernetes](/technologies/devops/interview-questions/kubernetes-basics), testes de segurança de API validam configurações de ingress e políticas de service mesh. ## Varredura de Segurança Infrastructure as Code Terraform, manifestos Kubernetes e charts Helm definem infraestrutura que os atacantes visam. A varredura de IaC detecta configurações incorretas antes que elas alcancem os ambientes de nuvem. ```yaml # Checkov IaC scanning in GitHub Actions iac-scan: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Run Checkov uses: bridgecrewio/checkov-action@v12 with: directory: terraform/ framework: terraform soft_fail: false output_format: sarif output_file_path: checkov.sarif - name: Upload SARIF uses: github/codeql-action/upload-sarif@v3 with: sarif_file: checkov.sarif ``` Checkov valida [configurações Terraform](/technologies/devops/interview-questions/terraform-basics) contra benchmarks de segurança incluindo CIS e SOC2. A saída SARIF se integra com a aba Security do GitHub para rastreamento unificado de vulnerabilidades. Equipes que usam [Ansible](/technologies/devops/interview-questions/ansible-configuration) podem adicionar ansible-lint com regras de segurança ao mesmo estágio do pipeline. ## Fortalecimento da Cadeia de Suprimentos do GitHub Actions Fixar actions em SHAs de commit completos previne ataques baseados em tags onde mantenedores ou contas comprometidas fazem force-push de versões maliciosas para tags existentes. A campanha Megalodon em maio de 2026 fez push de mais de 5.700 commits maliciosos através de milhares de repositórios em uma única janela de seis horas. ```yaml # Pin to commit SHA, not tag steps: - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2 # Avoid mutable tags like @v4 or @latest # Bad: uses: actions/checkout@v4 ``` Dependabot atualiza as actions fixadas por SHA quando novas versões são lançadas. O [OWASP DevSecOps Guideline](https://github.com/OWASP/DevSecOpsGuideline) recomenda controles adicionais: - Restringir permissões de workflow ao mínimo necessário usando blocos `permissions:` - Desabilitar triggers `pull_request_target` ou limitá-los a PRs rotuladas de colaboradores - Usar `GITHUB_TOKEN` com padrões somente leitura no nível da organização - Habilitar status checks obrigatórios e proteção de branch nas branches padrão ## Perguntas Comuns de Entrevista DevSecOps Os entrevistadores avaliam tanto a profundidade técnica quanto a experiência prática. Essas perguntas aparecem frequentemente em entrevistas de segurança DevOps. **P: Como prevenir que segredos sejam commitados em um repositório?** Hooks pre-commit com ferramentas como [detect-secrets](https://github.com/Yelp/detect-secrets) ou gitleaks escaneiam alterações staged antes do commit. Regras de push do lado do servidor no GitHub Enterprise ou GitLab bloqueiam commits contendo padrões que correspondem a formatos de segredos conhecidos. A varredura de segredos também deve ser executada no CI como backup, já que os desenvolvedores podem contornar hooks locais. **P: Explicar a diferença entre SAST, DAST e SCA.** SAST analisa código-fonte sem execução, encontrando bugs como padrões de injeção SQL e credenciais hardcoded. SCA identifica vulnerabilidades conhecidas em dependências comparando versões de pacotes com bancos de dados CVE. DAST testa aplicações em execução enviando requisições maliciosas e observando as respostas. Um pipeline maduro executa os três: SAST e SCA em cada PR, DAST contra staging antes de releases para produção. **P: O que é o princípio do menor privilégio em CI/CD?** Jobs de build devem ter apenas as permissões necessárias para completar sua tarefa específica. Um job que implanta para staging não precisa de credenciais de produção. A federação OIDC aplica isso emitindo credenciais com escopo para repositórios, branches e jobs de workflow específicos. O [OWASP CI/CD Top 10](https://owasp.org/www-project-top-10-ci-cd-security-risks/) lista gerenciamento inadequado de identidade e acesso como um risco principal porque jobs comprometidos com permissões excessivas expandem a superfície de ataque dramaticamente. **P: Como verificar a integridade de imagens de containers?** Assinaturas de confiança de conteúdo (Docker Content Trust, Sigstore cosign) fornecem verificação criptográfica de que as imagens foram construídas por pipelines confiáveis. Atestações SBOM documentam os componentes dentro das imagens. Admission controllers no Kubernetes rejeitam imagens não assinadas ou imagens com vulnerabilidades críticas conhecidas. A varredura de registry detecta vulnerabilidades que aparecem após o tempo de build. **P: Descrever um ataque de cadeia de suprimentos em CI/CD e como preveni-lo.** O ataque tj-actions/changed-files comprometeu uma GitHub Action amplamente utilizada, injetando código que exfiltrava segredos para endpoints controlados pelo atacante. As medidas de prevenção incluem: fixar actions em SHAs de commit em vez de tags, usar Dependabot para atualizar versões fixadas, restringir quais actions podem ser executadas via políticas no nível da organização, e monitorar execuções de workflow para conexões de rede inesperadas ou acesso a credenciais. ## Construindo um Roadmap DevSecOps para Entrevistas Técnicas Candidatos que demonstram pensamento estruturado sobre implementação de segurança se destacam. Uma implementação prática de DevSecOps prioriza primeiro controles de alto impacto e baixo esforço: - Habilitar varredura de segredos e proteção de branch imediatamente, já que ambos são gratuitos e bloqueiam os vetores de ataque mais comuns - Adicionar SAST e SCA às verificações de pull request no primeiro sprint, detectando vulnerabilidades antes da mesclagem - Migrar de credenciais estáticas para federação OIDC, eliminando os segredos mais perigosos das plataformas CI/CD - Implementar varredura de containers e geração de SBOM como parte dos builds de imagens - Implantar varredura de IaC para Terraform, Kubernetes e configuração de nuvem - Adicionar DAST para aplicações com autenticação ou manuseio de dados sensíveis - Estabelecer monitoramento de runtime com Falco ou equivalente para clusters Kubernetes em produção Os entrevistadores valorizam candidatos que reconhecem os trade-offs. A varredura de segurança adiciona latência ao pipeline. Falsos positivos criam fadiga de alertas. Uma prática DevSecOps madura ajusta limites, aceita riscos calculados com controles compensatórios, e mede continuamente o tempo médio de remediaçã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-2026-devsecops-interview