Aplicação no Ciclo de Vida - CI/CD Seguro

Enquanto o intro.md explica porque os pipelines são críticos e que práticas devem ser aplicadas, este documento mostra como transformar essas prescrições em ações concretas ao longo do ciclo de vida de desenvolvimento e entrega.

O princípio orientador é simples e não negociável:

• o pipeline pode automatizar execução e produzir sinais;
• mas a organização só ganha segurança quando existe decisão humana atribuída, validação empírica e evidência auditável.

À medida que a automação se torna mais sofisticada, surgem riscos de processo adicionais: não-determinismo, “aprovação implícita” por outputs, evidência plausível sem execução real, fuga de contexto e diluição de responsabilidade.
Este documento operacionaliza essas preocupações sem “falar de tecnologia”: trata-as como controlos de engenharia e governação do pipeline.

---

🧭 Quando aplicar

A segurança em pipelines não acontece apenas quando algo corre mal - ela é parte do seu ADN desde o primeiro commit.
Sempre que se cria, altera, executa ou promove um pipeline, existem triggers que exigem controlos específicos:

Momento trigger	Objetivo de segurança	Papéis principais
Criação ou refactor do pipeline	Introduzir controlos base, garantir auditabilidade e evitar alterações “fora do PR”	Developers, DevOps / SRE
Alteração de regras de decisão (gates/thresholds)	Garantir separação entre sinal automático e decisão; evitar bypass implícito	AppSec Engineers, DevOps / SRE, GRC / Compliance
Alteração de tooling/infra (runners, permissões, segredos)	Rever isolamento, injeção de segredos, blast radius e não-repúdio	DevOps / SRE, AppSec Engineers
Introdução/atualização de validadores (scanners, testes, policies)	Aumentar cobertura e gates proporcionais ao risco; garantir evidência de execução real	Developers, AppSec Engineers, DevOps / SRE
Integração de serviços externos no pipeline	Tratar como dependência; minimizar contexto; mitigar risco de exfiltração	DevOps / SRE, AppSec Engineers, GRC / Compliance
Preparação de release / promoção a produção	Validar assinatura, proveniência, rastreabilidade e responsabilidade humana	DevOps / SRE, AppSec Engineers
Registo de exceção (bypass de gate)	Aprovação formal, prazos, compensações e reversão automática	GRC / Compliance, Auditores Internos, AppSec Engineers
Auditoria ou revisão periódica	Demonstrar rastreabilidade ponta-a-ponta e reprodutibilidade	GRC / Compliance, Auditores Internos, DevOps / SRE

---

👥 Quem executa cada ação

A responsabilidade em CI/CD é partilhada.
Um pipeline seguro resulta da soma de esforços: do programador que submete código com validações ativas, ao DevOps que endurece runners e segredos, até ao GRC que controla exceções e evidencia governação.

Ação operacional	Responsável	Apoio	Evidência/Artefactos
Definir/alterar pipeline versionado via PR	Developers	DevOps / SRE	ci-pipeline.yml, histórico de revisão
Definir regras de decisão (gates/thresholds) explícitas e binárias por risco	AppSec Engineers	DevOps / SRE, GRC / Compliance	Regras de gates, critérios publicados, registos de alteração
Endurecer runners (ephemerais, não-privilegiados, segregados)	DevOps / SRE	AppSec Engineers	Configuração de runners, imagens base, evidência de isolamento
Integrar validadores (SAST, secrets, IaC, containers, SBOM, DAST quando aplicável)	Developers	AppSec Engineers, DevOps / SRE	Relatórios + logs de execução + exit codes
Injeção segura de segredos (OIDC, TTL curto, masked logs)	DevOps / SRE	AppSec Engineers	Políticas de segredos, logs de acesso, evidência de rotação/TTL
Assinar artefactos e gerar proveniência	DevOps / SRE	AppSec Engineers	Assinaturas, proveniência, logs de verificação antes de promoção
Aprovar promoção/deploy (ações irreversíveis) com owner explícito	DevOps / SRE	AppSec Engineers (L2/L3), GRC (L3)	Registo nominal de aprovação, contexto e evidência associada
Registar e aprovar exceções (com prazo e compensações)	GRC / Compliance, Auditores Internos	AppSec Engineers	Registo formal de exceções e aprovações, TTL, plano compensatório
Garantir rastreabilidade commit→pipeline→release	DevOps / SRE	GRC / Compliance, Auditores Internos	Logs correlacionados, IDs, export imutável (quando aplicável)
Garantir higiene de logs/outputs (minimização de contexto sensível)	DevOps / SRE	AppSec Engineers	Política de logging, evidência de mascaramento/redação, revisão periódica

---

🧾 User Stories normalizadas

Cada prática é expressa como user story reutilizável, com critérios verificáveis, artefactos concretos e proporcionalidade por nível de risco.

Nota editorial: estas user stories assumem explicitamente que “output bonito” não é evidência e que sugestões nunca equivalem a decisão.
Sempre que existam sinais automáticos (scores, recomendações, flags), estes são tratados como inputs para uma decisão humana formal.

---

US-01 - Gestão segura de código fonte

Contexto.
Sem controlo sobre o repositório, qualquer pipeline é vulnerável.

📝User Story

História.
Como Developers, quero que todas as alterações ao repositório sejam protegidas por PR e revisão obrigatória, para garantir integridade.

Critérios de aceitação (BDD).

• Dado que existe um repositório protegido
  Quando submeto um PR para main
  Então só é aceite após revisão obrigatória e todos os checks concluídos com sucesso.
• Dado que ocorre um merge
  Quando são detetados conflitos ou alterações relevantes na superfície de ataque
  Então é exigida nova revisão e reexecução automática dos validadores definidos.

Checklist.

• Branch protection ativa
• Reviewer obrigatório
• Status checks configurados
• Proibido force push

🧾 Artefactos & evidências.
Políticas de branch protection; logs de revisão; histórico Git; auditoria de merges.

⚖️ Proporcionalidade.

Nível	Obrigatório?	Ajustes
L1	Sim	Revisão simples e build check obrigatório
L2	Sim	Revisor técnico + validação de segurança ativa
L3	Sim	Revisão dupla (code owner + AppSec) e bloqueio em falhas High

Integração no SDLC.

Fase	Trigger	Responsável	SLA
PR/MR	Submissão de PR para main	Developers	Antes do merge
Revisão	Conflito ou alteração relevante da superfície de ataque num merge	Developers	Antes do merge

---

US-02 - Design seguro dos pipelines (versionamento, determinismo e revisão)

Contexto.
Pipelines inseguros são alvos privilegiados de ataque - e pipelines não reprodutíveis destroem auditoria.

📝User Story

História.
Como DevOps / SRE, quero pipelines versionados e aprovados por PR, com comportamento determinístico, para evitar alterações não auditadas e resultados não reproduzíveis.

Critérios de aceitação (BDD).

• Dado que altero a definição do pipeline
  Quando submeto PR
  Então só é aceite após revisão por DevOps e AppSec (em L2/L3).
• Dado que o pipeline depende de configuração ou parâmetros
  Quando é executado
  Então a configuração efetiva usada é registada como evidência (sem dados sensíveis).
• Dado que há alteração de ferramentas, etapas ou regras de execução
  Quando o pipeline é modificado
  Então é criada nova versão rastreável e auditável (commit/hash + changelog no PR).

Checklist.

• ci-pipeline.yml versionado
• PR obrigatório
• Triggers explícitos
• Configuração efetiva registada (sem segredos)
• Histórico de versões mantido

🧾 Artefactos & evidências.
Histórico de commits; ficheiro ci-pipeline.yml; aprovação PR; logs de revisão; registo de configuração efetiva.

⚖️ Proporcionalidade.

Nível	Obrigatório?	Ajustes
L1	Sim	Versão única do pipeline com aprovação manual
L2	Sim	Versionamento e revisão obrigatória
L3	Sim	Controlo de alterações assinado e validação reforçada de proveniência

Integração no SDLC.

Fase	Trigger	Responsável	SLA
Criação/refactor	Alteração da definição do pipeline submetida em PR	DevOps / SRE	No PR
Execução	Execução do pipeline com configuração ou parâmetros	DevOps / SRE	A cada execução (configuração efetiva registada)
Revisão	Alteração de ferramentas, etapas ou regras de execução	DevOps / SRE	No PR (commit/hash + changelog)

---

US-03 - Scanners integrados (validação empírica obrigatória)

Contexto.
Detetar cedo é mais barato e eficaz - mas só conta se houver execução real.

📝User Story

História.
Como Developers, quero que o pipeline execute validadores de segurança com execução observável, para impedir falhas graves em produção.

Critérios de aceitação (BDD).

• Dado que submeto código
  Quando corre o pipeline
  Então os validadores obrigatórios são executados e produzem logs/artefactos rastreáveis.
• Dado que existem falhas críticas
  Quando os resultados são avaliados
  Então o merge/promoção é bloqueado de acordo com os gates definidos.
• Dado que é introduzido novo tipo de artefacto
  Quando o conjunto atual de validação não o cobre
  Então o AppSec define regra adicional e a mudança é versionada e aprovada.

Checklist.

• SAST ativo
• Secrets scanning ativo
• IaC scanning (quando aplicável)
• Logs/artefactos de execução guardados
• Falhas High bloqueiam merge (L2/L3)

🧾 Artefactos & evidências.
Relatórios de scanners; logs CI/CD; exit codes; registos de bloqueio; dashboards de vulnerabilidades.

⚖️ Proporcionalidade.

Nível	Obrigatório?	Ajustes
L1	Sim	Validação base (SAST, secrets)
L2	Sim	Inclusão de IaC e análise de dependências
L3	Sim	Validação completa incluindo containers e SBOM

Integração no SDLC.

Fase	Trigger	Responsável	SLA
CI/CD	Submissão de código e execução do pipeline	Developers	A cada execução do pipeline
Pré-promoção	Avaliação de resultados com falhas críticas	Developers	Bloqueio do merge/promoção no gate
Revisão	Novo tipo de artefacto não coberto pela validação atual	AppSec	Na aprovação da regra adicional versionada

---

US-04 - Gestão de segredos

Contexto.
Segredos estáticos expõem a organização - e logs descuidados tornam-se um canal de fuga.

📝User Story

História.
Como DevOps / SRE, quero segredos injetados por OIDC com TTL curto e outputs mascarados, para reduzir risco de abuso e exposição indireta.

Critérios de aceitação (BDD).

• Dado que o pipeline arranca
  Quando credenciais são necessárias
  Então são emitidas just-in-time, com TTL curto e sem exposição em logs.
• Dado que o token expira
  Quando é necessário novo acesso
  Então é gerado token temporário novo sem reutilização.

Checklist.

• OIDC configurado
• TTL curto
• Variáveis mascaradas
• Logging revisto para não expor contexto sensível

🧾 Artefactos & evidências.
Políticas de segredos; logs de acesso; configuração OIDC; evidência de TTL/rotação.

⚖️ Proporcionalidade.

Nível	Obrigatório?	Ajustes
L1	Opcional	Segredos armazenados encriptados + masking
L2	Sim	OIDC implementado com TTL controlado
L3	Sim	Tokens efémeros automáticos e rotação frequente

Integração no SDLC.

Fase	Trigger	Responsável	SLA
CI/CD	Arranque do pipeline com necessidade de credenciais	DevOps / SRE	Just-in-time, no arranque do job
Operação	Expiração do token e necessidade de novo acesso	DevOps / SRE	Na expiração, sem reutilização

---

US-05 - Isolamento de runners

Contexto.
Runners inseguros comprometem todo o ecossistema.

📝User Story

História.
Como DevOps / SRE, quero runners ephemerais e segregados, para reduzir persistência pós-compromisso e limitar blast radius.

Critérios de aceitação (BDD).

• Dado que um job termina
  Quando o runner encerra
  Então é destruído sem manter estado.
• Dado que há pipelines paralelos
  Quando são executados
  Então estão isolados por permissões, namespace e segmentação de rede.

Checklist.

• Runners efémeros
• Sem privilégios excessivos
• Segmentação de rede
• Sem estado persistente entre jobs

🧾 Artefactos & evidências.
Configuração de runners; logs de execução; registos de isolamento; scripts de provisionamento.

⚖️ Proporcionalidade.

Nível	Obrigatório?	Ajustes
L1	Opcional	Runners partilhados com limites e hardening
L2	Sim	Segregação de runners por projeto
L3	Sim	Runners efémeros + rede isolada + destruição automática

Integração no SDLC.

Fase	Trigger	Responsável	SLA
Provisionamento	Execução de pipelines paralelos	DevOps / SRE	A cada execução
Operação	Fim do job e encerramento do runner	DevOps / SRE	No encerramento do job

---

US-06 - Assinatura e proveniência

Contexto.
Artefactos não assinados perdem legitimidade - e artefactos sem proveniência enfraquecem auditoria e confiança.

📝User Story

História.
Como DevOps / SRE, quero que todos os artefactos sejam assinados e tenham proveniência validada, para garantir confiança e permitir verificação independente.

Critérios de aceitação (BDD).

• Dado que um artefacto é produzido
  Quando é promovido
  Então assinatura e proveniência são verificadas antes da promoção.
• Dado que falha verificação
  Quando a assinatura/proveniência não é válida
  Então o artefacto é rejeitado e é emitido alerta.

Checklist.

• Assinatura automática
• Proveniência gerada
• Verificação antes de release
• Rejeição automática em falha (L2/L3)

🧾 Artefactos & evidências.
Assinaturas digitais; ficheiros de proveniência; logs de promoção; auditoria de build.

Referência: Este US complementa o princípio de gerar SBOM por build, integrando assinatura e proveniência como artefactos de build.

⚖️ Proporcionalidade.

Nível	Obrigatório?	Ajustes
L1	Sim	Assinatura recomendada + verificação manual em releases
L2	Sim	Assinatura automática + verificação obrigatória
L3	Sim	Bloqueio automático + validações reforçadas de proveniência

Integração no SDLC.

Fase	Trigger	Responsável	SLA
Build/Promoção	Produção de artefacto e pedido de promoção	DevOps / SRE	Verificação antes da promoção
Promoção	Assinatura ou proveniência inválida	DevOps / SRE	Rejeição e alerta na verificação

---

US-07 - Gates por risco (separação sinal/decisão)

Contexto.
Nem todas as apps exigem o mesmo rigor - mas em nenhuma app um “sinal” substitui decisão.

📝User Story

História.
Como AppSec Engineers, quero gates distintos por L1–L3 e explicitamente binários, para aplicar segurança proporcional e evitar bypass implícito.

Critérios de aceitação (BDD).

• Dado que uma aplicação é L3
  Quando há falha High ou Critical
  Então o gate bloqueia a promoção e exige decisão humana formal para qualquer exceção.
• Dado que uma aplicação é L1
  Quando há falha Medium
  Então é registado alerta sem bloqueio, mas com rastreabilidade e backlog de remediação.
• Dado que existe um output automático (score/recomendação)
  Quando é apresentado
  Então é tratado apenas como input, nunca como aprovação.

Checklist.

• Política publicada
• Gates configurados
• Thresholds definidos
• Separação entre sinal e decisão documentada

🧾 Artefactos & evidências.
Políticas de gates; logs de bloqueio; registos de alteração de thresholds; evidência de decisão em exceções.

⚖️ Proporcionalidade.

Nível	Obrigatório?	Ajustes
L1	Sim	Bloqueio apenas em Critical
L2	Sim	Bloqueio High/Critical + aprovação AppSec para exceções
L3	Sim	Bloqueio automático + governança reforçada (incl. GRC em exceções)

Integração no SDLC.

Fase	Trigger	Responsável	SLA
Pré-promoção	Falha High ou Critical em aplicação L3	AppSec Engineers	Bloqueio no gate, antes da promoção
Pré-promoção	Falha Medium em aplicação L1	AppSec Engineers	Alerta no gate, sem bloqueio
Promoção	Apresentação de score/recomendação automática	AppSec Engineers	Na decisão de promoção

---

US-08 - Cobertura ampliada (containers e SBOM)

Contexto.
Cobertura limitada cria pontos cegos e fragiliza supply chain.

📝User Story

História.
Como AppSec Engineers, quero validação de containers e SBOM em pipelines, para cobrir supply chain e permitir rastreabilidade de componentes.

Critérios de aceitação (BDD).

• Dado que uma imagem é construída
  Quando corre o pipeline
  Então o SBOM é gerado e anexado ao artefacto.
• Dado que uma imagem base muda
  Quando vulnerabilidade é detetada
  Então é aberta tarefa de mitigação e o risco é rastreável ao release afetado.

Checklist.

• Container scanning ativo
• SBOM gerado
• Base images validadas
• Evidência de execução guardada

🧾 Artefactos & evidências.
Relatórios de scanning; SBOM; auditoria de imagens; logs de builds.

⚖️ Proporcionalidade.

Nível	Obrigatório?	Ajustes
L1	Opcional	Scans de imagens base periódicos
L2	Sim	SBOM obrigatório + validação de base images
L3	Sim	Scans contínuos + correlação de CVEs + bloqueios em risco crítico

Integração no SDLC.

Fase	Trigger	Responsável	SLA
Build	Construção de imagem	AppSec Engineers	A cada build, com SBOM anexado ao artefacto
Operação	Vulnerabilidade detetada em imagem base em uso	AppSec Engineers	Na deteção, com rastreio ao release afetado

---

US-09 - Rastreabilidade ponta-a-ponta (commit→pipeline→release)

Contexto.
Sem rastreio, auditoria é impossível - e investigação de incidentes torna-se especulativa.

📝User Story

História.
Como GRC / Compliance, quero rastrear commit→pipeline→release, para suportar auditorias e investigação de incidentes.

Critérios de aceitação (BDD).

• Dado que ocorre um incidente
  Quando analiso um release
  Então consigo traçar origem até commit e execução do pipeline.
• Dado que um auditor pede evidências
  Quando executo consulta
  Então o sistema exporta logs correlacionados e verificáveis (sem dados sensíveis).

Checklist.

• IDs de correlação
• Logs retidos
• Export imutável (quando aplicável)
• Ligação explícita entre artefactos e execução

🧾 Artefactos & evidências.
Logs de pipelines; dashboards; registos de auditoria; exports (imutáveis quando exigido).

⚖️ Proporcionalidade.

Nível	Obrigatório?	Ajustes
L1	Sim	Logs básicos armazenados 30 dias
L2	Sim	Retenção 90 dias + correlação commit-build
L3	Sim	Retenção ≥1 ano + exportação imutável + auditoria reforçada

Integração no SDLC.

Fase	Trigger	Responsável	SLA
Incidente	Análise de um release na sequência de um incidente	GRC / Compliance	Dentro da retenção: 30 dias (L1), 90 dias (L2), ≥1 ano (L3)
Auditoria	Pedido de evidências por auditor	GRC / Compliance	Export correlacionado dentro da retenção do nível

---

US-10 - Gestão de exceções (bypass controlado)

Contexto.
Exceções mal geridas tornam-se risco estrutural e normalizam bypass.

📝User Story

História.
Como GRC / Compliance, quero exceções registadas, aprovadas e temporárias, para evitar acumulação de dívida e manter governação.

Critérios de aceitação (BDD).

• Dado que uma exceção é pedida
  Quando é analisada
  Então só é aprovada com prazo, owner e compensações definidas.
• Dado que o prazo expira
  Quando não há renovação formal
  Então a exceção é removida e o pipeline volta ao modo normal de controlo.

Checklist.

• Owner registado
• Prazo definido
• Aprovação dupla (AppSec + GRC) em L2/L3
• Registo de compensações
• Reversão automática no fim do prazo

🧾 Artefactos & evidências.
Registo de exceções; logs de aprovação; relatórios de revisão; prazos automáticos no sistema de GRC.

⚖️ Proporcionalidade.

Nível	Obrigatório?	Ajustes
L1	Sim	Registo simples com aprovação única
L2	Sim	Aprovação dupla e prazo máximo (ex.: 60 dias)
L3	Sim	Revisão frequente + auditoria obrigatória

Integração no SDLC.

Fase	Trigger	Responsável	SLA
Exceção	Pedido de exceção submetido a análise	GRC / Compliance	Aprovação só com prazo, owner e compensações; prazo máximo definido em L2 (ex.: 60 dias)
Exceção	Expiração do prazo sem renovação formal	GRC / Compliance	Reversão automática no fim do prazo

---

US-11 - Testes de segurança dinâmicos (DAST)

Contexto.
Testes estáticos apenas cobrem parcialmente; DAST em staging valida comportamento real.

📝User Story

História.
Como AppSec Engineers, quero executar DAST em staging após deployment, para validar vulnerabilidades comportamentais antes de produção.

Critérios de aceitação (BDD).

• Dado que uma build é promovida a staging
  Quando inicia pipeline DAST
  Então são executadas análises relevantes e os resultados são rastreáveis ao commit/release.
• Dado que DAST encontra falha High
  Quando o resultado é disponibilizado
  Então bloqueia promoção a produção até correção validada.

Checklist.

• DAST integrado no pipeline
• Credenciais de teste segregadas
• Relatório correlacionado com commit
• Bloqueio automático em High/Critical (L2/L3)

🧾 Artefactos & evidências.
Relatórios DAST; logs de execução; evidências de correção; rastreabilidade.

⚖️ Proporcionalidade.

Nível	Obrigatório?	Ajustes
L1	Opcional	DAST manual periódico
L2	Sim	DAST em staging pré-release
L3	Sim	DAST contínuo + bloqueio automático + revalidação pós-correção

Integração no SDLC.

Fase	Trigger	Responsável	SLA
Staging	Promoção de build para staging	AppSec Engineers	A cada promoção para staging
Pré-promoção	Falha High reportada pelo DAST	AppSec Engineers	Bloqueio da promoção a produção até correção validada

---

US-12 - Métricas e conformidade organizacional

Contexto.
Sem visibilidade centralizada, risco acumula-se invisível.

📝User Story

História.
Como Gestão Executiva / CISO, quero visualizar métricas de CI/CD (cobertura, gates, exceções, bloqueios, MTTR), para decisão informada e ação corretiva.

Critérios de aceitação (BDD).

• Dado que o pipeline executa
  Quando ocorrem eventos (merge, bloqueio, exceção, promoção)
  Então são registados com timestamp, contexto e atores.
• Dado que consulto o dashboard
  Quando filtro por projeto/período/risco
  Então obtenho indicadores acionáveis e auditáveis.

Checklist.

• Eventos centralizados
• Dashboard com KPIs (cobertura, MTTR, compliance rate)
• Alertas em anomalias
• Relatórios periódicos para GRC

🧾 Artefactos & evidências.
Dashboard; logs centralizados; relatórios; alertas; evidência de retenção.

⚖️ Proporcionalidade.

Nível	Obrigatório?	Ajustes
L1	Opcional	Relatórios manuais periódicos
L2	Sim	Dashboard com KPIs principais, atualizado diariamente
L3	Sim	Dashboard quase em tempo real + alertas automáticos

Integração no SDLC.

Fase	Trigger	Responsável	SLA
Operação	Evento no pipeline (merge, bloqueio, exceção, promoção)	Gestão Executiva / CISO	Registo com timestamp, contexto e atores no momento do evento
Auditoria	Consulta ao dashboard por projeto, período ou risco	Gestão Executiva / CISO	Atualização diária (L2); quase em tempo real (L3)

---

US-13 - Validação de integridade de imagens base

Contexto.
Imagens base comprometidas propagam risco a todo o ecossistema.

📝User Story

História.
Como DevOps / SRE, quero validar integridade de imagens base (hash/assinatura/drift) e correlacionar com vulnerabilidades, para evitar supply chain comprometido.

Critérios de aceitação (BDD).

• Dado que uma imagem base é usada
  Quando o pipeline inicia
  Então o identificador esperado é validado contra fonte confiável.
• Dado que surge vulnerabilidade relevante
  Quando afeta imagens em uso
  Então é criado alerta e aberta ação de mitigação rastreável ao release.

Checklist.

• Hash/assinatura de imagens base registado
• Validação automática no pull
• Rejeição em mismatch (L2/L3)
• Correlação contínua com vulnerabilidades

🧾 Artefactos & evidências.
Registos de hashes/assinaturas; logs de validação; relatórios de drift; ações de mitigação.

⚖️ Proporcionalidade.

Nível	Obrigatório?	Ajustes
L1	Opcional	Validação manual periódica
L2	Sim	Validação automática no pull com logs
L3	Sim	Validação + assinatura + alertas automáticos em drift/vulnerabilidade

Integração no SDLC.

Fase	Trigger	Responsável	SLA
CI/CD	Arranque do pipeline com imagem base	DevOps / SRE	Validação no pull, antes do build
Operação	Vulnerabilidade relevante que afeta imagens em uso	DevOps / SRE	Alerta e ação de mitigação na deteção

---

🆕 User Stories adicionais (riscos de processo do CI/CD moderno)

As user stories seguintes tornam explícitas as preocupações de processo que, na prática, mais degradam a segurança quando a automação aumenta: não-determinismo, confusão sinal/decisão, evidência fraca, fuga de contexto e diluição de responsabilidade.

---

US-14 - Reprodutibilidade e determinismo do pipeline

Contexto.
Sem reprodutibilidade, não há auditoria nem investigação de incidentes.

📝User Story

História.
Como DevOps / SRE, quero que execuções do pipeline sejam reprodutíveis e determinísticas (na medida do possível), para permitir verificação independente e auditoria.

Critérios de aceitação (BDD).

• Dado que um build é executado
  Quando volto a executar o mesmo pipeline sobre o mesmo commit
  Então obtenho resultados equivalentes (ou divergências justificadas e registadas).
• Dado que existem parâmetros/configuração
  Quando o pipeline corre
  Então a configuração efetiva usada é registada como evidência (sem segredos).

Checklist.

• Definição do pipeline versionada
• Dependências e versões relevantes estabilizadas/identificadas
• Configuração efetiva registada
• Divergências documentadas quando inevitáveis

🧾 Artefactos & evidências.
Execução rastreável (logs + config efetiva); ligação a commit; registos de divergência; artefactos produzidos.

⚖️ Proporcionalidade.

Nível	Obrigatório?	Ajustes
L1	Sim	Reprodutibilidade “boa-fé” com logging suficiente
L2	Sim	Reprodutibilidade como requisito; validação periódica
L3	Sim	Reprodutibilidade obrigatória + auditoria reforçada e retenção prolongada

Integração no SDLC.

Fase	Trigger	Responsável	SLA
Execução	Reexecução do mesmo pipeline sobre o mesmo commit	DevOps / SRE	Resultado equivalente, ou divergência justificada e registada
Execução	Execução com parâmetros ou configuração	DevOps / SRE	Configuração efetiva registada a cada execução

---

US-15 - Separação formal entre sinal automático e decisão de promoção

Contexto.
Um “score verde” não é uma decisão; uma decisão exige owner e evidência.

📝User Story

História.
Como AppSec Engineers, quero que qualquer recomendação/score/flag seja formalmente classificada como sinal, e que a promoção exija decisão humana explícita, para evitar aprovação implícita.

Critérios de aceitação (BDD).

• Dado que o pipeline produz sinais (scores/recomendações)
  Quando a promoção é considerada
  Então a decisão é registada com owner humano e evidência associada.
• Dado que alguém tenta promover sem decisão formal
  Quando o pipeline avalia a ação
  Então bloqueia e exige registo nominal de aprovação.

Checklist.

• Distinção “sinal” vs “decisão” documentada
• Promoção exige aprovação nominal
• Registo inclui evidência referenciada
• Bloqueio automático a promoções “sem owner”

🧾 Artefactos & evidências.
Registo de aprovação; evidência associada; logs de bloqueio; política publicada.

⚖️ Proporcionalidade.

Nível	Obrigatório?	Ajustes
L1	Sim	Aprovação nominal para produção
L2	Sim	Aprovação nominal + regra de separação de funções
L3	Sim	Aprovação nominal + auditoria reforçada + regra estrACI (approval control integrity)

Integração no SDLC.

Fase	Trigger	Responsável	SLA
Promoção	Promoção considerada a partir de sinais (scores, recomendações)	AppSec Engineers	Decisão nominal registada antes da promoção
Promoção	Tentativa de promoção sem decisão formal	AppSec Engineers	Bloqueio até registo nominal de aprovação

---

US-16 - Evidência empírica obrigatória (anti-“relatórios sem execução”)

Contexto.
Resultados plausíveis não substituem execução real.

📝User Story

História.
Como GRC / Compliance, quero que qualquer evidência de controlo em CI/CD seja baseada em execução observável (logs, exit codes, artefactos), para impedir conformidade aparente sem validação real.

Critérios de aceitação (BDD).

• Dado que existe um relatório de validação
  Quando é usado como evidência
  Então contém referência verificável à execução (job/run id, logs, artefactos).
• Dado que não existe execução observável
  Quando alguém tenta registar um resultado como evidência
  Então é rejeitado como “não verificável”.

Checklist.

• Evidência liga a uma execução real
• Logs e exit codes disponíveis
• Artefactos preservados conforme retenção
• Rejeição de evidência não verificável

🧾 Artefactos & evidências.
Run IDs; logs; exit codes; artefactos; política de evidência.

⚖️ Proporcionalidade.

Nível	Obrigatório?	Ajustes
L1	Sim	Evidência mínima por execução
L2	Sim	Evidência obrigatória + retenção reforçada
L3	Sim	Evidência obrigatória + export imutável e auditoria

Integração no SDLC.

Fase	Trigger	Responsável	SLA
Auditoria	Uso de um relatório de validação como evidência	GRC / Compliance	Referência verificável à execução (run id, logs, artefactos) no registo
Auditoria	Registo de resultado sem execução observável	GRC / Compliance	Rejeição imediata como «não verificável»

---

US-17 - Contenção de contexto e higiene de logs/outputs

Contexto.
O pipeline “vê” tudo - logo, é onde a fuga de contexto é mais provável.

📝User Story

História.
Como DevOps / SRE, quero que logs e outputs do pipeline sejam minimizados e higienizados, para impedir exposição de segredos, dados sensíveis ou propriedade intelectual.

Critérios de aceitação (BDD).

• Dado que o pipeline executa
  Quando gera logs
  Então segredos e identificadores sensíveis são mascarados/redigidos por defeito.
• Dado que é necessário debug
  Quando é ativado temporariamente
  Então exige aprovação, é limitado no tempo e produz evidência de desativação.

Checklist.

• Política de logging publicada
• Masking/redação ativa por defeito
• Debug temporário controlado e auditável
• Revisão periódica de logs e configurações

🧾 Artefactos & evidências.
Configuração de logging; evidência de masking; registos de ativação/desativação de debug; relatórios de revisão.

⚖️ Proporcionalidade.

Nível	Obrigatório?	Ajustes
L1	Sim	Masking básico + revisão pontual
L2	Sim	Masking + controlo formal de debug
L3	Sim	Controlo formal + auditoria + retenção e export conforme exigência

Integração no SDLC.

Fase	Trigger	Responsável	SLA
CI/CD	Geração de logs pelo pipeline	DevOps / SRE	Masking/redação por defeito, a cada execução
Operação	Ativação temporária de debug	DevOps / SRE	Aprovação prévia, janela limitada no tempo e evidência de desativação

---

US-18 - Não-repúdio e ownership de promoções (ações irreversíveis)

Contexto.
Se ninguém “assina” a promoção, ninguém responde pelo incidente.

📝User Story

História.
Como DevOps / SRE, quero que qualquer promoção para produção tenha owner humano explícito e registo de decisão, para garantir não-repúdio e responsabilização.

Critérios de aceitação (BDD).

• Dado que uma promoção para produção é solicitada
  Quando é executada
  Então existe registo nominal de aprovação e contexto de decisão (evidência referenciada).
• Dado que não existe owner
  Quando alguém tenta promover
  Então o pipeline bloqueia a ação.

Checklist.

• Promoção exige owner humano
• Registo nominal e timestamp
• Evidência referenciada (runs, artefactos, relatórios)
• Bloqueio a promoções sem registo

🧾 Artefactos & evidências.
Registo de aprovação; logs do pipeline; evidência associada; trilho de auditoria.

⚖️ Proporcionalidade.

Nível	Obrigatório?	Ajustes
L1	Sim	Aprovação nominal para produção
L2	Sim	Aprovação nominal + separação de funções
L3	Sim	Aprovação nominal + auditoria reforçada e retenção prolongada

Integração no SDLC.

Fase	Trigger	Responsável	SLA
Produção	Promoção para produção executada	DevOps / SRE	Registo nominal e timestamp no momento da promoção
Produção	Tentativa de promoção sem owner humano	DevOps / SRE	Bloqueio imediato da ação

---

US-19 - Agentes AI como principals na pipeline

Contexto. A US-04 estabelece o padrão para segredos no pipeline: OIDC, TTL curto, sem credenciais long-lived. Quando o pipeline passa a ser operado por agentes AI — Claude Code a criar PRs e accionar workflows, Copilot Workspace a fazer merges, agentes próprios construídos sobre SDKs a executar deploys — esses agentes tornam-se novos principals não-humanos com acesso a recursos sensíveis. O princípio é o mesmo da US-04; o que muda é que o principal já não é um runner CI tradicional, e os requisitos de auditoria e scoping têm de ser ajustados à nova realidade.

📝User Story

História. Como DevOps / SRE e AppSec, quero que os agentes AI que operam o pipeline recebam credenciais via workload identity efémera (OIDC) com scopes per-tool e TTL ≤ 1h, e que cada tool invocation gere audit event estruturado, para garantir auditabilidade, revogabilidade e least privilege equivalentes aos runners CI clássicos.

Critérios de aceitação (BDD).

• Dado que um agente AI vai operar no pipeline em nível A1+ Quando se autentica para invocar uma tool (ex.: gh pr create, kubectl apply, npm publish) Então recebe credenciais via OIDC com scope mínimo declarado no mandate (REQ-AGN-001), TTL ≤ 1h, sem reuso de identidade humana
• Dado que o agente invoca uma tool destrutiva (destructive/external na allowlist) Quando opera em nível A2+ Então emite intent event (REQ-AGN-004) antes da invocação, e a tool call gera audit event completo
• Dado que o kill-switch (REQ-AGN-003) é accionado Quando ocorre revogação de credenciais Então as credenciais do agente ficam inválidas em segundos e a sessão é terminada
• Dado que existe divergência entre intent declarado e acção real Quando a divergência é detectada Então o sinal aterra como incidente IR (Cap. 12) e o mandate é revisto

Checklist.

• Identidade workload dedicada por agente e por ambiente (sem reuso de credenciais humanas nem cross-env)
• Scopes declarados no mandate aplicados na infra (não apenas no documento) — ex.: gh:pr:write mas não gh:repo:delete
• TTL das credenciais ≤ 1h; sem chaves long-lived (cross-link com US-04)
• Audit event por tool invocation com timestamp, agent_id, session_id, mandate_ref, autonomy_level, tool, tool_version, args (PII redactada), intent_event_ref, outcome, external_effect
• Kill-switch operacional: revogação de credenciais + terminação de runtime + isolamento de namespace + alerta on-call
• Kill-switch exercitado em sandbox/staging com cadência conforme nível de autonomia (trimestral A3, mensal A4)
• Secret scanning + diff review sobre skill files / agent files / rules que dirigem o agente (cross-link Policy 15 §2)

🧾 Artefactos & evidências.

• Configuração OIDC / workload identity (IaC) por agente e ambiente
• Registo de mandate_ref em audit trail de cada tool invocation
• Logs estruturados de intent events + tool invocation audit events
• Log do exercício do kill-switch (timestamp + cronómetro + outcome)
• Evidência de secret scanning sobre prompts/skills (cross-link Policy 15)

⚖️ Proporcionalidade.

Nível	Obrigatório?	Ajustes
L1	Sim para A1+	OIDC obrigatório; A2+ tipicamente fora de produção
L2	Sim para A1+	OIDC + audit completo + intent events em A2+; kill-switch exercitado trimestralmente em A3
L3	Sim para A1+	OIDC + audit completo + intent events em A2+ + kill-switch exercitado mensalmente em A4; revisão appsec independente

Integração no SDLC.

Fase	Trigger	Responsável	SLA
Onboarding do agente	Activação do mandate (Policy 38)	devops + appsec	Antes do primeiro tool call
Operação	Cada tool invocation	Agente (com audit automático)	Real-time
Revisão	review_cadence do mandate	appsec	Conforme cadência

Ligações úteis.

• 🔗 Catálogo REQ-AGN-* (Cap. 02)
• 🔗 ARC-015 — agente como principal (Cap. 04)
• 🔗 US-04 — Gestão de segredos (padrão herdado)
• 🔗 Policy 18 — Gestão de Segredos (anexo agentes)
• 🔗 Policy 38 — Mandates de Agentes AI

---

US-20 - Identidade empresarial no SCM e assinatura de commits/tags

Quem escreve no repositório tem de ser identificável, autorizado e não-repudiável.

Contexto. O CIC-001 exige pipelines como código sujeitos a revisão e o CIC-002 restringe os triggers a fontes autorizadas (branches protegidas, tags assinadas, merges aprovados). Sem acesso de escrita granular ancorado em identidade empresarial (SSO/RBAC) e sem assinatura criptográfica de commits/tags, a proteção de branch da US-01 protege o fluxo mas não garante quem o originou — e a autorização de trigger por tag perde valor se a tag não for verificável.

📝User Story

História.
Como DevOps / SRE e AppSec Engineers, quero que o acesso de escrita ao SCM seja granular por branch/projeto através de identidade empresarial (SSO/RBAC) e que aplicações L3 exijam assinatura verificada de commits e tags, para garantir autorização mínima e não-repúdio na origem do pipeline.

Critérios de aceitação (BDD).

• Dado que um colaborador necessita de escrever num branch protegido
  Quando o acesso é concedido
  Então é mediado por SSO/RBAC com âmbito mínimo por branch/projeto, sem contas partilhadas nem permissões herdadas em excesso.
• Dado que uma aplicação é L3
  Quando um commit ou tag entra no fluxo de promoção
  Então a assinatura é verificada e, em falha, o trigger é recusado e registado.
• Dado que um trigger é desencadeado por uma tag
  Quando a tag não está assinada por identidade autorizada
  Então a execução é bloqueada como fonte não confiável.

Checklist.

• Acesso de escrita granular por branch/projeto via SSO/RBAC
• Sem contas partilhadas nem tokens pessoais long-lived para escrita
• Assinatura de commits/tags verificada em L3
• Falha de assinatura recusa o trigger e gera registo

🧾 Artefactos & evidências. Matriz de RBAC do SCM; configuração SSO; política de branch protection; registos de verificação de assinatura; logs de triggers recusados.

⚖️ Proporcionalidade.

L1	L2	L3
Identidade empresarial no SCM; RBAC básico por projeto	RBAC granular por branch; assinatura de tags recomendada	RBAC granular + assinatura de commits e tags obrigatória e verificada no pipeline

Integração no SDLC.

Fase	Trigger	Responsável	SLA
Onboarding/offboarding	Concessão ou revogação de acesso ao SCM	devops + appsec	Na alteração de acesso
Promoção	Cada trigger por commit/tag	Pipeline (verificação automática)	Real-time
Revisão	Auditoria periódica de acessos	grc	Semestral

Ligações úteis.

• 🔗 Catálogo CIC-001/CIC-002 (Cap. 07)
• 🔗 Design Seguro dos Pipelines
• 🔗 US-01 — Gestão segura de código fonte

---

US-21 - Separação CI/CD, build/test/deploy e templates versionados

Cada fase do pipeline tem privilégios próprios; cruzá-los é convidar o escalonamento.

Contexto. O CIC-008 exige jobs distintos para build, test e deploy, sem permissões cruzadas e com âmbito de credenciais por stage. O checklist acrescenta a separação funcional entre CI e CD e a reutilização de templates de pipeline versionados. A US-02 garante o pipeline como código versionado, mas não impõe a fronteira de privilégios entre fases — um job de test com credenciais de deploy anula a separação na prática.

📝User Story

História.
Como DevOps / SRE, quero pipelines com CI e CD separados por função, fases build/test/deploy em jobs distintos sem permissões cruzadas, e templates reutilizáveis versionados, para limitar o blast radius de cada fase e tornar a configuração efetiva auditável.

Critérios de aceitação (BDD).

• Dado que um job de build ou test é executado
  Quando requer credenciais
  Então recebe apenas o âmbito da sua fase, sem acesso a credenciais de deploy/produção.
• Dado que o pipeline reutiliza lógica comum
  Quando essa lógica é alterada
  Então vive num template versionado sob PR, e a configuração efetiva da execução é registada como evidência.
• Dado que existe uma fase de promoção (CD)
  Quando é acionada
  Então está separada do fluxo de integração (CI) por função e identidade, sem permissões herdadas entre ambos.

Checklist.

• CI e CD separados por função e identidade
• Jobs distintos para build, test e deploy
• Âmbito de credenciais por stage documentado e enforced
• Templates de pipeline reutilizáveis e versionados sob PR

🧾 Artefactos & evidências. Definição do pipeline com stages separados; templates versionados; matriz de credenciais por stage; registo da configuração efetiva; logs de execução por fase.

⚖️ Proporcionalidade.

L1	L2	L3
Fases logicamente distintas; templates versionados	CI/CD separados + âmbito de credenciais por stage	Separação reforçada com identidades dedicadas por stage e ausência verificada de permissões cruzadas

Integração no SDLC.

Fase	Trigger	Responsável	SLA
Criação/refactor	Alteração da estrutura do pipeline	devops	No PR
Revisão	Alteração de templates ou credenciais de stage	appsec + devops	No PR
Auditoria	Revisão periódica de permissões por stage	grc	Semestral

Ligações úteis.

• 🔗 Catálogo CIC-008 (Cap. 07)
• 🔗 Design Seguro dos Pipelines
• 🔗 US-02 — Design seguro dos pipelines

---

US-22 - Proteção contra escalonamento de privilégios em runners

Um job com acesso ao Docker socket tem controlo efetivo do host.

Contexto. O CIC-010 (L3) exige isolamento forte de runners — containers efémeros ou VMs descartáveis — sem acesso ao Docker socket por jobs não privilegiados, sem capacidades de escalonamento de privilégios e com logs de tentativas bloqueadas. A US-05 (isolamento de runners) cobre efemeridade e segmentação, mas não explicita a interdição de privesc nem a evidência de bloqueio, que o checklist trata como controlo próprio.

📝User Story

História.
Como DevOps / SRE, quero que os runners não exponham o Docker socket a jobs não privilegiados nem permitam escalonamento de privilégios, com registo das tentativas bloqueadas, para impedir comprometimento do host a partir de um job do pipeline.

Critérios de aceitação (BDD).

• Dado que um job não privilegiado é executado
  Quando tenta aceder ao Docker socket ou a capacidades privilegiadas
  Então o acesso é negado e a tentativa é registada.
• Dado que uma aplicação é L3
  Quando o runner é provisionado
  Então corre em isolamento forte (container efémero ou VM descartável) sem capacidades de privesc.
• Dado que ocorre uma tentativa de escalonamento
  Quando é detetada
  Então gera evidência auditável e alerta para resposta.

Checklist.

• Sem acesso ao Docker socket por jobs não privilegiados
• Sem capacidades de escalonamento de privilégios nos runners
• Isolamento forte (efémero/descartável) em L3
• Logs de tentativas bloqueadas disponíveis

🧾 Artefactos & evidências. Configuração de runners (sem socket exposto); políticas de capacidades/securityContext; logs de tentativas bloqueadas; evidência de efemeridade.

⚖️ Proporcionalidade.

L1	L2	L3
Hardening base; sem privilégios desnecessários	Runners segregados sem socket exposto a jobs não privilegiados	Isolamento forte (efémero/descartável) + interdição de privesc + logs de bloqueio verificados

Integração no SDLC.

Fase	Trigger	Responsável	SLA
Provisionamento	Criação/alteração de runners	devops	No PR de infra
Operação	Tentativa de acesso privilegiado	Runner (deteção automática)	Real-time
Revisão	Auditoria de configuração de runners	appsec	Semestral

Ligações úteis.

• 🔗 Catálogo CIC-006/CIC-010 (Cap. 07)
• 🔗 Isolamento e Proteção de Runners
• 🔗 US-05 — Isolamento de runners

---

US-23 - Custódia de artefactos, visibilidade de exceção e integrações externas

O que se guarda, por onde transita e o que se liga ao pipeline é tudo superfície de ataque.

Contexto. Três prescrições convergem na fronteira do pipeline: o CIC-007 exige armazenamento e transporte seguros de artefactos com proveniência verificável e deteção de manipulação; o checklist exige que as exceções a controlos sejam sinalizadas visivelmente no pipeline (não apenas registadas — US-10); e o intro trata qualquer sistema externo (scanners, registries, serviços) como dependência de supply chain e potencial canal de exfiltração. A US-06 cobre assinatura/proveniência, mas não a custódia segura nem a integração externa minimizada.

📝User Story

História.
Como DevOps / SRE e AppSec Engineers, quero artefactos armazenados e transportados de forma segura com deteção de manipulação, exceções sinalizadas visivelmente no pipeline, e integrações externas tratadas como dependências de supply chain com contexto minimizado, para preservar integridade na cadeia de entrega e impedir exfiltração silenciosa.

Critérios de aceitação (BDD).

• Dado que um artefacto assinado é armazenado ou transportado
  Quando é consumido a jusante
  Então a integridade é verificada e a manipulação é detetada antes da promoção.
• Dado que um gate é alvo de exceção (bypass)
  Quando o pipeline executa
  Então a exceção é sinalizada de forma visível na execução, além de registada formalmente.
• Dado que o pipeline integra um serviço externo
  Quando é configurado
  Então é tratado como dependência (proveniência/confiança avaliada) e recebe apenas o contexto mínimo necessário.

Checklist.

• Armazenamento/transporte de artefactos seguros com deteção de manipulação
• Verificação de integridade/proveniência antes da promoção
• Exceções a gates sinalizadas visivelmente na execução do pipeline
• Integrações externas tratadas como dependências com contexto mínimo

🧾 Artefactos & evidências. Configuração de artifact store (controlo de acesso/transporte); registos de verificação de integridade; sinalização de exceção nos logs/UI da execução; inventário de integrações externas e respetivo âmbito de contexto.

⚖️ Proporcionalidade.

L1	L2	L3
Armazenamento controlado; exceção registada	Transporte seguro + deteção de manipulação + exceção sinalizada na execução	Custódia reforçada + verificação obrigatória downstream + integrações externas auditadas e contexto minimizado

Integração no SDLC.

Fase	Trigger	Responsável	SLA
Build/Promoção	Produção e consumo de artefactos	devops	A cada promoção
Operação	Registo/aplicação de exceção a gate	appsec + grc	No pedido de exceção
Integração	Adição/alteração de serviço externo	devops + appsec	No PR de integração

Ligações úteis.

• 🔗 Catálogo CIC-007 (Cap. 07)
• 🔗 Integridade e Proveniência de Artefactos
• 🔗 Excepções e Visibilidade em CI/CD
• 🔗 US-06 — Assinatura e proveniência
• 🔗 US-10 — Gestão de exceções (bypass controlado)

---

📦 Artefactos esperados

Cada prática deixa pegadas técnicas. Sem elas, não há prova de conformidade:

Artefacto / Evidência	Dono	Observações
ci-pipeline.yml	Developers	Versionado via PR (US-01, US-02)
Registo de configuração efetiva (sem segredos)	DevOps / SRE	Suporta reprodutibilidade (US-02, US-14)
Regras de gates/thresholds publicadas	AppSec Engineers	Separação sinal/decisão (US-07, US-15)
Logs + exit codes + artefactos de execução	DevOps / SRE	Evidência empírica (US-03, US-16)
Assinaturas + proveniência	DevOps / SRE	Verificação antes de promoção (US-06)
Relatórios de validadores (SAST, secrets, etc.)	Developers / AppSec Engineers	Sempre ligados a execução real (US-03, US-16)
SBOM por build	AppSec Engineers	Anexado ao artefacto (US-08)
Registo de exceções (TTL, compensações, approvals)	GRC / Compliance	Governação de bypass (US-10)
Logs correlacionados commit→pipeline→release	DevOps / SRE	Rastreabilidade auditável (US-09)
Política e evidência de higiene de logs	DevOps / SRE	Minimização de contexto (US-17)
Registos nominais de promoção/deploy	DevOps / SRE	Não-repúdio (US-18)
Dashboard de métricas e eventos	Gestão Executiva / CISO	Visibilidade organizacional (US-12)

---

⚖️ Matriz de proporcionalidade L1–L3

Nem todas as apps exigem o mesmo nível de rigor.
A matriz assegura que o esforço é proporcional ao risco sem nunca comprometer: decisão humana, evidência empírica e rastreabilidade.

Categoria	L1 (baixo)	L2 (médio)	L3 (crítico)
Branches/PR	1 reviewer + build check	Reviewer + validação de segurança	≥2 reviewers + code owners + AppSec
Determinismo	Logging suficiente	Reprodutibilidade como requisito	Reprodutibilidade + auditoria reforçada
Sinal vs decisão	Aprovação nominal para produção	Aprovação nominal + separação de funções	Aprovação nominal + controlo reforçado + auditoria
Evidência empírica	Logs básicos + artefactos chave	Logs + exit codes + retenção reforçada	Evidência completa + export imutável (quando exigido)
Scanners	SAST + secrets	+ IaC + dependências	+ containers + SBOM + cobertura alargada
Segredos	Masking + armazenamento seguro	OIDC preferido + TTL controlado	OIDC obrigatório + TTL curto + rotação frequente
Runners	Partilhados com hardening	Segregados por projeto	Efémeros + segmentação de rede + destruição automática
Artefactos	Assinatura recomendada	Assinatura + verificação obrigatória	Bloqueio automático em falha + proveniência reforçada
Exceções	Registo simples	Aprovação dupla + TTL	Aprovação dupla + revisão frequente + auditoria
Rastreabilidade	Logs 30 dias	Logs 90 dias + correlação commit-build	≥1 ano + export imutável + dashboards
DAST	Manual periódico	Em staging pré-release	Contínuo + bloqueio automático
Métricas	Relatórios manuais	Dashboard diário	Quase tempo real + alertas

---

🏁 Recomendações finais

A segurança de pipelines não é opcional: é o mecanismo de confiança de toda a entrega contínua.

• Versiona e revê o pipeline como código - e exige determinismo suficiente para auditoria.
• Define gates binários e governáveis - e nunca confundas sinais automáticos com decisões.
• Exige evidência empírica - logs, exit codes e artefactos, não apenas relatórios.
• Protege segredos e minimiza contexto - o pipeline é um ponto privilegiado de exfiltração.
• Atribui ownership às ações irreversíveis - promoções sem owner são um risco estrutural.
• Controla exceções com TTL e compensações - bypass só existe quando é governado.

Um CI/CD seguro é o garante silencioso de que tudo o que chega a produção é íntegro, verificável, rastreável e assumido por responsáveis reais.