Segurança que chega só na auditoria, seis meses depois, é cara e tarde demais. DevSecOps move isso pra dentro do pipeline: o problema aparece no merge request, quando ainda é barato arrumar.

O medo é sempre o mesmo: “isso vai travar meu deploy”. Não precisa. Veja como integrar segurança no GitLab CI sem virar gargalo.

As 3 camadas que pegam 80% dos problemas

1. SAST — analisa seu código em busca de padrões inseguros (SQL injection, XSS).
2. Scan de dependências — acha CVE conhecido nas libs que você importa.
3. Detecção de secrets — barra senha/token commitado por engano.

GitLab traz as três como templates prontos.

Pipeline base

# .gitlab-ci.yml
stages:
  - build
  - test
  - security
  - deploy

include:
  - template: Jobs/SAST.gitlab-ci.yml
  - template: Jobs/Dependency-Scanning.gitlab-ci.yml
  - template: Jobs/Secret-Detection.gitlab-ci.yml

build:
  stage: build
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA .

test:
  stage: test
  script:
    - npm ci
    - npm test

Só com o include acima, os jobs de segurança já rodam no estágio test por padrão e jogam os achados na aba Security do merge request.

O segredo pra não travar o time

Aqui está o pulo do gato: nem todo achado deve bloquear o merge. Configure o que falha e o que só avisa.

sast:
  stage: security
  rules:
    # roda em todo MR, mas não bloqueia por achado de severidade baixa
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  allow_failure: true

Política prática:

• Crítico / Alto → bloqueia o merge. Não passa.
• Médio / Baixo → aparece no MR como aviso, não bloqueia.

Assim o time vê tudo, mas só para de verdade quando é grave. Segurança vira informação, não burocracia.

Secrets: a vitória mais rápida

Secret commitado é o erro nº1 e o mais fácil de pegar:

secret_detection:
  stage: security
  allow_failure: false   # secret vazado SEMPRE bloqueia

Token de AWS no repositório é incidente, não aviso. Esse job vale o esforço sozinho.

Onde colocar no fluxo

push → build → test (unit) → security (SAST/deps/secrets) → deploy

Segurança roda em paralelo com o resto sempre que possível. O pipeline não fica mais lento de forma perceptível, e o feedback chega antes do código virar produção.

Erros comuns

• Bloquear tudo no dia 1 → time desativa o pipeline na primeira semana. Comece avisando, aperte aos poucos.
• Ignorar o relatório → scan que ninguém lê é teatro. Defina um responsável por triagem.
• Secret só no scan → adote também pre-commit hook local. Quanto mais cedo, melhor.

Próximo passo

DevSecOps no pipeline é cultura antes de ferramenta. A ferramenta é fácil — o difícil é calibrar o que bloqueia sem revoltar o time.

Quero te mostrar isso montado numa esteira completa, com Docker, deploy e observabilidade num projeto real: é o DevOps na Prática. Precisa de ajuda no seu pipeline agora? Fala comigo no WhatsApp.