GCP

Secure Builds com Cloud Build: bloqueando imagens vulneraveis antes do Artifact Registry

Engineering Handbook - Capitulo 08

Iury Coelho

18 de jul. de 202625 min de leitura

GCP Cloud Build DevSecOps

Secure Builds com Cloud Build: bloqueando imagens vulneráveis antes do Artifact Registry

Google Cloud Master Journey 2026
Engineering Handbook · Capítulo 08

Como transformei o scan de vulnerabilidades em um security gate de CI/CD usando Cloud Build, Artifact Registry e Artifact Analysis.

Secure Builds com Cloud Build

Este artigo faz parte da série Google Cloud Master Journey 2026, em que estou transformando laboratórios práticos em capítulos de um Engineering Handbook sobre Cloud Engineering, DevSecOps, arquitetura e segurança.

A proposta não é apenas registrar comandos ou badges. Quero transformar cada laboratório em um material que responda perguntas de engenharia:

qual risco essa tecnologia reduz;
em que momento do pipeline o controle deve agir;
quais dados o scanner realmente analisa;
como um resultado de vulnerabilidade vira uma decisão automática;
quando o build deve falhar;
o que muda entre laboratório e produção;
quais limitações permanecem mesmo depois de adicionar um scanner;
como integrar esse controle à cadeia de confiança construída no capítulo anterior.

Neste capítulo, o tema é segurança do processo de build com Cloud Build, Artifact Registry e Artifact Analysis.

O que vamos construir

O laboratório usado como base foi Secure Builds with Cloud Build (GSP1184).

Durante a prática, construí um pipeline que:

cria uma imagem de contêiner com Cloud Build;
armazena a imagem no Artifact Registry;
dispara scan automático após o push;
executa On-Demand Scanning antes da publicação;
consulta vulnerabilidades por severidade;
interrompe o pipeline quando encontra vulnerabilidade CRITICAL;
substitui uma imagem base vulnerável;
executa novamente o mesmo security gate;
permite o push somente quando a política é atendida.

flowchart LR Dev[Desenvolvedor] --> Source[Código + Dockerfile] Source --> Build[Cloud Build] Build --> Scan[On-Demand Scan] Scan --> Gate{Existe CRITICAL?} Gate -->|Sim| Fail[Build falha] Gate -->|Não| Tag[Tag good] Tag --> Registry[Artifact Registry] Registry --> Auto[Scan automático contínuo]

A ideia central é simples:

Uma imagem não deve chegar ao registry de promoção — e muito menos à produção — apenas porque o Docker build terminou com sucesso.

Onde este capítulo se encaixa na jornada

No capítulo anterior, a segurança foi aplicada no momento do deploy:

Imagem sem attestation
→ Binary Authorization bloqueia no GKE

Neste capítulo, a segurança entra antes:

Imagem com vulnerabilidade crítica
→ Cloud Build interrompe o pipeline

As duas camadas se complementam.

flowchart LR Code[Código] --> Build[Cloud Build] Build --> VulnerabilityScan[Scan de vulnerabilidades] VulnerabilityScan --> Gate{Security gate} Gate -->|Aprovado| Registry[Artifact Registry] Registry --> Attestation[Attestation] Attestation --> BinaryAuth[Binary Authorization] BinaryAuth --> Runtime[GKE ou Cloud Run]

O scan reduz o risco de promover componentes conhecidos como vulneráveis.

Binary Authorization garante que somente artefatos aprovados pelo processo autorizado alcancem o runtime.

O problema: build bem-sucedido não significa build seguro

Um pipeline pode terminar com status verde e ainda produzir uma imagem insegura.

O comando abaixo pode funcionar perfeitamente:

docker build -t minha-aplicacao:latest .

Mesmo assim, a imagem pode conter:

sistema operacional desatualizado;
bibliotecas vulneráveis;
dependências transitivas comprometidas;
ferramentas desnecessárias;
credenciais copiadas para camadas;
pacotes sem correção;
imagens base abandonadas;
versões incompatíveis com políticas internas.

flowchart TD Build[Docker build concluído] --> Question{Imagem está segura?} Question -->|Não sabemos| Risk[Artefato avança sem evidência] Question -->|Scan + política| Decision[Decisão automatizada]

O sucesso técnico do build responde:

Foi possível produzir a imagem?

O security gate responde:

Essa imagem atende aos requisitos mínimos para continuar?

São perguntas diferentes.

O que é Artifact Analysis

Artifact Analysis é o serviço do Google Cloud para análise e armazenamento de metadados relacionados a artefatos.

No contexto deste laboratório, ele é usado para identificar vulnerabilidades em imagens de contêiner.

A documentação atual distingue duas formas principais de scanning:

automatic scanning;
on-demand scanning.

Além de vulnerabilidades, Artifact Analysis pode ajudar a entender composição de software, dependências e licenças, conforme o tipo de pacote e o recurso de scanning utilizado.

Scan automático e On-Demand Scan

Esses mecanismos parecem semelhantes, mas resolvem momentos diferentes do ciclo.

Scan automático

É executado após o push da imagem no Artifact Registry.

flowchart LR Build --> Push[Push para Artifact Registry] Push --> AutoScan[Scan automático] AutoScan --> Findings[Occurrences de vulnerabilidade]

Vantagens:

integração direta com o registry;
análise de imagens recém-publicadas;
visualização pelo Console;
atualização contínua dos metadados quando surgem novas vulnerabilidades;
inventário centralizado.

Limitação principal:

A imagem já chegou ao registry quando o resultado é produzido.

Isso não é necessariamente um problema quando o registry é tratado como área de quarentena. Mas pode ser insuficiente se o simples push já representar promoção.

On-Demand Scan

Pode analisar uma imagem local ou armazenada no Artifact Registry.

flowchart LR LocalImage[Imagem local] --> ODS[On-Demand Scan] ODS --> Report[Relatório] Report --> Gate{Atende à política?} Gate -->|Sim| Push[Push] Gate -->|Não| Stop[Interromper]

Vantagens:

controle do momento do scan;
integração com CI/CD;
possibilidade de analisar antes do push;
uso direto dos resultados para decidir o destino do artefato.

O laboratório combina os dois modelos:

On-Demand Scan como gate do pipeline;
scan automático como análise contínua do que foi armazenado.

Arquitetura completa do laboratório

flowchart TB subgraph Source["Origem"] App[main.py] Dockerfile[Dockerfile] BuildConfig[cloudbuild.yaml] end subgraph CI["Cloud Build"] DockerBuild[Build da imagem] OnDemand[On-Demand Scanning] Severity[Severity check] Retag[Retag :good] Push[Push] end subgraph Registry["Artifact Registry"] Image[Imagem armazenada] AutoScan[Scan automático] Metadata[Metadados de vulnerabilidade] end App --> DockerBuild Dockerfile --> DockerBuild BuildConfig --> DockerBuild DockerBuild --> OnDemand OnDemand --> Severity Severity -->|Sem CRITICAL| Retag Severity -->|Com CRITICAL| Failure[Pipeline falha] Retag --> Push Push --> Image Image --> AutoScan AutoScan --> Metadata

Task 1: construindo a imagem com Cloud Build

O primeiro Dockerfile usou uma imagem Debian 11 do ambiente App Engine:

FROM gcr.io/google-appengine/debian11

RUN apt update && apt install python3-pip -y

WORKDIR /app
COPY . ./

RUN pip3 install Flask==1.1.4
RUN pip3 install gunicorn==20.1.0

CMD exec gunicorn --bind :$PORT --workers 1 --threads 8 --timeout 0 main:app

A aplicação era propositalmente simples:

import os
from flask import Flask

app = Flask(__name__)

@app.route("/")
def hello_world():
    name = os.environ.get("NAME", "Worlds")
    return "Hello {}!".format(name)

if __name__ == "__main__":
    app.run(
        debug=True,
        host="0.0.0.0",
        port=int(os.environ.get("PORT", 8080)),
    )

O primeiro pipeline tinha apenas a etapa de build:

steps:
  - id: build
    name: gcr.io/cloud-builders/docker
    args:
      - build
      - -t
      - us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image
      - .
    waitFor:
      - "-"

sequenceDiagram participant Dev as Engenheiro participant CB as Cloud Build participant Docker as Docker Builder Dev->>CB: gcloud builds submit CB->>Docker: docker build Docker-->>CB: imagem criada no ambiente do build CB-->>Dev: build concluído

Nesse momento, a imagem existia no ambiente do build, mas ainda não havia sido publicada no Artifact Registry.

Task 2: Artifact Registry como destino do pipeline

O repositório foi criado com:

gcloud artifacts repositories create artifact-scanning-repo \
  --repository-format=docker \
  --location=us-central1 \
  --description="Docker repository"

Depois o pipeline recebeu uma etapa de push:

- id: push
  name: gcr.io/cloud-builders/docker
  args:
    - push
    - us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image

E a imagem foi declarada no bloco images:

images:
  - us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image

A configuração final dessa etapa ficou:

flowchart LR Source[Código] --> CB[Cloud Build] CB --> DockerBuild[Docker build] DockerBuild --> Push[Docker push] Push --> AR[Artifact Registry]

O Artifact Registry passa a ser o registro central do artefato e o ponto de integração com Artifact Analysis.

Task 3: scan automático após o push

Depois que a imagem foi enviada, Artifact Analysis iniciou o scan automático.

O resultado pôde ser consultado em:

Artifact Registry
→ artifact-scanning-repo
→ sample-image
→ digest
→ Vulnerabilities

Um detalhe importante é que o scan está associado ao digest da imagem.

Adicionar ou alterar uma tag não cria um novo conteúdo. Portanto, não deveria ser confundido com um novo artefato.

flowchart TD Digest[Digest sha256] --> Scan[Scan] Tag1[latest] --> Digest Tag2[good] --> Digest Tag3[release] --> Digest

As três tags podem apontar para o mesmo digest e, consequentemente, para o mesmo conjunto de resultados.

Task 4: executando On-Demand Scanning

A imagem foi construída localmente no Cloud Shell:

docker build \
  -t us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image \
  .

O scan foi solicitado com:

gcloud artifacts docker images scan \
  us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image \
  --format="value(response.scan)" > scan_id.txt

O arquivo scan_id.txt recebeu a localização do relatório.

Depois, as vulnerabilidades foram consultadas:

gcloud artifacts docker images list-vulnerabilities \
  "$(cat scan_id.txt)"

O laboratório não espera que uma pessoa leia manualmente todo o relatório.

O dado é consumido por uma regra:

export SEVERITY=CRITICAL

gcloud artifacts docker images list-vulnerabilities \
  "$(cat scan_id.txt)" \
  --format="value(vulnerability.effectiveSeverity)" \
| if grep -Fxq "${SEVERITY}"; then
    echo "Failed vulnerability check for ${SEVERITY} level"
  else
    echo "No ${SEVERITY} Vulnerabilities found"
  fi

A imagem inicial retornou:

Failed vulnerability check for CRITICAL level

Esse resultado se tornou a base do security gate.

O que significa `effectiveSeverity`

A severidade de uma vulnerabilidade pode depender do contexto do pacote, da distribuição e da forma como a fonte de vulnerabilidade classifica o problema.

O campo effectiveSeverity fornece a severidade efetiva apresentada pelo scanner para aquela occurrence.

No laboratório, a política foi binária:

Existe CRITICAL?
→ falhar

Em produção, essa regra pode precisar considerar mais dimensões:

severidade;
disponibilidade de correção;
pacote realmente utilizado;
exposição do componente;
exploit conhecido;
ambiente de destino;
prazo de correção;
exceção aprovada.

Voltaremos a isso na seção Além do laboratório.

Task 5: transformando o scan em security gate

O pipeline foi ampliado para quatro fases principais:

build
→ scan
→ severity check
→ push

sequenceDiagram participant CB as Cloud Build participant Docker as Docker participant Scan as On-Demand Scanning participant Gate as Severity Check participant AR as Artifact Registry CB->>Docker: build da imagem Docker-->>CB: imagem local CB->>Scan: solicitar scan Scan-->>CB: scan_id CB->>Gate: consultar severidades alt CRITICAL encontrada Gate-->>CB: exit 1 CB-->>AR: nenhum push :good else nenhuma CRITICAL Gate-->>CB: exit 0 CB->>Docker: retag :good Docker->>AR: push end

A etapa de scan:

- id: scan
  name: gcr.io/cloud-builders/gcloud
  entrypoint: bash
  args:
    - -c
    - |
      (gcloud artifacts docker images scan \
        us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image \
        --location=us \
        --format="value(response.scan)") > /workspace/scan_id.txt

O arquivo é salvo em /workspace, diretório compartilhado entre os passos do build.

A etapa de decisão:

- id: severity-check
  name: gcr.io/cloud-builders/gcloud
  entrypoint: bash
  args:
    - -c
    - |
      gcloud artifacts docker images list-vulnerabilities \
        $(cat /workspace/scan_id.txt) \
        --format="value(vulnerability.effectiveSeverity)" \
      | if grep -Fxq CRITICAL; then
          echo "Failed vulnerability check for CRITICAL level"
          exit 1
        else
          echo "No CRITICAL vulnerability found"
          exit 0
        fi

O exit 1 é o mecanismo que interrompe o pipeline.

O build vulnerável deveria falhar. Isso não é defeito no pipeline.

É exatamente o comportamento de segurança desejado.

Falha como resultado correto

Normalmente, sucesso significa status verde.

Em um security gate, a interpretação é diferente.

flowchart TD Vulnerable[Imagem com CRITICAL] --> FailedBuild[Build falha] FailedBuild --> Correct[Controle funcionou] Safe[Imagem sem CRITICAL] --> SuccessfulBuild[Build passa] SuccessfulBuild --> Correct2[Controle funcionou]

Há dois resultados corretos:

artefato inseguro interrompido;
artefato conforme promovido.

O erro seria permitir que ambos seguissem o mesmo caminho.

Corrigindo a imagem vulnerável

O Dockerfile foi substituído:

FROM python:3.12-alpine

WORKDIR /app
COPY . ./

RUN pip3 install Flask==3.0.3
RUN pip3 install gunicorn==22.0.0
RUN pip3 install Werkzeug==3.0.3

CMD exec gunicorn --bind :$PORT --workers 1 --threads 8 main:app

As mudanças principais foram:

imagem base mais recente;
redução de pacotes do sistema;
versões atualizadas de Flask;
Gunicorn atualizado;
Werkzeug atualizado.

O mesmo pipeline foi executado novamente.

Dessa vez:

scan
→ nenhuma CRITICAL
→ retag :good
→ push

Esse ponto demonstra um princípio importante:

A política permanece; o artefato é que precisa evoluir para atendê-la.

Não enfraquecemos o gate para fazer o build passar.

Corrigimos a imagem.

Arquitetura final do laboratório

flowchart TB subgraph Developer["Desenvolvimento"] App[Código Python] Dockerfile[Dockerfile] end subgraph CloudBuild["Cloud Build"] Build[Build] Scan[On-Demand Scan] Check[Severity Check] Retag[Tag good] Push[Push] end subgraph ArtifactRegistry["Artifact Registry"] Stored[Imagem por digest] Automatic[Automatic Scanning] Continuous[Continuous Analysis] end App --> Build Dockerfile --> Build Build --> Scan Scan --> Check Check -->|CRITICAL| Failed[Pipeline interrompido] Check -->|Conforme| Retag Retag --> Push Push --> Stored Stored --> Automatic Automatic --> Continuous

Automatizando o laboratório

Depois de entender o fluxo, transformei o laboratório em um script Bash que:

detecta PROJECT_ID e PROJECT_NUMBER;
configura us-central1;
identifica a conta de serviço padrão do Cloud Build;
habilita APIs;
concede permissões;
cria a aplicação;
gera os Dockerfiles;
produz os arquivos cloudbuild.yaml;
executa build e push;
roda On-Demand Scan;
interpreta severidades;
confirma a falha esperada;
corrige a imagem;
executa o pipeline novamente;
pausa nos pontos de Check my progress.

flowchart LR Manual[Fluxo manual] --> Understanding[Entendimento] Understanding --> Automation[Script] Automation --> Repeatability[Reprodutibilidade] Repeatability --> Handbook[Documentação]

A automação não substitui o aprendizado. Ela remove trabalho repetitivo depois que o modelo foi compreendido.

Além do laboratório

O laboratório demonstra um gate funcional, mas simplifica decisões importantes.

1. Severidade não é o mesmo que risco

A regra do laboratório é:

CRITICAL → bloquear

Essa regra é um bom início, mas risco real depende de contexto.

Uma vulnerabilidade crítica pode estar:

em pacote não executado;
em ferramenta presente apenas no build;
sem caminho de exploração no runtime;
protegida por controle compensatório;
sem correção disponível.

Ao mesmo tempo, uma vulnerabilidade HIGH pode estar:

exposta diretamente à internet;
em componente explorado ativamente;
com exploit público;
em serviço crítico.

Uma política madura pode combinar:

severidade
+ exploitabilidade
+ exposição
+ fix disponível
+ criticidade do serviço
+ idade da vulnerabilidade

2. Bloquear tudo pode paralisar a entrega

Um gate excessivamente rígido pode bloquear imagens que não têm correção disponível.

Isso incentiva bypasses informais.

Uma política operacional precisa de:

prazo de correção;
exceção com justificativa;
responsável;
data de expiração;
aprovação;
rastreabilidade;
reavaliação automática.

flowchart TD Finding[Vulnerabilidade] --> Fix{Correção disponível?} Fix -->|Sim| Remediate[Atualizar] Fix -->|Não| Exception{Exceção aprovada?} Exception -->|Não| Block[Bloquear] Exception -->|Sim| Temporary[Permitir temporariamente] Temporary --> Expire[Expirar e reavaliar]

3. OS packages não são toda a superfície

Contêineres podem conter vulnerabilidades em:

pacotes do sistema operacional;
Python;
Java;
Go;
Node.js;
PHP;
Ruby;
Rust;
.NET;
binários copiados manualmente;
arquivos não gerenciados por package manager.

A cobertura depende do tipo de scanning e dos formatos suportados.

Por isso, uma pipeline completa pode combinar:

Artifact Analysis;
scanner de dependências;
SAST;
secret scanning;
análise de infraestrutura;
análise de licenças;
DAST;
testes de segurança.

4. Dependências transitivas precisam ser investigadas

Uma vulnerabilidade pode não aparecer diretamente no requirements.txt.

Ela pode ter sido introduzida por outra biblioteca.

aplicação
→ Flask
→ dependência transitiva
→ pacote vulnerável

O relatório precisa ser conectado à árvore de dependências e ao caminho do arquivo dentro da imagem.

5. Atualizar a tag não garante atualização real

Tags como:

python:3.12-alpine

são mutáveis.

O conteúdo associado pode mudar.

Em produção, eu avaliaria pin por digest:

FROM python:3.12-alpine@sha256:...

Isso aumenta reprodutibilidade.

Mas cria outra responsabilidade:

atualizar deliberadamente o digest para receber patches.

Reprodutibilidade e atualização precisam coexistir.

6. Imagens precisam ser reconstruídas continuamente

Uma imagem segura hoje pode ficar vulnerável amanhã.

Novos CVEs são publicados continuamente.

Por isso, a estratégia não deve depender apenas de mudanças no código da aplicação.

É necessário reconstruir imagens quando:

imagem base recebe patch;
dependência é atualizada;
nova vulnerabilidade aparece;
política interna muda;
artefato excede idade máxima.

flowchart LR NewCVE[Novo CVE] --> Rescan[Metadados atualizados] Rescan --> Rebuild[Rebuild obrigatório] BaseUpdate[Imagem base atualizada] --> Rebuild Rebuild --> Gate[Security gate]

7. Continuous Analysis não substitui resposta

Artifact Analysis atualiza os metadados de vulnerabilidades ao longo do tempo.

Mas descobrir uma nova vulnerabilidade não corrige a imagem em execução.

Precisamos de processos para:

identificar workloads afetados;
priorizar;
criar issue;
reconstruir;
promover nova imagem;
substituir workloads;
verificar conclusão.

8. A conta de serviço do Cloud Build mudou

O laboratório usa o formato clássico:

PROJECT_NUMBER@cloudbuild.gserviceaccount.com

Em projetos novos, Cloud Build pode usar a conta padrão do Compute Engine.

Por isso, eu não assumiria a identidade.

Verificaria:

gcloud builds get-default-service-account

Em produção, a recomendação mais segura é usar uma conta de serviço dedicada e explicitamente configurada.

9. Privilégio mínimo

A conta do build precisa de acesso para:

ler o contexto;
executar scan;
escrever no repositório correto;
acessar recursos necessários.

Ela não deveria receber permissões amplas no projeto inteiro por conveniência.

Uma arquitetura mais segura usa:

service account dedicada;
papéis mínimos;
escopo por repositório;
separação por ambiente;
revisão periódica de IAM.

10. Segredos não devem entrar na imagem

Evitaria:

ENV API_KEY=...
COPY credentials.json /app/
RUN echo "$TOKEN" > arquivo

Cada instrução pode criar camadas recuperáveis.

Segredos devem ser fornecidos de forma controlada no build ou no runtime, usando mecanismos próprios e IAM.

11. O sistema de build também é parte da supply chain

Um scanner confiável não compensa um builder comprometido.

É necessário proteger:

triggers;
repositórios;
service accounts;
imagens de builder;
scripts;
workers;
conexões de rede;
provenance;
logs;
permissões para modificar cloudbuild.yaml.

12. Private Pools e controle de rede

Builds com acesso a recursos privados ou requisitos de isolamento podem usar Private Pools.

Isso permite controlar:

rede;
capacidade;
isolamento;
acesso a sistemas internos;
egress;
workers dedicados.

O desenho deve impedir que builds não confiáveis alcancem recursos sensíveis desnecessariamente.

13. Registry de quarentena e registry de promoção

O laboratório usa um único repositório.

Em produção, eu separaria estados de confiança.

flowchart LR Build[Build] --> Quarantine[Registry de quarentena] Quarantine --> Scan[Scan e políticas] Scan -->|Aprovado| Release[Registry de release] Scan -->|Reprovado| Blocked[Retido] Release --> Deploy[Deploy]

A promoção pode ser feita por digest, evitando reconstruir o artefato.

14. Gate por política centralizada

Espalhar scripts grep CRITICAL por dezenas de repositórios cria inconsistência.

Eu centralizaria:

definição da política;
versão do componente de scan;
formato de exceção;
regras de severidade;
métricas;
atualizações;
auditoria.

Isso pode ser implementado com:

template de Cloud Build;
builder interno;
política como código;
serviço central de decisão;
módulo reutilizável.

15. SBOM e proveniência

O scan responde:

Quais vulnerabilidades conhecidas aparecem nos componentes detectados?

Uma SBOM responde:

Quais componentes fazem parte do artefato?

Proveniência responde:

Onde, quando e como o artefato foi produzido?

Uma cadeia madura combina os três.

flowchart TD Artifact[Artefato] Artifact --> SBOM[SBOM] Artifact --> Vuln[Vulnerabilidades] Artifact --> Provenance[Proveniência] SBOM --> Policy[Política] Vuln --> Policy Provenance --> Policy Policy --> Promotion[Promover ou bloquear]

16. Scan não valida comportamento malicioso

Uma imagem pode não conter CVEs conhecidos e ainda ser maliciosa.

Exemplos:

código próprio com backdoor;
exfiltração intencional;
comportamento destrutivo;
credenciais embutidas;
lógica insegura.

Vulnerability scanning é uma camada, não prova total de segurança.

17. Política por ambiente

Ambientes diferentes podem ter exigências diferentes.

Exemplo:

Ambiente	Política
Desenvolvimento	bloquear `CRITICAL` com fix
Homologação	bloquear `CRITICAL` e `HIGH` exploráveis
Produção	exigir scan, SBOM, provenance, assinatura e aprovação

As diferenças precisam ser explícitas, não atalhos manuais.

18. Métricas operacionais

Eu acompanharia:

builds bloqueados;
vulnerabilidades por severidade;
tempo médio para correção;
imagens antigas;
exceções abertas;
exceções expiradas;
pacotes recorrentes;
equipes com maior exposição;
percentual de imagens promovidas;
tempo do scan no pipeline.

Um gate sem métricas pode virar apenas atrito.

Arquitetura que eu usaria em produção

flowchart TB subgraph Source["Código e revisão"] Git[Git] PR[Pull Request] Git --> PR end subgraph BuildPlane["Projeto de build"] Trigger[Cloud Build Trigger] BuildSA[Service Account dedicada] Build[Build isolado] Tests[Testes] SAST[SAST] SBOM[Gerar SBOM] ODS[On-Demand Scan] Policy[Policy Engine] Trigger --> Build BuildSA --> Build Build --> Tests --> SAST --> SBOM --> ODS --> Policy end subgraph Artifacts["Artefatos"] Quarantine[Artifact Registry - quarantine] Release[Artifact Registry - release] Metadata[Artifact Analysis] end subgraph Delivery["Entrega"] Attestation[Attestation] BinaryAuth[Binary Authorization] Runtime[GKE / Cloud Run] end PR --> Trigger Build --> Quarantine Quarantine --> ODS ODS --> Metadata Policy -->|Aprovado| Release Policy -->|Reprovado| Stop[Interromper] Release --> Attestation Attestation --> BinaryAuth BinaryAuth --> Runtime

Como aplicaria em ambientes reais

Para uma plataforma SaaS, eu implementaria:

Pull Request
→ testes
→ build
→ SBOM
→ scan
→ security gate
→ registry de release
→ attestation
→ deploy

Cada produto poderia compartilhar o mesmo template de segurança.

Isso reduz divergências entre projetos.

Plataformas institucionais

Em um sistema institucional, o pipeline poderia exigir:

base image aprovada;
zero vulnerabilidades críticas;
exceções documentadas;
imagem por digest;
attestation do pipeline;
deploy somente por processo autorizado;
auditoria de promoções.

O objetivo é evitar que um artefato construído fora do processo oficial alcance o ambiente institucional.

Sistemas com dados sensíveis

Em um sistema de saúde, o scan não resolve privacidade nem segurança clínica, mas reduz risco de componentes vulneráveis na plataforma.

Eu adicionaria:

política mais rígida em produção;
prazo curto para vulnerabilidades exploráveis;
inventário de dependências;
separação de ambientes;
logs de promoção;
attestation;
rebuild periódico.

Google Cloud e AWS: equivalências úteis

Capacidade	Google Cloud	AWS
Build gerenciado	Cloud Build	CodeBuild
Registry	Artifact Registry	ECR
Scan automático	Artifact Analysis	ECR Enhanced Scanning / Inspector
Scan sob demanda	On-Demand Scanning	Inspector/ECR e scanners integrados
IAM de pipeline	Service Account	IAM Role
Segurança no deploy	Binary Authorization	Gatekeeper/Ratify, Kyverno ou controles próprios
KMS	Cloud KMS	AWS KMS
Auditoria	Cloud Audit Logs	CloudTrail / CloudWatch

As equivalências não são perfeitas. O modelo de integração e enforcement difere entre plataformas.

Custos e impacto operacional

Uma solução real pode envolver custos de:

minutos de Cloud Build;
armazenamento no Artifact Registry;
scanning;
retenção de imagens;
logs;
Private Pools;
transferência;
rebuilds periódicos.

Também existe custo de tempo no pipeline.

Um scan que aumenta muito a duração pode prejudicar a experiência do desenvolvedor.

Por isso, eu avaliaria:

cache;
builds paralelos;
scans incrementais quando disponíveis;
política por estágio;
feedback rápido no Pull Request;
scans mais completos antes da promoção.

Erros e pontos de atenção do laboratório

Região fixa

O laboratório usou us-central1 para o Artifact Registry.

Misturar regiões na URI causa falhas de push ou consulta.

IAM da conta de serviço

O build precisa conseguir acessar On-Demand Scanning.

O papel deve ser concedido à conta que realmente executa o build.

Falha intencional

O primeiro pipeline de CI/CD deveria falhar.

Tratar essa falha como problema e remover o gate destruiria o objetivo do laboratório.

Latência do scan

O relatório pode levar algum tempo para ficar disponível.

Scripts precisam considerar retry ou espera.

Imagem base vulnerável

A maior parte dos findings iniciais vinha do sistema operacional e dos pacotes presentes na base, não da pequena aplicação Python.

YAML e shell

Indentação, escape de $, pipes e códigos de saída definem se o gate realmente funciona.

Um grep mal escrito pode permitir imagens que deveriam ser bloqueadas.

O que o laboratório não explicou

O laboratório não aprofunda:

como escolher o threshold ideal;
como avaliar exploitabilidade;
como tratar vulnerabilidades sem correção;
como modelar exceções;
como expirar exceções;
como separar registries;
como gerar SBOM;
como produzir provenance;
como impedir alteração do pipeline;
como usar service account dedicada;
como proteger segredos;
como operar Private Pools;
como responder a novas vulnerabilidades em imagens já implantadas;
como medir eficácia;
como integrar o gate com Binary Authorization;
como promover o mesmo digest entre ambientes;
como impedir que usuários façam push direto para o registry de release.

Essas decisões fazem parte da arquitetura operacional.

Como um arquiteto pensa

Antes de criar um gate, eu responderia:

Qual ameaça estamos reduzindo?
CVEs conhecidos, dependência comprometida, base antiga ou artefato fora do pipeline?
Qual é o threshold?
Apenas CRITICAL, HIGH explorável ou vulnerabilidade com fix disponível?
Onde o gate atua?
Pull Request, build, push, promoção ou deploy?
Qual artefato é promovido?
A mesma imagem por digest ou uma reconstrução?
Como funcionam exceções?
Quem aprova, por quanto tempo e com qual evidência?
Como reagimos a CVE nova?
Rebuild, rollback, ticket automático ou bloqueio de novos deploys?
Quem pode alterar a política?
Desenvolvedores do produto, plataforma ou segurança?
Quais métricas mostram eficácia?
Findings, tempo de correção, bypasses e builds bloqueados.

A ferramenta deve implementar uma política de risco, não substituir essa política.

Glossário

Principais conceitos utilizados neste artigo.

Artifact Registry

Serviço para armazenar e distribuir imagens e pacotes.

Artifact Analysis

Serviço de scanning e gerenciamento de metadados sobre artefatos.

Automatic Scanning

Scan disparado quando uma imagem é enviada ao Artifact Registry.

Continuous Analysis

Atualização contínua dos metadados de vulnerabilidade de imagens já analisadas.

On-Demand Scanning

Scan solicitado explicitamente para uma imagem local ou remota.

Vulnerability Occurrence

Registro de que uma vulnerabilidade foi identificada em um artefato específico.

Severity

Classificação da gravidade de uma vulnerabilidade.

Effective Severity

Severidade efetiva reportada para a occurrence no contexto analisado.

Security Gate

Regra que permite ou impede a continuação do pipeline.

Base Image

Imagem usada como ponto de partida do Dockerfile.

Digest

Hash imutável que identifica o conteúdo da imagem.

SBOM

Software Bill of Materials: inventário dos componentes de software presentes no artefato.

Proveniência

Evidência verificável de onde, quando e como o artefato foi produzido.

Promotion

Movimento controlado de um artefato aprovado entre estágios ou registries.

Lições aprendidas

Build concluído não significa artefato seguro.
Scan automático e On-Demand Scan resolvem momentos diferentes.
Vulnerabilidades precisam virar decisões automáticas.
Falhar um pipeline pode ser o resultado correto.
A política deve permanecer estável; o artefato deve ser corrigido.
A imagem base influencia fortemente a superfície de vulnerabilidades.
Tags são convenientes, mas digest representa identidade.
IAM da pipeline é parte da segurança.
Scan de vulnerabilidades é uma camada, não uma garantia completa.
Build-time e deploy-time controls funcionam melhor juntos.

Como isso ajuda na formação em Cloud Engineering

O laboratório reforça habilidades importantes para Cloud, DevOps, DevSecOps e arquitetura:

Cloud Build;
Artifact Registry;
Artifact Analysis;
Docker;
YAML;
IAM;
service accounts;
automação;
pipelines;
políticas de segurança;
análise de vulnerabilidades;
promoção de artefatos;
observabilidade de builds.

Para Associate Cloud Engineer, ele reforça operação de serviços, IAM, CLI e automação.

Para Professional Cloud DevOps Engineer e Professional Cloud Security Engineer, os conceitos de supply chain e security gates são ainda mais centrais.

Conclusão

O laboratório começou com um pipeline capaz apenas de construir uma imagem.

Depois, esse pipeline passou a:

criar;
analisar;
interpretar;
decidir;
bloquear;
corrigir;
promover.

O aprendizado principal não foi executar um comando de scan.

Foi entender como um finding técnico pode se transformar em uma política operacional automática.

A primeira imagem falhou porque continha vulnerabilidades críticas.

Em vez de enfraquecer a regra, a imagem foi corrigida.

O mesmo pipeline foi executado novamente e permitiu a promoção.

Essa é a essência de um secure build:

o artefato precisa provar que atende aos requisitos antes de avançar.

No capítulo anterior, protegemos o deploy.

Neste capítulo, protegemos o build.

Juntos, eles formam uma cadeia de defesa mais forte:

Código
→ build seguro
→ scan
→ promoção controlada
→ attestation
→ autorização no deploy
→ runtime

Próximo capítulo

No próximo capítulo da Google Cloud Master Journey 2026, a trilha continua aprofundando a segurança de containers e da cadeia de entrega.

Os próximos temas incluem:

proteção do processo de build;
segurança de containers;
isolamento;
IAM;
provenance;
attestations;
políticas;
Challenge Lab de Secure Software Delivery.

A segurança do runtime começa no primeiro arquivo consumido pelo build.

Referências oficiais consultadas

Em breve

Comentários

Em breve

As respostas da comunidade chegam em breve.

Em breve

Secure Builds com Cloud Build: bloqueando imagens vulneráveis antes do Artifact Registry

O que vamos construir

Onde este capítulo se encaixa na jornada

O problema: build bem-sucedido não significa build seguro

O que é Artifact Analysis

Scan automático e On-Demand Scan

Scan automático

On-Demand Scan

Arquitetura completa do laboratório

Task 1: construindo a imagem com Cloud Build

Task 2: Artifact Registry como destino do pipeline

Task 3: scan automático após o push

Task 4: executando On-Demand Scanning

O que significa effectiveSeverity

Task 5: transformando o scan em security gate

Falha como resultado correto

Corrigindo a imagem vulnerável

Arquitetura final do laboratório

Automatizando o laboratório

Além do laboratório

1. Severidade não é o mesmo que risco

2. Bloquear tudo pode paralisar a entrega

3. OS packages não são toda a superfície

4. Dependências transitivas precisam ser investigadas

5. Atualizar a tag não garante atualização real

6. Imagens precisam ser reconstruídas continuamente

7. Continuous Analysis não substitui resposta

8. A conta de serviço do Cloud Build mudou

9. Privilégio mínimo

10. Segredos não devem entrar na imagem

11. O sistema de build também é parte da supply chain

12. Private Pools e controle de rede

13. Registry de quarentena e registry de promoção

14. Gate por política centralizada

15. SBOM e proveniência

16. Scan não valida comportamento malicioso

17. Política por ambiente

18. Métricas operacionais

Arquitetura que eu usaria em produção

Como aplicaria em ambientes reais

Plataformas institucionais

Sistemas com dados sensíveis

Google Cloud e AWS: equivalências úteis

Custos e impacto operacional

Erros e pontos de atenção do laboratório

Região fixa

IAM da conta de serviço

Falha intencional

Latência do scan

Imagem base vulnerável

YAML e shell

O que o laboratório não explicou

Como um arquiteto pensa

Lições aprendidas

Como isso ajuda na formação em Cloud Engineering

Conclusão

Próximo capítulo

Referências oficiais consultadas

Comentários

Leia também

O que significa `effectiveSeverity`