Checklist de segurança para pipelines CI/CD com runners self‑hosted e secrets management

Por Kevin Marcondes · Publicado em 11/10/2026 · 9 min de leitura

Este checklist de segurança para pipelines CI/CD com runners self‑hosted e secrets management foca em controles práticos: hardening de hosts, isolamento, políticas de acesso mínimo, gestão de segredos, cadeia de suprimentos e auditoria. Use como referência para reduzir riscos de vazamento, sequestro de runners e manipulação de artefatos em ambientes próprios.

Ameaças comuns em CI/CD self‑hosted: entenda o terreno

Runners self‑hosted dão controle e performance, mas ampliam a superfície de ataque. Ameaças típicas: vazamento de secrets em logs, jobs maliciosos, dependências comprometidas, invasão do host do runner e sequestro de credenciais de deploy. O primeiro passo é separar ambiente de build do de produção e adotar isolamento forte, com privilégios mínimos e rotinas de rotação de segredos.

Mapeie quem aciona pipelines, o que cada job acessa, para onde artefatos vão e quais redes são liberadas. Defina limites claros: o runner não deve ter acesso direto a bancos ou filas de produção sem controles adicionais e registros de auditoria.

Hardening do host do runner e rede: checklist essencial

Trate o host do runner como ativo sensível. Aplique hardening do sistema, atualizações automáticas e inventário de pacotes. Minimize a superfície: desabilite serviços desnecessários, ative firewall e limite portas abertas. Separe runners por sensibilidade (produção, homologação) em sub-redes distintas.

Reduza egress. Permita apenas destinos necessários: registries, mirrors, provedores de dependências, endpoints do CI e stores de secrets. Bloqueie entrada da Internet. Prefira NAT de saída, proxies autenticados e DNS interno com listas de permissão.

Para um reforço de base em servidores Linux, confira este guia prático de endurecimento: checklist de segurança para VPS Linux.

• Sistema atualizado e reinicializações controladas
• Firewall restritivo (deny by default) e logs de firewall
• Acesso SSH com chaves, MFA no bastion e sem root remoto
• Montagens temporárias com noexec,nosuid,nodev quando possível
• Monitoramento e alertas do runner (CPU, disco, processos)
• Backups e imagens douradas somente para templates de runner

Runners efêmeros, isolamento e privilégio mínimo

Runners efêmeros reduzem persistência de malware e rastros de dados. Suba um runner por job ou por lote pequeno e destrua após o término. Evite reutilizar diretórios de trabalho. Execute jobs como usuário sem privilégios, com controles de kernel (seccomp, AppArmor/SELinux) e cgroups para limitar recursos.

Se possível, isole cada job em containers ou VMs leves. Desabilite docker‑in‑docker privilegiado; prefira sockets limitados ou runtimes com políticas. Escopos e permissões dos tokens do CI devem ser mínimos e temporários.

Para arquitetura e automação de escala, veja: auto‑escalar runners self‑hosted no GitHub Actions.

• Runner por job ou curta duração
• Usuário sem privilégios; sem sudo no job
• Policies de segurança de container (seccomp, AppArmor)
• Limites de CPU/RAM/IO por job
• Tokens com escopo mínimo e validade curta
• Wipe seguro do workspace ao final do job

Secrets management: políticas, fluxo e controles de vazamento

Centralize segredos e reduza arquivos .env persistentes. Use secrets do CI, stores externos ou emissões temporárias via OIDC para obter credenciais sob demanda. Aplique rotação periódica, versionamento e trilhas de auditoria. No pipeline, mascare variáveis sensíveis, bloqueie echo e sanitize logs e artefatos.

Restrinja secrets por ambiente e branch. Evite passar segredos para jobs que não precisam. Prefira montar segredos em memória (tmpfs) e remova após uso. Faça varredura de repositórios e artefatos em busca de segredos acidentalmente commitados.

No mundo Docker, evite ARG/ENV com segredos em Dockerfiles. Injete apenas em tempo de build com escopo restrito e sem leak para camadas de imagem.

Cadeia de suprimentos: dependências, builds e assinatura

Sua imagem de base e suas dependências são parte do perímetro. Fixe versões, use checksums e bloqueie updates não revisados. Gere SBOM em cada build e armazene junto ao artefato. Escaneie dependências e imagens em busca de CVEs antes de prosseguir para deploy.

Assine imagens e artefatos e publique atestações de proveniência. Mantenha caches, mirrors e registries privados controlados. Trate o cache como não confiável: valide outputs. Para um registry privado e autenticado, veja: registry Docker privado com mirror em VPS.

Para acelerar builds sem relaxar controles, confira: BuildKit e cache remoto no CI.

• Fixar versões e checar integridade de downloads
• Gerar SBOM e armazenar com o artefato
• Assinar imagens/artefatos e validar na implantação
• Bloquear egress para repositórios não aprovados
• Escanear CVEs previamente e falhar o job em alto risco

Proteção de artefatos, logs e canais de deploy

Defina políticas de retenção e acesso a artefatos. Armazene em repositórios com trilha imutável e versionamento. Separe papéis: quem faz merge não deve poder alterar artefatos assinados. Em deploy, valide assinaturas e atestações antes de promover entre estágios.

Reduza sensibilidade dos logs: mascare variáveis e remova stack traces excessivos em jobs sensíveis. Limpe diretórios temporários ao final. Use contas de serviço dedicadas para CD, com permissões mínimas e janelas de tempo limitadas.

Para serviços internos expostos ao pipeline, use autenticação mútua entre serviços. Guia prático: mTLS no Docker Compose.

• Retenção mínima necessária, com WORM quando aplicável
• Assinatura verificada como gate de promoção
• Contas de serviço separadas por ambiente
• Mascaramento de logs e limpeza de workspaces
• Aprovações manuais para mudanças de alto risco

Auditoria contínua, testes e resposta a incidentes

Registre quem acionou o pipeline, hash do commit, ID do runner, versões de ferramentas, digest dos artefatos e decisões de política. Centralize logs com correlação entre etapas. Teste periodicamente recuperação de segredos e rotação de chaves.

Prepare runbooks de incidente para: vazamento de secrets, comprometimento de runner, dependência maliciosa e falha de assinatura. Tenha caminho de break‑glass controlado, com expiração curta e auditoria forte. Revise trimestralmente permissões e inventário de secrets.

• Coletar e reter logs de auditoria com integridade
• Testes de rotação de secrets e revogação de credenciais
• Runbooks com responsáveis e SLAs internos
• Revisões periódicas de IAM e varredura de repositórios

Checklist resumido para aplicar hoje

Use esta lista como ponto de partida. Adapte ao seu contexto e riscos. Priorize itens com maior impacto e menor esforço, e evolua em ciclos curtos com métricas de redução de exposição e incidentes evitados.

• Runners efêmeros, sem sudo, com políticas de kernel
• Host endurecido, firewall restritivo e egress mínimo
• Segredos centralizados, mascarados e rotacionados
• OIDC para credenciais temporárias quando possível
• Fixar versões, gerar SBOM e assinar artefatos
• Scans de CVEs bloqueando build em alto risco
• Artefatos em storage versionado e verificação de assinatura no deploy
• Contas de serviço com privilégio mínimo por ambiente
• Logs com mascaramento e rastreabilidade de ponta a ponta
• Runbooks, drills e revisão periódica de permissões

Perguntas frequentes

O que muda na segurança ao usar runners self‑hosted?

Você passa a proteger também o host e a rede do runner. É preciso hardening do sistema, isolamento por job, controle de egress, rotação de segredos e auditoria completa. Sem esses controles, o runner pode vazar secrets, ser sequestrado para deploys maliciosos ou expor sua infraestrutura interna.

Runners efêmeros realmente reduzem risco?

Sim. Descartar o runner após cada job elimina persistência de malware, reduz chance de vazamento por reuso de workspace e força configuração conhecida por template. Combinados a usuário sem privilégios e tokens curtos, diminuem a janela de ataque e o impacto de compromissos.

Como evitar vazamento de secrets nos logs do pipeline?

Ative mascaramento de variáveis, proíba comandos que imprimem valores sensíveis e revise scripts para não ecoar secrets. Injete segredos apenas no escopo necessário, use montagem em memória quando possível e faça varreduras automáticas em repositórios e artefatos para detectar exposições acidentais.

OIDC pode substituir arquivos .env no CI/CD?

Em muitos cenários, sim. OIDC permite emitir credenciais temporárias sob demanda, evitando chaves estáticas em .env. Com políticas de IAM bem definidas, você reduz vazamentos e facilita rotação. Ainda assim, alguns sistemas legados podem exigir integração gradual ou cofre central paralelo.

Qual a frequência ideal de rotação de segredos?

Depende do risco e do sistema. Como regra, rotacione segredos sensíveis em janelas curtas e sempre após incidentes ou mudanças de equipe. Automatize rotação quando possível e mantenha registro de versões para rollback seguro. Use credenciais temporárias para reduzir a necessidade de chaves longas.

Onde armazenar artefatos gerados pelo CI com segurança?

Use repositórios de artefatos com versionamento e controles de acesso. Prefira storages com imutabilidade (WORM) e vincule cada artefato a seu commit hash e SBOM. Exija validação de assinatura antes de promover entre ambientes, mantendo trilhas de auditoria e retenção adequada.

Veja também

• Guia: checklist de pré‑deploy e plano de rollback rápido para aplicações PHP em produção
• Guia: centralização de logs com Fluentd e Elasticsearch para aplicações PHP em VPS
• Guia: organizar migrations e rollbacks em PostgreSQL para equipes pequenas
• Checklist de segurança para VPS Linux antes de colocar serviços em produção: hardening, SSH, backups e monitoramento