1. Antes de começar
Este é o codelab prático sobre Como proteger seu pipeline de CI/CD com o CodeMender.
Na entrega de software moderna, as ferramentas de análise estática (como o CodeQL) são essenciais para detectar padrões sintáticos conhecidos, mas geralmente não identificam vulnerabilidades sutis ocultas na lógica de negócios e geram alertas ruidosos e não verificados.
O CodeMender (executável da CLI: cm) aprimora seu pipeline de CI/CD, operando com as ferramentas de SAST atuais, ao implantar os agentes de raciocínio de segurança do Google com tecnologia do Gemini para:
Descubra falhas complexas na lógica de negócios: entenda o contexto do aplicativo e os fluxos de dados arquitetônicos além das regras rígidas de padrões estáticos.
Redução drástica de falsos positivos com a verificação de autoexploração: comprove dinamicamente a possibilidade de exploração em ambientes de sandbox antes de alertar os desenvolvedores.
Corrigir descobertas verificadas de forma autônoma: sintetize patches de código, valide em pacotes de testes para evitar regressões e envie solicitações de pull prontas para revisão.
Neste codelab, você vai integrar o CodeMender ao repositório do OWASP Juice Shop usando o GitHub Actions e a federação de identidade da carga de trabalho (WIF, na sigla em inglês) sem chave do Google Cloud.
Pré-requisitos
- Recomendado: conhecimento básico dos conceitos do CodeMender (abordados em Proteger seu aplicativo com o CodeMender)
- Noções básicas sobre fluxos de trabalho, gatilhos e sintaxe YAML do GitHub Actions
- Noções básicas sobre comandos do Git e fluxos de trabalho de revisão de solicitações de pull
- Conhecimento básico dos conceitos do Cloud IAM do Google Cloud (contas de serviço, papéis e APIs)
- Familiaridade com vulnerabilidades comuns de aplicativos da Web (como injeção de SQL e XSS)
O que você vai aprender
- Como configurar a autenticação sem chave de confiança zero entre o GitHub Actions e o Google Cloud usando a federação de identidade da carga de trabalho (WIF)
- Como criar um fluxo de trabalho automatizado de verificação de vulnerabilidades usando o CodeMender e o
gemini-3.8-flash - Como publicar relatórios de segurança acionáveis usando o OASIS SARIF v2.1.0 e os resumos de jobs nativos do GitHub Actions.
- Como criar um fluxo de trabalho de correção autônomo que gera patches de código verificados por teste e abre solicitações de pull para revisão humana
- Como aplicar restrições de qualidade automatizadas (
--fail-on) e armazenamento em cache de pipeline para segurança contínua de alta velocidade
O que é necessário
- Um projeto na nuvem do Google Cloud com o faturamento ativado e permissões de Proprietário do projeto/Editor
- Uma conta do GitHub com permissões para criar repositórios, configurar Secrets e gerenciar Actions (você vai bifurcar o repositório do GitHub da OWASP Juice Shop na Etapa 3 usando a CLI do GitHub).
2. Entender a arquitetura de CI/CD do CodeMender
No DevSecOps empresarial moderno, a segurança com tecnologia de IA não pode ser apenas uma ferramenta manual para computadores. Ele precisa operar como um controlador automatizado (bloqueando solicitações de pull não seguras) e um co-desenvolvedor autônomo (propondo patches verificados diretamente no Git).
Para isso, você vai implementar uma arquitetura de fluxo de trabalho duplo com a federação de identidade da carga de trabalho (WIF) do Google Cloud e os modelos de raciocínio do Gemini Enterprise.
Arquitetura de fluxo de trabalho duplo
Em vez de colocar a detecção e a correção em um único script monolítico, o pipeline separa a segurança em dois fluxos de trabalho desacoplados e específicos:
Fluxo de trabalho | Acionador principal | Responsabilidade principal | Porta lógica rígida de qualidade |
1. Verificação de vulnerabilidades( | Solicitações de pull, pushes principais, cron semanal, envio manual | • Executa verificações diferenciais rápidas de AST em PRs (~15s), verificações rápidas de referência em pushes ( | Bloqueia a mesclagem de PR se vulnerabilidades altas ou críticas recém-introduzidas forem detectadas ( |
2. Remediador autônomo( | Acionador manual ( | • Retoma o estado dos artefatos de verificação ( | Garante diffs de produção limpos antes de abrir uma solicitação de envio. |
Três princípios básicos de design empresarial
Ao criar esses fluxos de trabalho nas próximas seções, lembre-se destes três pilares arquitetônicos fundamentais:
🔑 Autenticação sem chave de confiança zero e validação de simulação:
Nenhuma chave JSON de longa duração da conta de serviço do Google Cloud é armazenada no GitHub Secrets. O executor gera um token OIDC de curta duração trocado pelo STS do Google Cloud por uma credencial temporária de 1 hora, define persist-credentials: false em checkouts do Git e executa cm health --strict para verificar as credenciais, o Network Reachability e as permissões do IAM antes de consumir a cota do modelo de consumo.
⚡ Roteamento de verificação adaptável e supressão de ruído legada:
Em vez de executar auditorias lentas de repositório completo em cada solicitação de pull, o CodeMender encaminha cada evento de CI para o modo de verificação ideal: as solicitações de pull acionam a análise AST diferencial (--diff="origin/$BASE_REF") em arquivos modificados e chamadores de 1 salto em menos de 15 segundos; os pushes da ramificação principal executam verificações rápidas de referência de sessão única (--quick); e as programações semanais executam auditorias profundas simultâneas arquivo por arquivo (padrão cm find .). As vulnerabilidades de base de código preexistentes não afetadas por uma solicitação de pull são rotuladas como [LEGACY / UNTOUCHED]; elas aparecem nos relatórios SARIF para visibilidade, mas não bloqueiam o portão de mesclagem da solicitação de pull e não acionam a correção automática.
🛡️ Observabilidade de segurança resiliente e sem bloqueio:
Mesmo quando o --fail-on sai com o código 1 para bloquear um PR não seguro, proteger as etapas de exportação de relatórios e upload de SARIF com steps.scan.outputs.completed == 'true' e hashFiles('results.sarif') != '' garante que os alertas do OASIS SARIF e os resumos de jobs ainda sejam publicados, enquanto ignora a exportação e o upload se uma execução for cancelada ou abortada devido a um erro de configuração ou capacidade (10–60).
3. Autenticar e preparar o repositório de destino no Cloud Shell
Para estabelecer a autenticação sem chave e executar pipelines de segurança automatizados, você precisa de um repositório de destino do GitHub acessível que seja seu. Neste codelab, você vai usar o OWASP Juice Shop, um aplicativo da Web do Node.js intencionalmente vulnerável, como um ambiente de segurança pronto para uso.
Você vai usar a CLI do GitHub (gh), pré-instalada no Google Cloud Shell, para se autenticar no GitHub, capturar os detalhes do usuário automaticamente e preparar o repositório em um fluxo simplificado.
Etapa 1: abrir o Cloud Shell e autenticar a CLI do GitHub
Abra o Console do Google Cloud e ative o Cloud Shell (ícone >_ na barra de navegação superior).
Autentique a CLI do GitHub (gh) para configurar o gerenciamento de credenciais do Git:
gh auth login --hostname github.com --git-protocol https --web
Siga as instruções na tela:
Copie o código único de 8 caracteres impresso no Cloud Shell (por exemplo, 1234-ABCD).
Pressione Enter para abrir https://github.com/login/device no navegador.
Cole o código e clique em Autorizar o GitHub.
Etapa 2: exportar variáveis dinamicamente e bifurcar o OWASP Juice Shop
Execute os comandos a seguir no Cloud Shell para capturar automaticamente seu nome de usuário do GitHub e preparar o repositório:
# 1. Automatically capture your GitHub username (customize GITHUB_REPO if desired)
export GITHUB_ORG=$(gh api user -q .login)
export GITHUB_REPO="${GITHUB_REPO:-juice-shop}"
export GITHUB_REPOSITORY="${GITHUB_ORG:+${GITHUB_ORG}/${GITHUB_REPO}}"
echo "Authenticated as: ${GITHUB_REPOSITORY}"
# 2. Fork on GitHub server using GITHUB_REPO as the fork name
gh repo fork juice-shop/juice-shop --fork-name "${GITHUB_REPO}" --default-branch-only --clone=false 2>/dev/null || true
# 3. Shallow clone your fork (downloads only ~15 MB in 3-5 seconds, skipping heavy upstream git history)
[ -d ~/"${GITHUB_REPO}" ] || git clone --depth=1 "https://github.com/${GITHUB_REPOSITORY}.git" ~/"${GITHUB_REPO}" || \
(sleep 2 && git clone --depth=1 "https://github.com/${GITHUB_REPOSITORY}.git" ~/"${GITHUB_REPO}")
cd ~/"${GITHUB_REPO}"
# 4. Confirm you are in the repository directory
git status
4. Configurar a federação de identidade da carga de trabalho do Google Cloud usando a gcloud
Nesta etapa, você vai usar a CLI gcloud no Google Cloud Shell para ativar as APIs necessárias, criar uma conta de serviço de CI/CD dedicada, configurar o pool de Identidade da carga de trabalho e estabelecer uma relação de confiança do OIDC com seu repositório do GitHub (${GITHUB_REPOSITORY}).
Etapa 1: definir as variáveis de ambiente do Google Cloud
No terminal do Cloud Shell (no espaço de trabalho do repositório clonado), capture o ID do projeto ativo do Google Cloud, verifique a variável do repositório do GitHub e defina os nomes dos recursos da WIF:
# Capture active Google Cloud Project ID and verify GitHub repository
export PROJECT_ID=$(gcloud config get-value project)
export GITHUB_USER=$(gh api user -q ".login")
export GITHUB_REPO="${GITHUB_REPO:-$(git remote get-url origin 2>/dev/null | sed -E 's#^.*/##; s#\.git$##')}"
export GITHUB_REPO="${GITHUB_REPO:-juice-shop}"
export GITHUB_REPOSITORY="${GITHUB_USER:+${GITHUB_USER}/${GITHUB_REPO}}"
# Define WIF and Service Account resource names
export WORKLOAD_IDENTITY_POOL="codemender-github-pool"
export WORKLOAD_IDENTITY_PROVIDER="codemender-github-provider"
export SERVICE_ACCOUNT_NAME="codemender-ci-runner"
if [ -z "${PROJECT_ID}" ] || [ -z "${GITHUB_REPOSITORY}" ]; then
echo "ERROR: PROJECT_ID ('${PROJECT_ID}') or GITHUB_REPOSITORY ('${GITHUB_REPOSITORY}') is empty. Check 'gcloud config get-value project' and 'gh auth status'."
else
echo "Project ID: ${PROJECT_ID}"
echo "GitHub Repository: ${GITHUB_REPOSITORY}"
fi
Etapa 2: ativar as APIs necessárias do Google Cloud
Ative as APIs IAM, Security Token Service, IAM Credentials, Agent Platform e Resource Manager:
gcloud services enable \
iam.googleapis.com \
iamcredentials.googleapis.com \
sts.googleapis.com \
aiplatform.googleapis.com \
cloudresourcemanager.googleapis.com \
--project=${PROJECT_ID}
Etapa 3: criar uma conta de serviço de CI/CD dedicada
Crie uma conta de serviço do Google Cloud com privilégio mínimo dedicada à execução do pipeline de CI/CD (reutilize-a com segurança se ela já existir):
export SERVICE_ACCOUNT_EMAIL="${SERVICE_ACCOUNT_NAME}@${PROJECT_ID}.iam.gserviceaccount.com"
gcloud iam service-accounts describe "${SERVICE_ACCOUNT_EMAIL}" \
--project="${PROJECT_ID}" >/dev/null 2>&1 || \
gcloud iam service-accounts create "${SERVICE_ACCOUNT_NAME}" \
--display-name="CodeMender CI/CD Pipeline Runner" \
--project="${PROJECT_ID}"
echo "Service Account Email: ${SERVICE_ACCOUNT_EMAIL}"
Etapa 4: conceder permissões do IAM da Agent Platform
Conceda o papel roles/aiplatform.user (Usuário da Agent Platform) à conta de serviço para que ela possa se comunicar com a Gemini Enterprise Agent Platform:
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
--member="serviceAccount:${SERVICE_ACCOUNT_EMAIL}" \
--role="roles/aiplatform.user"
Etapa 5: criar o pool de Identidade da carga de trabalho
Crie o pool de Identidade da carga de trabalho para gerenciar as declarações de identidade do GitHub Actions (ou restaure e ative-o automaticamente se ele já existir no projeto):
POOL_STATE=$(gcloud iam workload-identity-pools list \
--location="global" \
--show-deleted \
--project="${PROJECT_ID}" \
--filter="name ~ /${WORKLOAD_IDENTITY_POOL}$" \
--format="value(state)")
if [ -z "${POOL_STATE}" ]; then
gcloud iam workload-identity-pools create "${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--display-name="CodeMender GitHub Pool" \
--project="${PROJECT_ID}"
else
[ "${POOL_STATE}" = "DELETED" ] && gcloud iam workload-identity-pools undelete "${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--project="${PROJECT_ID}"
gcloud iam workload-identity-pools update "${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--no-disabled \
--project="${PROJECT_ID}"
fi
Etapa 6: criar o provedor de identidade de carga de trabalho com o OIDC do GitHub
Crie (ou atualize) o provedor OIDC no pool, vinculando o URL do emissor https://token.actions.githubusercontent.com e mapeando as declarações de token do GitHub para os atributos do STS do Google:
PROVIDER_STATE=$(gcloud iam workload-identity-pools providers list \
--workload-identity-pool="${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--show-deleted \
--project="${PROJECT_ID}" \
--filter="name ~ /${WORKLOAD_IDENTITY_PROVIDER}$" \
--format="value(state)")
if [ -z "${GITHUB_REPOSITORY}" ]; then
echo "ERROR: GITHUB_REPOSITORY is empty. Re-run Step 1 before configuring the OIDC provider."
elif [ -z "${PROVIDER_STATE}" ]; then
gcloud iam workload-identity-pools providers create-oidc "${WORKLOAD_IDENTITY_PROVIDER}" \
--workload-identity-pool="${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--display-name="CodeMender GitHub Provider" \
--issuer-uri="https://token.actions.githubusercontent.com" \
--attribute-mapping="google.subject=assertion.sub,attribute.actor=assertion.actor,attribute.repository=assertion.repository,attribute.repository_owner=assertion.repository_owner" \
--attribute-condition="assertion.repository == '${GITHUB_REPOSITORY}'" \
--project="${PROJECT_ID}"
else
[ "${PROVIDER_STATE}" = "DELETED" ] && gcloud iam workload-identity-pools providers undelete "${WORKLOAD_IDENTITY_PROVIDER}" \
--workload-identity-pool="${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--project="${PROJECT_ID}"
gcloud iam workload-identity-pools providers update-oidc "${WORKLOAD_IDENTITY_PROVIDER}" \
--workload-identity-pool="${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--issuer-uri="https://token.actions.githubusercontent.com" \
--attribute-mapping="google.subject=assertion.sub,attribute.actor=assertion.actor,attribute.repository=assertion.repository,attribute.repository_owner=assertion.repository_owner" \
--attribute-condition="assertion.repository == '${GITHUB_REPOSITORY}'" \
--no-disabled \
--project="${PROJECT_ID}"
fi
Etapa 7: permitir que o repositório do GitHub represente a conta de serviço
Vincule o papel roles/iam.workloadIdentityUser para permitir que os tokens originados do seu repositório representem a conta de serviço do executor de CI e verifique a vinculação da política:
# Retrieve the canonical Workload Identity Pool resource ID
export POOL_ID=$(gcloud iam workload-identity-pools describe "${WORKLOAD_IDENTITY_POOL}" \
--project="${PROJECT_ID}" \
--location="global" \
--format="value(name)")
if [ -z "${POOL_ID}" ] || [ -z "${GITHUB_REPOSITORY}" ]; then
echo "ERROR: POOL_ID ('${POOL_ID}') or GITHUB_REPOSITORY ('${GITHUB_REPOSITORY}') is empty. Re-run Step 1 and Step 5."
else
# Bind Workload Identity User role to the principalSet of your repository
gcloud iam service-accounts add-iam-policy-binding "${SERVICE_ACCOUNT_EMAIL}" \
--project="${PROJECT_ID}" \
--role="roles/iam.workloadIdentityUser" \
--member="principalSet://iam.googleapis.com/${POOL_ID}/attribute.repository/${GITHUB_REPOSITORY}"
# Verify the principalSet binding on the Service Account
gcloud iam service-accounts get-iam-policy "${SERVICE_ACCOUNT_EMAIL}" \
--project="${PROJECT_ID}"
fi
Etapa 8: recuperar valores de configuração para secrets do GitHub
Recupere o nome completo do recurso do seu provedor de identidade de carga de trabalho e armazene-o em uma variável de ambiente para registro automatizado na próxima etapa:
# Retrieve full Workload Identity Provider name
export WORKLOAD_PROVIDER_NAME=$(gcloud iam workload-identity-pools providers describe ${WORKLOAD_IDENTITY_PROVIDER} \
--workload-identity-pool=${WORKLOAD_IDENTITY_POOL} \
--location="global" \
--project=${PROJECT_ID} \
--format="value(name)")
echo "=========================================================="
echo "WIF CONFIGURATION READY:"
echo "=========================================================="
echo "GCP_WORKLOAD_IDENTITY_PROVIDER: ${WORKLOAD_PROVIDER_NAME}"
echo "GCP_SERVICE_ACCOUNT: ${SERVICE_ACCOUNT_EMAIL}"
echo "=========================================================="
5. Configurar secrets do repositório do GitHub e permissões de fluxo de trabalho
Agora que a WIF do Google Cloud está provisionada, você vai configurar os Secrets do repositório do GitHub e conceder as permissões de fluxo de trabalho necessárias para a verificação de segurança automatizada e as solicitações de pull de correção automática.
É possível definir essas configurações diretamente no Cloud Shell usando a CLI do GitHub (gh), eliminando completamente a necessidade de copiar e colar manualmente nomes de recursos longos.
Etapa 1: definir secrets do repositório usando a CLI do GitHub
No terminal do Cloud Shell, execute os comandos a seguir para definir com segurança os dois secrets de repositório necessários usando as variáveis de ambiente ativas:
# 1. Set the Workload Identity Provider resource name
gh secret set GCP_WORKLOAD_IDENTITY_PROVIDER \
--body "${WORKLOAD_PROVIDER_NAME}" \
--repo "${GITHUB_REPOSITORY}"
# 2. Set the CI/CD Service Account email
gh secret set GCP_SERVICE_ACCOUNT \
--body "${SERVICE_ACCOUNT_EMAIL}" \
--repo "${GITHUB_REPOSITORY}"
# 3. Verify the secrets are registered
gh secret list --repo "${GITHUB_REPOSITORY}"
Etapa 2: conceder permissões de fluxo de trabalho para PRs automatizadas
Por padrão, os fluxos de trabalho do GitHub Actions são executados com permissões somente leitura e não podem criar solicitações de pull. Na Etapa 9, o CodeMender vai gerar e enviar de forma autônoma solicitações de pull de correção verificadas.
Conceda permissões de gravação e ative a criação de solicitações de pull diretamente pela API GitHub:
[ -d .git ] || cd ~/"${GITHUB_REPO:-juice-shop}"
export GITHUB_REPOSITORY="${GITHUB_REPOSITORY:-$(git remote get-url origin 2>/dev/null | sed -E 's#^.*github\.com[:/]##; s#\.git$##')}"
gh api \
--method PUT \
-H "Accept: application/vnd.github+json" \
/repos/${GITHUB_REPOSITORY}/actions/permissions/workflow \
-f default_workflow_permissions="write" \
-F can_approve_pull_request_reviews=true
Etapa 3: desativar os fluxos de trabalho herdados do Juice Shop upstream
A bifurcação do OWASP Juice Shop carrega mais de 16 fluxos de trabalho de CI upstream (como PR Compliance Check, CI/CD Pipeline e CodeQL Scan), além de um modelo de PR de colaborador upstream que fecha automaticamente as PRs direcionadas a master. Desative todos os fluxos de trabalho que não sejam do CodeMender usando a CLI do GitHub e remova os arquivos upstream localmente para que seu fork execute estritamente os fluxos de trabalho do CodeMender:
[ -d .git ] || cd ~/"${GITHUB_REPO:-juice-shop}"
export GITHUB_REPOSITORY="${GITHUB_REPOSITORY:-$(git remote get-url origin 2>/dev/null | sed -E 's#^.*github\.com[:/]##; s#\.git$##')}"
# 1. Disable all inherited non-CodeMender workflows in GitHub Actions (and CodeQL default setup if active)
for WF_ID in $(gh workflow list --all --limit 100 --repo "${GITHUB_REPOSITORY}" --json id,path \
-q '.[] | select((.path | startswith(".github/workflows/")) and (.path | test("codemender-") | not)) | .id'); do
gh workflow disable "${WF_ID}" --repo "${GITHUB_REPOSITORY}" 2>/dev/null || true
done
gh api -X PATCH "/repos/${GITHUB_REPOSITORY}/code-scanning/default-setup" \
-f state=not-configured >/dev/null 2>&1 || true
# 2. Remove upstream workflow files and PR template from the local workspace
for f in .github/workflows/*; do
case "$f" in *codemender-*) ;; *) rm -f "$f" ;; esac
done
rm -f .github/PULL_REQUEST_TEMPLATE.md
6. Criar o fluxo de trabalho de verificação de vulnerabilidades automatizada com o SARIF
Nesta etapa, você vai criar o fluxo de trabalho principal de verificação contínua de segurança (.github/workflows/codemender-scan.yml) que executa verificações de referência em pushes de ramificação, portas diferenciais em solicitações de pull e exportações de SARIF para a verificação de código do GitHub.
Etapa 1: fazer o download do fluxo de trabalho de verificação do CodeMender
Baixe codemender-scan.yml do repositório inicial para .github/workflows/:
[ -d .git ] || cd ~/"${GITHUB_REPO:-juice-shop}"
mkdir -p .github/workflows
curl -fsSL https://raw.githubusercontent.com/edwardc-gcp/codemender-github-actions/main/.github/workflows/codemender-scan.yml \
-o .github/workflows/codemender-scan.yml
Etapa 2: confirmar, enviar e acionar a verificação de CI
Confirme as mudanças no fluxo de trabalho e envie diretamente para a ramificação principal do repositório (master para Juice Shop ou main):
# Stage workflow changes, commit, and push to primary branch
git add -A .github
git commit -m "ci: add CodeMender SARIF security scanning workflow"
git push origin $(git branch --show-current)
No navegador:
Acesse o repositório bifurcado do GitHub: https://github.com/YOUR_GITHUB_USER/juice-shop (por exemplo, https://github.com/octocat/juice-shop).
Clique na guia Ações na barra de navegação superior.
Na barra lateral esquerda, em Fluxos de trabalho, selecione Verificação de segurança do CodeMender e exportação SARIF.
Acione ou confira a execução do fluxo de trabalho:
Acionador automático: se uma execução automática acionada pelo seu push estiver listada, clique nela diretamente para monitorar a execução ao vivo.
Gatilho manual on demand (workflow_dispatch): se nenhuma execução tiver começado, clique no botão Executar fluxo de trabalho ▾ à direita, verifique se Branch: master está selecionado (deixe a caixa de seleção deep_scan desmarcada para que a verificação rápida de referência --quick seja executada) e clique no botão verde Executar fluxo de trabalho.
Clique na execução em andamento e selecione Autonomous Code Vulnerability Scan para acompanhar o fluxo de trabalho em tempo real.
Dentro de codemender-scan.yml: roteamento de verificação com reconhecimento de eventos
Enquanto a verificação de referência do --quick é executada na nuvem (cerca de 3 a 5 minutos), inspecione como o codemender-scan.yml (linhas 118 a 155) encaminha cada evento do GitHub para o modo de verificação dedicado dentro do executor:
# Excerpt from .github/workflows/codemender-scan.yml
if [ "${{ github.event_name }}" = "pull_request" ]; then
cm find . \
--diff="origin/${{ github.base_ref }}" \
--diff-workers=16 \
--fail-on="CRITICAL,HIGH" \
--sandbox=false --yes --bypass-warning || status=$?
elif [ "${{ github.event_name }}" = "schedule" ] || [ "${{ github.event.inputs.deep_scan }}" = "true" ]; then
cm find . \
--deep-workers=8 \
--sandbox=false --yes --bypass-warning || status=$?
else
cm find . \
--quick \
--sandbox=false --yes --bypass-warning || status=$?
fi
Configuração do executor reforçado ( linhas 27 a 117): ignora bifurcações externas não confiáveis e solicitações de envio de dependabot[bot], faz o checkout com persist-credentials: false, armazena em cache ~/.local/bin/cm e ~/.codemender/state.db e executa cm health --strict antes de consumir a cota do modelo de consumo.
Limites do sandbox headless (--sandbox=false --yes --bypass-warning): desativa o isolamento do namespace do usuário do Linux (restrito em contêineres do GitHub Actions sem privilégios), mantendo os limites do caminho do espaço de trabalho (project_paths) e command_policy.yaml aplicados.
Exportação de artefatos e SARIF protegidos por código de saída ( linhas 147 a 194): define steps.scan.outputs.completed=true estritamente quando cm find sai com 0 (limpo) ou 1 (limite de --fail-on atingido). Isso garante que os relatórios SARIF (cm report -f sarif com pontuações de gravidade do CVSS), as tabelas $GITHUB_STEP_SUMMARY (cm report -f md) e os artefatos codemender-findings.json ainda sejam publicados quando --fail-on bloquear um PR, ignorando a exportação em erros de configuração ou capacidade (10–60) para que os arquivos SARIF vazios nunca fechem os alertas existentes.
7. Inspecionar os alertas de verificação de código e o painel de segurança do GitHub
Depois que o fluxo de trabalho de push de referência for concluído, o GitHub vai processar o arquivo SARIF enviado e preencher o resumo da execução de ações e a guia "Segurança" do repositório.
Etapa 1: inspecionar o resumo do job nativo no GitHub Actions
Cada execução de fluxo de trabalho adiciona uma tabela de resumo em Markdown (cm report -f md) diretamente à visão geral da execução do GitHub Actions:
No repositório do GitHub, clique na guia Actions.
Selecione a execução concluída de Verificação de segurança do CodeMender e exportação de SARIF (as auditorias de push da ramificação de referência terminam com uma marca de seleção verde ✅ após a publicação das descobertas do SARIF).
Role para baixo até a seção 🛡️ Resumo da verificação de segurança do CodeMender para inspecionar o detalhamento das descobertas:
🔒 Relatório de segurança do CodeMender
Resumo
Total de descobertas: 28
Gravidade | Count |
🔴 CRÍTICO | 6 |
🟠 ALTA | 16 |
🟡 MÉDIO | 6 |
Status | Count |
🔴 ABERTO | 28 |
Descobertas
ID | Gravidade | Confiança | Status | Correção | Arquivo | Title |
| 🔴 CRÍTICO | 100% | ABRIR | — |
| Execução remota de código por injeção de código do lado do servidor no perfil do usuário |
| 🔴 CRÍTICO | 100% | ABRIR | — |
| Injeção de SQL na rota de autenticação do usuário |
| 🔴 CRÍTICO | 100% | ABRIR | — |
| Execução remota de código por escape de sandbox no processamento de pedidos B2B |
Etapa 2: conhecer o painel centralizado de verificação de código
Na barra de navegação superior do repositório do GitHub, clique na guia Segurança e qualidade (ou Segurança).
Na barra lateral esquerda, em Findings, selecione Code scanning.
Se várias ferramentas estiverem ativas, filtre Ferramenta para CodeMender (is:open branch:master tool:CodeMender) para inspecionar os alertas mapeados com selos de gravidade CVSS nativos:
Selo de gravidade | Título da vulnerabilidade | Local detectado | Ramificação |
🔴 Crítico | Execução remota de código por injeção de código do lado do servidor no perfil do usuário |
|
|
🔴 Crítico | Injeção de SQL na rota de autenticação do usuário |
|
|
🔴 Crítico | Execução remota de código por escape de sandbox no processamento de pedidos B2B |
|
|
Clique em Injeção de SQL na rota de autenticação do usuário (routes/login.ts:34) para analisar o fluxo de dados corrompido e a análise de causa raiz sintetizada pelo Gemini.
8. Bloquear uma solicitação de pull não segura com a verificação diferencial
A verificação de referência descobriu 28 vulnerabilidades preexistentes no OWASP Juice Shop. Com os analisadores estáticos tradicionais, essas 28 descobertas legadas fariam com que todas as solicitações de pull futuras falhassem até que todo o backlog fosse corrigido, forçando as equipes a desativar o bloqueio de mesclagem.
Agora, você vai testar o PR Differential AST Gate (--diff + --fail-on="CRITICAL,HIGH") do CodeMender em ação: abra uma solicitação de pull que introduza uma nova vulnerabilidade e observe o CodeMender isolar o delta, bloquear a mesclagem em cerca de 15 a 25 segundos e anotar as linhas exatas que estão causando o problema.
Etapa 1: abrir uma solicitação de pull que introduza uma falha de injeção de comando
No Cloud Shell (no espaço de trabalho do repositório clonado), crie uma ramificação de recurso, adicione uma nova rota Express com uma vulnerabilidade de injeção de comando do SO e abra uma solicitação de pull na bifurcação:
[ -d .git ] || cd ~/"${GITHUB_REPO:-juice-shop}"
export GITHUB_REPOSITORY="${GITHUB_REPOSITORY:-$(git remote get-url origin 2>/dev/null | sed -E 's#^.*github\.com[:/]##; s#\.git$##')}"
PRIMARY_BRANCH=$(git symbolic-ref --short refs/remotes/origin/HEAD | sed 's@^origin/@@')
# Reset any previous demo PR/branch so this step can be re-run cleanly
gh pr close feat/diagnostics --repo "${GITHUB_REPOSITORY}" --delete-branch 2>/dev/null || true
git checkout "${PRIMARY_BRANCH}"
git checkout -B feat/diagnostics
# Introduce an Express endpoint vulnerable to OS Command Injection (CWE-78)
cat << 'EOF' > routes/diagnostics.ts
import { execSync } from 'node:child_process'
import { type Request, type Response } from 'express'
export function systemDiagnostics () {
return (req: Request, res: Response) => {
const host = String(req.query.host ?? '127.0.0.1')
const output = execSync(`ping -c 1 ${host}`).toString()
res.status(200).json({ status: 'ok', output })
}
}
EOF
git add routes/diagnostics.ts
git commit -m "feat: add network diagnostics endpoint"
git push -f -u origin feat/diagnostics
gh pr create \
--repo "${GITHUB_REPOSITORY}" \
--base "${PRIMARY_BRANCH}" \
--head feat/diagnostics \
--title "feat: add network diagnostics endpoint" \
--body "Adds a ping diagnostics handler."
Etapa 2: verificar o portão de mesclagem diferencial e a anotação inline da solicitação de envio
Abra o URL da solicitação de pull impresso no final da saída do terminal.
Role até a caixa Verificações na parte de baixo da página de conversa da solicitação de pull e observe a Verificação autônoma de vulnerabilidades de código:
Velocidade delta: em vez de verificar todos os mais de 680 arquivos no repositório (cerca de 3 a 5 minutos), o cm find . --diff="origin/${PRIMARY_BRANCH}" limita a análise estritamente a routes/diagnostics.ts (e a qualquer autor de chamada de 1 salto), concluindo a verificação em cerca de 15 a 25 segundos.
Isolamento de dívida legada e bloqueio de mesclagem: nenhuma das 28 vulnerabilidades legadas intocadas do Juice Shop falha na verificação. Somente a injeção de comando CRITICAL recém-introduzida aciona --fail-on="CRITICAL,HIGH", saindo com o código de status 1 (❌ vermelho) para bloquear a mesclagem do PR.
Clique na guia Files changed na parte de cima da solicitação de pull:
Como a proteção de código de saída do fluxo de trabalho (steps.scan.outputs.completed == 'true') ainda exporta e faz upload de results.sarif quando --fail-on sai com o código 1, a verificação de código do GitHub renderiza uma anotação de segurança inline CodeMender — Critical diretamente em execSync em routes/diagnostics.ts.
Etapa 3: limpar o PR de teste e voltar para a ramificação principal
Volte o espaço de trabalho do Cloud Shell para a ramificação principal e feche a solicitação de pull de teste não segura antes de prosseguir para a correção autônoma:
[ -d .git ] || cd ~/"${GITHUB_REPO:-juice-shop}"
export GITHUB_REPOSITORY="${GITHUB_REPOSITORY:-$(git remote get-url origin 2>/dev/null | sed -E 's#^.*github\.com[:/]##; s#\.git$##')}"
PRIMARY_BRANCH=$(git symbolic-ref --short refs/remotes/origin/HEAD | sed 's@^origin/@@')
git checkout "${PRIMARY_BRANCH}"
gh pr close feat/diagnostics --repo "${GITHUB_REPOSITORY}" --delete-branch
git branch -D feat/diagnostics 2>/dev/null || true
9. Criar o fluxo de trabalho de correção autônoma e PR automático
Agora que o portão de solicitação de pull impede que novas vulnerabilidades entrem na base de código, você vai implantar a correção autônoma (.github/workflows/codemender-remediate.yml) para corrigir ativamente as vulnerabilidades atuais e abrir solicitações de pull prontas para revisão.
Etapa 1: fazer o download do arquivo do fluxo de trabalho de correção
O CodeMender oferece dois modelos de correção, dependendo da visibilidade do repositório:
Repositórios públicos / de código aberto (codemender-remediate.yml): Modo de divulgação responsável: links para alertas SARIF de verificação de código do GitHub sem expor publicamente vetores de exploração brutos.
Repositórios privados / corporativos (codemender-remediate-private-repo.yml): Modo de evidência de auditoria interna: incorpora artefatos de verificação (PLAN.md, REPORT.md, exploit.sh) em seções de RP recolhíveis, excluindo-os dos commits do Git.
Faça o download do fluxo de trabalho de correção de segurança pública no seu repositório:
mkdir -p .github/workflows
curl -fsSL https://raw.githubusercontent.com/edwardc-gcp/codemender-github-actions/main/.github/workflows/codemender-remediate.yml \
-o .github/workflows/codemender-remediate.yml
Etapa 2: confirmar e acionar o fluxo de trabalho de correção autônoma
Confirme e envie o fluxo de trabalho de correção para sua ramificação principal:
git add .github/workflows/codemender-remediate.yml
git commit -m "ci: add CodeMender autonomous remediation workflow"
git push origin $(git branch --show-current)
No navegador, acesse a guia Ações do repositório do GitHub.
Na barra lateral esquerda, em Fluxos de trabalho, selecione Correção de segurança autônoma e PR automático do CodeMender.
Clique no menu suspenso verde Executar fluxo de trabalho à direita:
Usar fluxo de trabalho de: verifique se a ramificação padrão (master) está selecionada.
ID ou prefixo da descoberta específica a ser corrigida: insira o prefixo de 8 caracteres para routes/login.ts anotado na Etapa 7 (por exemplo, cd47b38a). Se você deixar esse campo em branco, a correção em lote será executada em todas as descobertas críticas e altas em aberto (cerca de 10 a 15 minutos). A segmentação de um único ID é concluída em cerca de 45 a 60 segundos.
Clique no botão verde Executar fluxo de trabalho dentro do popover e abra a execução em andamento.
Dentro de codemender-remediate.yml: síntese autônoma de patches
Enquanto o CodeMender sintetiza o patch na nuvem (cerca de 30 a 45 segundos), inspecione como codemender-remediate.yml (linhas 111 a 184) organiza a correção dentro do executor:
Retomada sem verificação (cm report import): faz o download do artefato codemender-findings.json do fluxo de trabalho de verificação e o importa para o espaço de trabalho (cm report import -f codemender-findings.json), voltando para cm find . --quick somente se não houver um artefato anterior.
Síntese de patch sem interface (cm fix): fixa project_paths em $GITHUB_WORKSPACE, canaliza < /dev/null para evitar travamentos interativos e transmite --no-reset durante loops em lote para que as correções cumulativas sejam preservadas entre as descobertas:
# Executed inside the GitHub Actions runner (codemender-remediate.yml)
cm fix "${SPECIFIC_TARGET}" --sandbox=false --yes --bypass-warning < /dev/null
Limpar commits de produção ( linhas 155–252): limpa .cm_project, .exploit/ e arquivos temporários via .git/info/exclude antes que peter-evans/create-pull-request@v8 abra a ramificação (codemender/auto-remediation-${{ github.run_id }}), confirmando estritamente as mudanças no código de produção:
--- a/routes/login.ts
+++ b/routes/login.ts
@@ -28,8 +28,8 @@ module.exports = function login () {
- models.sequelize.query(`SELECT * FROM Users WHERE email = '${req.body.email || ''}' AND password = '${security.hash(req.body.password || '')}' AND deletedAt IS NULL`, { model: models.User })
+ models.sequelize.query('SELECT * FROM Users WHERE email = :email AND password = :password AND deletedAt IS NULL', {
+ replacements: { email: req.body.email || '', password: security.hash(req.body.password || '') },
+ model: models.User
+ })
Etapa 3: analisar a solicitação de pull recém-aberta no GitHub
Navegue até a guia Solicitações de pull no repositório e abra a nova solicitação de pull (por exemplo, 🛡️ [CodeMender] Fix: SQL Injection in User Authentication Route).
Clique em Arquivos alterados para confirmar que apenas routes/login.ts foi modificado, com todos os metadados de ambiente de execução internos excluídos.
Analise a descrição da solicitação de envio que leva diretamente ao alerta da verificação de código do GitHub (SARIF) para aprovação do mantenedor.
10. Resolver problemas de casos extremos e repositórios particulares
Repositórios privados sem o GitHub Advanced Security (GHAS)
Os repositórios públicos do GitHub recebem ingestão SARIF de verificação de código do GitHub sem custo financeiro e ilimitada. No entanto, se você implantar esse fluxo de trabalho em um repositório privado do Enterprise que não tenha uma licença ativa do GitHub Advanced Security (GHAS), a etapa upload-sarif vai falhar com:
HTTP 403: Advanced Security must be enabled for this repository to use code scanning.
Resolução: fallback do relatório HTML interativo independente
O gerador de relatórios HTML integrado do CodeMender (cm report -f html) cria um painel de segurança interativo e independente com cards de métricas de gravidade, snippets de código com destaque de sintaxe e números de linha, além de um visualizador de diferenças de patch inline sem dependências da Web externas.
Para oferecer suporte a repositórios privados sem uma licença do GHAS, atualize .github/workflows/codemender-scan.yml para arquivar um artefato de relatório HTML em vez de fazer upload do SARIF:
Gerar o relatório HTML independente: na etapa Export Security Reports & Publish Job Summary, exporte um painel HTML com o resumo em Markdown usando cm report -f html > codemender-audit-report.html.
Arquivar o relatório como um artefato de fluxo de trabalho: substitua a etapa Upload SARIF Report to GitHub Code Scanning (github/codeql-action/upload-sarif@v4) por actions/upload-artifact@v4 configurada para fazer upload de codemender-audit-report.html (por exemplo, com o nome de artefato codemender-security-report).
Inspecione localmente em qualquer navegador: faça o download de codemender-security-report.zip diretamente da página de resumo da execução do fluxo de trabalho do GitHub Actions, extraia o arquivo e abra codemender-audit-report.html em qualquer navegador da Web para fazer uma triagem visual.
Remediação autônoma de repositório particular com evidências de auditoria incorporadas
Em repositórios corporativos privados, as equipes de engenharia e segurança precisam de visibilidade total da análise de causa raiz, da prova de conceito de exploração e do plano de correção sem precisar de painéis de ferramentas externas. No entanto, o commit de scripts de exploit (exploit.sh) ou arquivos Markdown internos (PLAN.md, LOG.md) na ramificação do repositório polui o histórico do Git e pode acionar alertas falsos de outros scanners de segurança.
Para resolver isso, implante o fluxo de trabalho de correção de repositório particular (codemender-remediate-private-repo.yml):
curl -fsSL https://raw.githubusercontent.com/edwardc-gcp/codemender-github-actions/main/.github/workflows/codemender-remediate-private-repo.yml \
-o .github/workflows/codemender-remediate.yml
git add .github/workflows/codemender-remediate.yml
git commit -m "ci: switch to private repository remediation workflow with embedded audit evidence"
git push origin $(git branch --show-current)
Como funciona a correção de repositórios particulares
Verificação dinâmica de PoC (cm verify): sintetiza e testa um exploit funcional antes de gerar a correção para confirmar a capacidade de exploração, ignorando automaticamente cm fix se a verificação marcar uma descoberta não explorável como DISMISSED.
Elementos recolhíveis de auditoria de RP incorporados: extrai REPORT.md, PLAN.md e exploit.sh em /tmp/codemender-evidence/ e os formata diretamente na descrição da solicitação de pull dentro de blocos recolhíveis <details open> para inspeção do revisor com um clique.
Arquivamento de artefatos: arquiva a pasta de evidências completa usando actions/upload-artifact@v4.
Commits do Git limpos: limpa todos os metadados de ambiente de execução e diretórios .exploit para que o commit do Git da solicitação de pull contenha estritamente mudanças no código de produção.
Lista de verificação para solução de problemas da federação de identidade da carga de trabalho (WIF)
Por padrão, o google-github-actions/auth@v2 grava um arquivo de configuração de credencial federada local durante a configuração, e a troca real de token do OAuth 2.0 ocorre quando o cm health --strict ou o cm find é iniciado. Use a lista de verificação abaixo para diagnosticar erros de autenticação HTTP 400 ou HTTP 403:
Sintoma do erro | Causa raiz comum | Verificação e correção |
HTTP 403 ( | Vinculação | Confirme se |
HTTP 400 ( | O nome (ou as letras maiúsculas/minúsculas) do repositório OIDC | Execute novamente a Etapa 4 (Etapas 1 e 6) garantindo que |
HTTP 400 ( | Mapeamento de | Confirme se |
HTTP 403 temporário imediatamente após a configuração | A propagação global do IAM e da federação de identidade da carga de trabalho pode levar de 1 a 5 minutos em vinculações recém-criadas. | Aguarde de 1 a 2 minutos e clique em Re-run failed jobs no GitHub Actions. |
Para inspecionar a vinculação ativa da Identidade da carga de trabalho na sua conta de serviço de CI/CD no Cloud Shell, execute:
gcloud iam service-accounts get-iam-policy "${SERVICE_ACCOUNT_EMAIL}" \
--project="${PROJECT_ID}" \
--flatten="bindings[].members" \
--filter="bindings.role=roles/iam.workloadIdentityUser"
Confirme se a saída vincula roles/iam.workloadIdentityUser a principalSet://iam.googleapis.com/<POOL_ID>/attribute.repository/<GITHUB_USER>/<GITHUB_REPO>:
--- bindings: members: principalSet://iam.googleapis.com/.../attribute.repository/<OWNER>/<REPO> role: roles/iam.workloadIdentityUser
Pré-lançamento de CI/CD e solução de problemas de código de saída da CLI
Os comandos do CodeMender (cm health --strict, cm find, cm verify e cm fix) retornam códigos de saída determinísticos para que os pipelines de CI/CD possam distinguir imediatamente as descobertas de segurança de erros de configuração ou de serviço:
Código de saída | Categoria | Causa raiz comum e correção |
| Sucesso | As verificações de integridade foram aprovadas ou a verificação foi concluída sem descobertas de bloqueio. |
| Descobertas / Geral |
|
|
| Falha na troca de token OAuth/ADC da WIF ( |
|
| Sintaxe |
|
| O executor não consegue acessar |
|
| A conta de serviço não tem |
|
| A verificação de simulação |
|
| O agente atingiu o limite de tarefas ativas simultâneas. Execute o fluxo de trabalho novamente após um breve atraso. |
Para outros erros de tempo de execução, como resolução de ramificação base do Git diff (fetch-depth: 0), atrasos na propagação de recursos ou permissões de criação de solicitações de pull do GitHub Actions, consulte o Guia oficial de solução de problemas de CI/CD do CodeMender.
11. Limpar recursos
Para evitar o consumo contínuo de recursos ou limpar as configurações de teste nos ambientes do Google Cloud e do GitHub, siga as etapas de limpeza abaixo.
Etapa 1: remover os secrets do repositório do GitHub e desativar os fluxos de trabalho usando a CLI gh
Use a CLI do GitHub (gh) para excluir os secrets de ações do repositório e desativar os fluxos de trabalho do CodeMender:
# Delete the repository Actions secrets
gh secret delete GCP_WORKLOAD_IDENTITY_PROVIDER --repo "${GITHUB_REPOSITORY}" 2>/dev/null || true
gh secret delete GCP_SERVICE_ACCOUNT --repo "${GITHUB_REPOSITORY}" 2>/dev/null || true
# Disable the CodeMender workflows to prevent unwanted automatic triggers
gh workflow disable codemender-scan.yml --repo "${GITHUB_REPOSITORY}" 2>/dev/null || true
gh workflow disable codemender-remediate.yml --repo "${GITHUB_REPOSITORY}" 2>/dev/null || true
Etapa 2: desativar ou excluir recursos da federação de identidade da carga de trabalho do Google Cloud
Os pools de identidade da carga de trabalho, os provedores e as contas de serviço têm custo zero de inatividade quando não estão trocando tokens. Escolha o modo de limpeza que corresponde ao seu fluxo de trabalho:
Opção A: pausar o acesso (recomendado se você planeja executar novamente neste projeto): desativa a troca de tokens OIDC imediatamente sem acionar a retenção de exclusão reversível de 30 dias do Cloud IAM do Google Cloud ou os atrasos de propagação da conta de serviço uniqueId:
gcloud iam workload-identity-pools providers update-oidc "${WORKLOAD_IDENTITY_PROVIDER}" \
--workload-identity-pool="${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--disabled \
--project="${PROJECT_ID}"
Opção B — Desativação completa: exclui o provedor de WIF, o pool (mantido no estado DELETED por 30 dias) e a conta de serviço dedicada:
# Delete Workload Identity Provider
gcloud iam workload-identity-pools providers delete "${WORKLOAD_IDENTITY_PROVIDER}" \
--workload-identity-pool="${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--project="${PROJECT_ID}" \
--quiet
# Delete Workload Identity Pool
gcloud iam workload-identity-pools delete "${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--project="${PROJECT_ID}" \
--quiet
# Delete CI/CD Service Account
gcloud iam service-accounts delete "${SERVICE_ACCOUNT_EMAIL}" \
--project="${PROJECT_ID}" \
--quiet
12. Parabéns
Parabéns! Você concluiu o codelab Proteger seu pipeline de CI/CD com o CodeMender.
Você projetou, criou e automatizou um pipeline de DevSecOps de nível de produção e de confiança zero usando a federação de identidade da carga de trabalho do Google Cloud, o CodeMender e o GitHub Actions.
O que você aprendeu
Autenticação sem chave de confiança zero: eliminou as chaves JSON de conta de serviço de longa duração e arriscadas ao vincular tokens OIDC temporários do GitHub ao Cloud IAM do Google Cloud usando a federação de identidade da carga de trabalho (WIF, na sigla em inglês).
Verificação de AST diferencial de PR e supressão de ruído legado: verificação contínua com escopo para arquivos modificados e dependentes (--diff="origin/$BASE_REF"), isolando a dívida técnica legada ([LEGACY / UNTOUCHED]) para manter os loops de feedback do desenvolvedor em menos de 15 segundos.
Relatórios multiformato e resumos de jobs nativos: OASIS SARIF v2.1.0 combinado para verificação de código centralizada do GitHub com Markdown nativo (cm report -f md >> $GITHUB_STEP_SUMMARY) para visibilidade executiva instantânea diretamente nas páginas de execução do fluxo de trabalho de CI.
Correção autônoma com revisão human-in-the-loop: fomos além das notificações de alerta passivas para pipelines de correção ativa que sintetizam de forma autônoma os patches de código propostos, verificam em relação a pacotes de teste de regressão e abrem solicitações de pull de revisão com artefatos de auditoria para aprovação do engenheiro.
Portões de qualidade automatizados: aplicamos uma proteção rigorosa de ramificações e portões de mesclagem (--fail-on) para impedir que vulnerabilidades perigosas cheguem à produção.
Transferência de estado orientada por artefatos e isolamento do espaço de trabalho: transferiu as descobertas de forma integrada entre jobs de CI usando cm report import, enquanto usava .git/info/exclude para preservar o histórico original do Git e evitar o vazamento de credenciais.
Mudança de mentalidade do desenvolvedor
Prática tradicional de DevSecOps | Pipeline de CI/CD autônomo do CodeMender |
Despejo de alertas passivos: os scanners mostram registros brutos do terminal ou listas de erros estáticas, transferindo todo o trabalho de triagem para os desenvolvedores. | Desenvolvedor ativo: sintetiza patches de código verificados e abre solicitações de pull prontas para mesclagem para aprovação do engenheiro. |
Alto número de falsos positivos: as heurísticas de AST estática sinalizam milhares de vulnerabilidades teóricas sem prova de que podem ser exploradas. | Verificação de exploit em dois níveis: a geração dinâmica de testes de sandbox ( |
Armazenamento de secrets arriscado: as chaves JSON de contas de serviço de longa duração armazenadas em secrets de CI correm o risco de vazamentos acidentais e proliferação de credenciais. | WIF de confiança zero: autenticação sem chave por meio de tokens OIDC temporários trocados com o STS do Google Cloud sob demanda. |
Nova verificação monolítica: cada commit aciona auditorias completas do repositório, atrasando os fluxos de trabalho de CI e desperdiçando tokens caros. | Roteamento de AST com reconhecimento de eventos: as solicitações de pull executam verificações de AST diferenciais de 15 segundos ( |
Histórico de repositório poluído: scripts de exploit temporários e registros de ataque confirmados diretamente nas ramificações do repositório. | Higiene do espaço de trabalho empresarial: evidências de ataque incorporadas de forma limpa nas descrições de PR e nos artefatos de fluxo de trabalho, mantendo os commits de código puros. |
Próximas etapas
🚀 Continue a jornada de aprendizado do CodeMender:
Parte 1: Proteja seu aplicativo com o CodeMender — Domine a descoberta autônoma de vulnerabilidades em repositórios, a verificação de exploits de PoC e a síntese de patches locais.
Shift Left local e CI/CD nativo da nuvem sem servidor: confira as implementações de referência do guia oficial de CI/CD para o Google Cloud Build (cloudbuild.yaml) e os hooks de pré-commit do Git local (cm find . --diff --staged).
📖 Explore a documentação e os recursos:
Guia oficial de integração de CI/CD do Google Cloud CodeMender
Documentação oficial do Google Cloud CodeMender
Repositório de modelos iniciais do GitHub Actions do CodeMender
Documentação da federação de identidade da carga de trabalho do Google Cloud
💡 Aplique aos seus próprios repositórios:
Crie uma bifurcação do fluxo de trabalho inicial e proteja os repositórios Python, Go, Java, Rust e Node.js da sua organização com o CodeMender.