1. Antes de comenzar
Te damos la bienvenida al codelab práctico para proteger tu canalización de CI/CD con CodeMender.
En la entrega de software moderna, las herramientas de análisis estático (como CodeQL) son esenciales para detectar patrones sintácticos conocidos, pero suelen pasar por alto vulnerabilidades sutiles ocultas en la lógica empresarial y generan alertas ruidosas y no verificadas.
CodeMender (ejecutable de la CLI: cm) mejora tu canalización de CI/CD, que opera junto con las herramientas de SAST existentes, a través de la implementación de agentes de razonamiento de seguridad potenciados por Gemini de Google para lo siguiente:
Descubre fallas complejas en la lógica empresarial: Razona sobre el contexto de la aplicación y los flujos de datos de la arquitectura más allá de las reglas rígidas de patrones estáticos.
Reduce drásticamente los falsos positivos a través de la verificación de autoexplotación: Demuestra de forma dinámica la explotabilidad en entornos de zona de pruebas antes de alertar a los desarrolladores.
Corrige de forma autónoma los hallazgos verificados: Sintetiza parches de código, valida con paquetes de pruebas para evitar regresiones y envía solicitudes de extracción listas para su revisión.
En este codelab, integrarás CodeMender en el repositorio de OWASP Juice Shop con GitHub Actions y la federación de identidades para cargas de trabajo (WIF) de Google Cloud sin claves.
Requisitos previos
- Recomendado: Conocimientos básicos de los conceptos de CodeMender (que se explican en Protege tu aplicación con CodeMender)
- Conocimientos básicos de los flujos de trabajo, los activadores y la sintaxis YAML de GitHub Actions
- Conocimientos básicos de los comandos de Git y los flujos de trabajo de revisión de solicitudes de extracción
- Conocimientos básicos de los conceptos de Cloud IAM de Google Cloud (cuentas de servicio, roles y APIs)
- Familiaridad con las vulnerabilidades comunes de las aplicaciones web (como la inyección de SQL y XSS)
Qué aprenderás
- Cómo configurar la autenticación sin clave de confianza cero entre GitHub Actions y Google Cloud a través de la federación de identidades para cargas de trabajo (WIF)
- Cómo crear un flujo de trabajo de análisis de vulnerabilidades automatizado con CodeMender y
gemini-3.8-flash - Cómo publicar informes de seguridad prácticos con OASIS SARIF v2.1.0 y resúmenes de trabajos de GitHub Actions nativos
- Cómo construir un flujo de trabajo de corrección autónomo que genere parches de código verificados por pruebas y abra solicitudes de extracción para la revisión humana
- Cómo aplicar puertas de calidad automatizadas (
--fail-on) y almacenamiento en caché de canalizaciones para una seguridad continua de alta velocidad
Requisitos
- Un proyecto de Google Cloud con la facturación habilitada y permisos de Propietario del proyecto o editor
- Una cuenta de GitHub con permisos para crear repositorios, configurar Secrets y administrar Actions (bifurcarás el repositorio de GitHub de OWASP Juice Shop en el paso 3 con la CLI de GitHub)
2. Comprende la arquitectura de CI/CD de CodeMender
En las DevSecOps empresariales modernas, la seguridad potenciada por IA no puede ser simplemente una herramienta de escritorio manual. Debe funcionar como un controlador de acceso automatizado (que bloquee las solicitudes de extracción no seguras) y un codesarrollador autónomo (que proponga parches verificados directamente en Git).
Para lograrlo, implementarás una arquitectura de flujo de trabajo doble con la tecnología de la federación de identidades para cargas de trabajo (WIF) de Google Cloud y los modelos de razonamiento de Gemini Enterprise.
Arquitectura de flujo de trabajo doble
En lugar de incluir la detección y la corrección en una sola secuencia de comandos monolítica, la canalización separa la seguridad en dos flujos de trabajo independientes y diseñados para un propósito específico:
Flujo de trabajo | Activador principal | Responsabilidad principal | Control de calidad estricto |
1. Escáner de vulnerabilidades( | Solicitudes de extracción, envíos principales, cron semanal, envío manual | • Ejecuta análisis de AST diferenciales rápidos en las solicitudes de extracción (~15 s), análisis de referencia rápidos en las confirmaciones ( | Bloquea la combinación de PR si se detectan vulnerabilidades altas o críticas recién introducidas ( |
2. Autonomous Remediator( | Activador manual ( | • Reanuda el estado a partir de los artefactos de análisis ( | Garantiza diferencias de producción limpias antes de abrir una solicitud de extracción. |
Tres principios básicos del diseño empresarial
A medida que crees estos flujos de trabajo en las próximas secciones, ten en cuenta estos tres pilares arquitectónicos fundamentales:
🔑 Autenticación sin claves de confianza cero y validación preliminar:
No se almacenan claves JSON de cuentas de servicio de Google Cloud de larga duración en los secretos de GitHub. El ejecutor genera un token de OIDC de corta duración que se intercambia a través de STS de Google Cloud por una credencial efímera de 1 hora, establece persist-credentials: false en las confirmaciones de Git y ejecuta cm health --strict para verificar las credenciales, la accesibilidad de la red y los permisos de IAM antes de consumir la cuota del modelo.
⚡ Enrutamiento de análisis adaptable y reducción de ruido heredada:
En lugar de ejecutar auditorías lentas de todo el repositorio en cada solicitud de extracción, CodeMender enruta cada evento de CI al modo de análisis óptimo: las solicitudes de extracción activan un análisis AST diferencial (--diff="origin/$BASE_REF") en los archivos modificados y los llamadores de 1 salto en menos de 15 segundos; las confirmaciones de la rama principal ejecutan análisis de referencia rápidos de una sola sesión (--quick); y las programaciones semanales ejecutan auditorías profundas simultáneas archivo por archivo (cm find . predeterminado). Las vulnerabilidades de la base de código preexistentes que no se modificaron con una solicitud de extracción se etiquetan como [LEGACY / UNTOUCHED]; aparecen en los informes de SARIF para mayor visibilidad, pero no bloquean la puerta de fusión de la solicitud de extracción y no activan la corrección automática.
🛡️ Observabilidad de seguridad resiliente y sin bloqueos:
Incluso cuando --fail-on sale con el código 1 para bloquear una solicitud de extracción no segura, proteger los pasos de exportación de informes y carga de SARIF con steps.scan.outputs.completed == 'true' y hashFiles('results.sarif') != '' garantiza que las alertas de SARIF de OASIS y los resúmenes de trabajos se sigan publicando, mientras que se omiten limpiamente la exportación y la carga si una ejecución se cancela o se anula debido a un error de configuración o capacidad (10–60).
3. Autentica y prepara el repositorio de destino en Cloud Shell
Para establecer la autenticación sin claves y ejecutar canalizaciones de seguridad automatizadas, necesitas un repositorio de GitHub de destino accesible que sea de tu propiedad. En este codelab, usarás OWASP Juice Shop, una aplicación web de Node.js que es vulnerable de forma intencional, como un entorno de pruebas de seguridad listo para usar.
Usarás la CLI de GitHub (gh), preinstalada en Google Cloud Shell, para autenticarte con GitHub, capturar tus detalles de usuario automáticamente y preparar tu repositorio en un flujo optimizado.
Paso 1: Abre Cloud Shell y autentica la CLI de GitHub
Abre la consola de Google Cloud y activa Cloud Shell (ícono >_ en la barra de navegación superior).
Autentica la CLI de GitHub (gh) para configurar la administración de credenciales de Git:
gh auth login --hostname github.com --git-protocol https --web
Sigue las instrucciones en pantalla:
Copia el código de un solo uso de 8 caracteres que se muestra en Cloud Shell (p.ej., 1234-ABCD).
Presiona Intro para abrir https://github.com/login/device en el navegador.
Pega el código y haz clic en Autorizar github.
Paso 2: Exporta variables de forma dinámica y bifurca OWASP Juice Shop
Ejecuta los siguientes comandos en Cloud Shell para capturar automáticamente tu nombre de usuario de GitHub y preparar el repositorio:
# 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. Configura la federación de identidades para cargas de trabajo de Google Cloud a través de gcloud
En este paso, usarás la CLI de gcloud en Google Cloud Shell para habilitar las APIs necesarias, crear una cuenta de servicio de CI/CD dedicada, configurar el grupo de identidades para cargas de trabajo y establecer una relación de confianza de OIDC con tu repositorio de GitHub (${GITHUB_REPOSITORY}).
Paso 1: Configura las variables de entorno de Google Cloud
En la terminal de Cloud Shell (dentro del espacio de trabajo del repositorio clonado), captura el ID del proyecto de Google Cloud activo, verifica la variable del repositorio de GitHub y define los nombres de los recursos de 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
Paso 2: Habilita las APIs de Google Cloud requeridas
Habilita la API de IAM, la API de Security Token Service, la API de credenciales de IAM, la API de Agent Platform y la API de Resource Manager:
gcloud services enable \
iam.googleapis.com \
iamcredentials.googleapis.com \
sts.googleapis.com \
aiplatform.googleapis.com \
cloudresourcemanager.googleapis.com \
--project=${PROJECT_ID}
Paso 3: Crea una cuenta de servicio de CI/CD dedicada
Crea una cuenta de servicio de Google Cloud con privilegios mínimos dedicada a la ejecución de la canalización de CI/CD (reutilízala de forma segura si ya existe):
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}"
Paso 4: Otorga permisos de IAM de Agent Platform
Otorga el rol roles/aiplatform.user (Usuario de Agent Platform) a la cuenta de servicio para que pueda comunicarse con Gemini Enterprise Agent Platform:
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
--member="serviceAccount:${SERVICE_ACCOUNT_EMAIL}" \
--role="roles/aiplatform.user"
Paso 5: Crea el grupo de identidades para cargas de trabajo
Crea el grupo de identidades para cargas de trabajo para administrar las aserciones de identidad de GitHub Actions (o restáuralo y habilítalo automáticamente si ya existe en tu proyecto):
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
Paso 6: Crea el proveedor de Workload Identity con OIDC de GitHub
Crea (o actualiza) el proveedor de OIDC dentro del grupo, vincula la URL de la entidad emisora https://token.actions.githubusercontent.com y asigna las aserciones de tokens de GitHub a los atributos de STS de 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
Paso 7: Permite que el repositorio de GitHub actúe en nombre de la cuenta de servicio
Vincula el rol roles/iam.workloadIdentityUser para permitir que los tokens que se originan en tu repositorio actúen en nombre de la cuenta de servicio del ejecutor de CI y verifica la vinculación de la 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
Paso 8: Recupera los valores de configuración de los secretos de GitHub
Recupera el nombre completo del recurso de tu proveedor de identidades para cargas de trabajo y almacénalo en una variable de entorno para el registro automatizado en el siguiente paso:
# 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. Configura los secretos del repositorio de GitHub y los permisos del flujo de trabajo
Ahora que se aprovisionó la WIF de Google Cloud, configurarás los secretos del repositorio de GitHub y otorgarás los permisos de flujo de trabajo necesarios para el análisis de seguridad automatizado y las solicitudes de extracción de corrección automática.
Puedes establecer estos parámetros de configuración directamente desde Cloud Shell con la CLI de GitHub (gh), lo que elimina por completo la necesidad de copiar y pegar manualmente nombres de recursos largos.
Paso 1: Configura los secretos del repositorio con la CLI de GitHub
En la terminal de Cloud Shell, ejecuta los siguientes comandos para configurar de forma segura los dos secretos de repositorio requeridos con las variables de entorno activas:
# 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}"
Paso 2: Otorga permisos de flujo de trabajo para las PR automatizadas
De forma predeterminada, los flujos de trabajo de GitHub Actions se ejecutan con permisos de solo lectura y no pueden crear solicitudes de extracción. En el paso 9, CodeMender generará y enviará de forma autónoma solicitudes de extracción de corrección verificadas.
Otorga permisos de escritura y habilita la creación de solicitudes de extracción directamente a través de la API de 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
Paso 3: Inhabilita los flujos de trabajo heredados de Juice Shop ascendentes
La bifurcación de OWASP Juice Shop transfiere 16 flujos de trabajo de CI ascendentes (como PR Compliance Check, CI/CD Pipeline y CodeQL Scan) junto con una plantilla de PR de colaborador ascendente que cierra automáticamente las PR orientadas a master. Inhabilita todos los flujos de trabajo que no sean de CodeMender a través de la CLI de GitHub y quita los archivos upstream de forma local para que tu bifurcación ejecute estrictamente los flujos de trabajo de 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. Compila el flujo de trabajo de análisis de vulnerabilidades automatizado con SARIF
En este paso, crearás el flujo de trabajo principal de análisis de seguridad continuo (.github/workflows/codemender-scan.yml) que ejecuta análisis de referencia en las confirmaciones de ramas, puertas diferenciales en las solicitudes de extracción y exportaciones de SARIF al análisis de código de GitHub.
Paso 1: Descarga el flujo de trabajo de análisis de CodeMender
Descarga codemender-scan.yml del repositorio de inicio en .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
Paso 2: Confirma, envía y activa el análisis de CI
Confirma los cambios en el flujo de trabajo y envíalos directamente a la rama principal de tu repositorio (master para Juice Shop o 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)
En el navegador:
Navega a tu repositorio de GitHub bifurcado: https://github.com/YOUR_GITHUB_USER/juice-shop (p.ej., https://github.com/octocat/juice-shop).
Haz clic en la pestaña Acciones en la barra de navegación superior.
En la barra lateral izquierda, en Flujos de trabajo, selecciona CodeMender Security Scan & SARIF Export.
Activa o visualiza la ejecución del flujo de trabajo:
Activación automática: Si aparece una ejecución automática activada por tu envío, haz clic en ella directamente para supervisar la ejecución en vivo.
Activador manual on demand (workflow_dispatch): Si aún no se inició ninguna ejecución, haz clic en el botón Ejecutar flujo de trabajo ▾ de la derecha, asegúrate de que esté seleccionado Branch: master (deja desmarcada la casilla de verificación deep_scan para que se ejecute el análisis rápido de referencia de --quick) y haz clic en el botón verde Ejecutar flujo de trabajo.
Haz clic en la ejecución en curso y selecciona Autonomous Code Vulnerability Scan para ver cómo se inicia el flujo de trabajo en tiempo real.
Dentro de codemender-scan.yml: Enrutamiento de análisis adaptado a eventos
Mientras se ejecuta el análisis de referencia de --quick en la nube (entre 3 y 5 minutos), inspecciona cómo codemender-scan.yml (líneas 118 a 155) enruta cada evento de GitHub a su modo de análisis dedicado dentro del ejecutor:
# 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
Configuración del ejecutor reforzado ( líneas 27 a 117): Omite las bifurcaciones externas no confiables y las PR de dependabot[bot], realiza la confirmación con persist-credentials: false, almacena en caché ~/.local/bin/cm y ~/.codemender/state.db, y ejecuta cm health --strict antes de consumir la cuota del modelo.
Límites de la zona de pruebas sin interfaz gráfica (--sandbox=false --yes --bypass-warning): Inhabilita el aislamiento del espacio de nombres de usuario de Linux (restringido dentro de contenedores de GitHub Actions sin privilegios) y, al mismo tiempo, mantiene los límites de la ruta de acceso del espacio de trabajo (project_paths) y command_policy.yaml aplicados.
Exportación de artefactos y SARIF protegidos por código de salida ( líneas 147 a 194): Establece steps.scan.outputs.completed=true estrictamente cuando cm find sale con 0 (limpio) o 1 (se alcanzó el umbral de --fail-on). Esto garantiza que los informes de SARIF (cm report -f sarif con puntuaciones de gravedad de CVSS), las tablas de $GITHUB_STEP_SUMMARY (cm report -f md) y los artefactos de codemender-findings.json se sigan publicando cuando --fail-on bloquee una solicitud de extracción, mientras se omite la exportación en caso de errores de configuración o capacidad (10–60) para que los archivos SARIF vacíos nunca cierren las alertas existentes.
7. Inspecciona las alertas de análisis de código y el panel de seguridad de GitHub
Una vez que finaliza el flujo de trabajo de envío de referencia, GitHub procesa el archivo SARIF subido y completa el resumen de ejecución de Actions y la pestaña Security del repositorio.
Paso 1: Inspecciona el resumen del trabajo nativo en GitHub Actions
Cada ejecución del flujo de trabajo agrega una tabla de resumen de Markdown (cm report -f md) directamente a la descripción general de la ejecución de GitHub Actions:
En tu repositorio de GitHub, haz clic en la pestaña Actions.
Selecciona la ejecución completada de CodeMender Security Scan & SARIF Export (las auditorías de envío de la rama de referencia finalizan con una marca de verificación verde ✅ después de publicar los hallazgos de SARIF).
Desplázate hacia abajo hasta la sección 🛡️ CodeMender Security Scan Summary para inspeccionar el desglose de los hallazgos:
🔒 Informe de seguridad de CodeMender
Resumen
Total de hallazgos: 28
Gravedad | Recuento |
🔴 CRÍTICO | 6 |
🟠 ALTO | 16 |
🟡 MEDIO | 6 |
Estado | Recuento |
🔴 ABIERTO | 28 |
Hallazgos
ID | Gravedad | Confianza | Estado | Corrección | Archivo | Título |
| 🔴 CRÍTICO | 100% | ABRIR | — |
| Ejecución remota de código a través de la inserción de código del servidor en el perfil de usuario |
| 🔴 CRÍTICO | 100% | ABRIR | — |
| Inyección de SQL en la ruta de autenticación del usuario |
| 🔴 CRÍTICO | 100% | ABRIR | — |
| Ejecución remota de código a través de un escape de zona de pruebas en el procesamiento de pedidos B2B |
Paso 2: Explora el panel centralizado de Code Scanning
En la barra de navegación superior de tu repositorio de GitHub, haz clic en la pestaña Security and quality (o Security).
En la barra lateral izquierda, en Hallazgos, selecciona Análisis de código.
Si hay varias herramientas activas, filtra Herramienta por CodeMender (is:open branch:master tool:CodeMender) para inspeccionar las alertas asignadas con insignias de gravedad de CVSS nativas:
Insignia de gravedad | Título de la vulnerabilidad | Ubicación detectada | Branch |
🔴 Crítica | Ejecución remota de código a través de la inserción de código del servidor en el perfil de usuario |
|
|
🔴 Crítica | Inyección de SQL en la ruta de autenticación del usuario |
|
|
🔴 Crítica | Ejecución remota de código a través de un escape de zona de pruebas en el procesamiento de pedidos B2B |
|
|
Haz clic en Inyección de SQL en la ruta de autenticación del usuario (routes/login.ts:34) para revisar el flujo de datos contaminado y el análisis de causa raíz sintetizado por Gemini.
8. Bloquea una solicitud de extracción no segura con el análisis diferencial
Tu análisis de referencia descubrió 28 vulnerabilidades preexistentes en OWASP Juice Shop. Con los analizadores estáticos tradicionales, esos 28 hallazgos heredados harían que fallaran todas las solicitudes de extracción futuras hasta que se corrigiera todo el trabajo pendiente, lo que obligaría a los equipos a inhabilitar el bloqueo de fusiones.
Ahora, probarás la puerta de AST diferencial de PR (--diff + --fail-on="CRITICAL,HIGH") de CodeMender en acción: abrirás una solicitud de extracción que introduce una nueva vulnerabilidad y observarás cómo CodeMender aísla el delta, bloquea la combinación en ~15-25 segundos y anota las líneas ofensivas exactas.
Paso 1: Abre una solicitud de extracción que introduzca una falla de inyección de comandos
En Cloud Shell (dentro del espacio de trabajo de tu repositorio clonado), crea una rama de función, agrega una nueva ruta de Express que contenga una vulnerabilidad de inyección de comandos del SO y abre una solicitud de extracción en tu bifurcación:
[ -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."
Paso 2: Verifica la puerta de combinación diferencial y la anotación de PR intercalada
Abre la URL de la solicitud de extracción que se muestra al final del resultado de la terminal.
Desplázate hasta la casilla de verificación Checks en la parte inferior de la página de conversación de la solicitud de extracción y observa Autonomous Code Vulnerability Scan:
Velocidad delta: En lugar de analizar los más de 680 archivos del repositorio (lo que tarda entre 3 y 5 minutos), cm find . --diff="origin/${PRIMARY_BRANCH}" limita el análisis estrictamente a routes/diagnostics.ts (y a cualquier emisor de 1 salto), lo que completa el análisis en entre 15 y 25 segundos.
Aislamiento de deuda heredada y bloqueo de combinación: Ninguna de las 28 vulnerabilidades heredadas sin modificar de Juice Shop falla la verificación; solo la CRITICAL de inyección de comandos recién introducida activa --fail-on="CRITICAL,HIGH", lo que genera el código de estado 1 (❌ rojo) para bloquear la combinación de la solicitud de extracción.
Haz clic en la pestaña Files changed en la parte superior de la solicitud de extracción:
Debido a que la protección del código de salida del flujo de trabajo (steps.scan.outputs.completed == 'true') aún exporta y sube results.sarif cuando --fail-on sale con el código 1, el análisis de código de GitHub renderiza una anotación de seguridad intercalada CodeMender — Critical directamente debajo de execSync en routes/diagnostics.ts.
Paso 3: Limpia la solicitud de extracción de prueba y regresa a la rama principal
Cambia el espacio de trabajo de Cloud Shell de vuelta a la rama principal y cierra la solicitud de extracción de prueba no segura antes de continuar con la corrección 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. Compila el flujo de trabajo de corrección autónoma y de PR automática
Ahora que la puerta de enlace de la solicitud de extracción evita que ingresen nuevas vulnerabilidades a la base de código, implementarás la corrección autónoma (.github/workflows/codemender-remediate.yml) para corregir de forma activa las vulnerabilidades existentes y abrir solicitudes de extracción listas para su revisión.
Paso 1: Descarga el archivo del flujo de trabajo de corrección
CodeMender proporciona dos plantillas de corrección según la visibilidad del repositorio:
Repositorios públicos o de código abierto (codemender-remediate.yml): Modo de divulgación responsable: Se vincula a las alertas de SARIF de análisis de código de GitHub sin exponer públicamente los vectores de explotación sin procesar.
Repositorios privados o empresariales (codemender-remediate-private-repo.yml): Modo de evidencia de auditoría interna: Incorpora artefactos de verificación (PLAN.md, REPORT.md, exploit.sh) dentro de secciones de PR contraíbles y, al mismo tiempo, los excluye de las confirmaciones de Git.
Descarga el flujo de trabajo de corrección seguro para el público en tu repositorio:
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
Paso 2: Confirma y activa el flujo de trabajo de corrección autónoma
Confirma y envía el flujo de trabajo de corrección a tu rama principal:
git add .github/workflows/codemender-remediate.yml
git commit -m "ci: add CodeMender autonomous remediation workflow"
git push origin $(git branch --show-current)
En tu navegador, navega a la pestaña Acciones de tu repositorio de GitHub.
En la barra lateral izquierda, en Flujos de trabajo, selecciona CodeMender Autonomous Security Remediation & Auto-PR.
Haz clic en el menú desplegable verde Run workflow que se encuentra a la derecha:
Usar el flujo de trabajo de: Asegúrate de que esté seleccionada la rama predeterminada (master).
ID o prefijo de hallazgo específico que se debe corregir: Ingresa el prefijo de 8 caracteres para routes/login.ts que anotaste en el paso 7 (por ejemplo, cd47b38a). Si dejas este campo en blanco, se ejecutará la corrección por lotes en todos los hallazgos críticos y altos abiertos (entre 10 y 15 minutos aproximadamente). Si se orienta a un solo ID, se completa en entre 45 y 60 segundos aproximadamente.
Haz clic en el botón verde Run workflow dentro de la ventana emergente y abre la ejecución en curso.
Dentro de codemender-remediate.yml: Síntesis de parches autónoma
Mientras CodeMender sintetiza el parche en la nube (entre 30 y 45 segundos), inspecciona cómo codemender-remediate.yml (líneas 111 a 184) organiza la solución dentro del ejecutor:
Reanudación sin análisis (cm report import): Descarga el artefacto codemender-findings.json del flujo de trabajo de análisis y lo importa al espacio de trabajo (cm report import -f codemender-findings.json), recurriendo a cm find . --quick solo si no existe un artefacto previo.
Síntesis de parches sin interfaz gráfica (cm fix): Fija project_paths en $GITHUB_WORKSPACE, canaliza < /dev/null para evitar bloqueos interactivos y pasa --no-reset durante los bucles por lotes para que las correcciones acumulativas se conserven en todos los hallazgos:
# Executed inside the GitHub Actions runner (codemender-remediate.yml)
cm fix "${SPECIFIC_TARGET}" --sandbox=false --yes --bypass-warning < /dev/null
Clean Production Commits ( líneas 155 a 252): Limpia .cm_project, .exploit/ y los archivos temporales a través de .git/info/exclude antes de que peter-evans/create-pull-request@v8 abra la rama (codemender/auto-remediation-${{ github.run_id }}), confirmando estrictamente los cambios en el código de producción:
--- 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
+ })
Paso 3: Revisa la solicitud de extracción recién abierta en GitHub
Navega a la pestaña Solicitudes de extracción en tu repositorio y abre la nueva solicitud de extracción (p.ej., 🛡️ [CodeMender] Fix: SQL Injection in User Authentication Route).
Haz clic en Files changed para confirmar que solo se modificó routes/login.ts, sin incluir todos los metadatos internos del entorno de ejecución.
Revisa la descripción de la solicitud de extracción que vincula directamente a la alerta de GitHub Code Scanning (SARIF) para que el encargado de mantenimiento la apruebe.
10. Soluciona problemas de casos extremos y repositorios privados
Repositorios privados sin GitHub Advanced Security (GHAS)
Los repositorios públicos de GitHub reciben una transferencia de SARIF de análisis de código de GitHub gratuita y sin límites. Sin embargo, si implementas este flujo de trabajo en un repositorio privado de Enterprise que no tiene una licencia activa de GitHub Advanced Security (GHAS), el paso upload-sarif fallará con el siguiente mensaje:
HTTP 403: Advanced Security must be enabled for this repository to use code scanning.
Resolución: Resguardo de informe HTML interactivo independiente
El generador de informes HTML integrado de CodeMender (cm report -f html) crea un panel de seguridad interactivo independiente que incluye tarjetas de métricas de gravedad, fragmentos de código con sintaxis destacada y números de línea, y un visor de diferencias de parches intercalado sin dependencias web externas.
Para admitir repositorios privados sin una licencia de GHAS, actualiza .github/workflows/codemender-scan.yml para archivar un artefacto de informe HTML en lugar de subir SARIF:
Generar el informe HTML independiente: En el paso Export Security Reports & Publish Job Summary, exporta un panel HTML junto con tu resumen de Markdown usando cm report -f html > codemender-audit-report.html.
Archiva el informe como un artefacto de flujo de trabajo: Reemplaza el paso Upload SARIF Report to GitHub Code Scanning (github/codeql-action/upload-sarif@v4) por actions/upload-artifact@v4 configurado para subir codemender-audit-report.html (por ejemplo, con el nombre de artefacto codemender-security-report).
Inspecciona de forma local en cualquier navegador: Descarga codemender-security-report.zip directamente desde la página de resumen de ejecución del flujo de trabajo de GitHub Actions, extráelo y abre codemender-audit-report.html en cualquier navegador web para realizar una clasificación visual.
Corrección autónoma de repositorios privados con evidencia de auditoría incorporada
En los repositorios corporativos privados, los equipos de ingeniería y seguridad necesitan visibilidad completa del análisis de la causa raíz, la prueba de concepto de la vulnerabilidad y el plan de solución sin necesidad de paneles de herramientas externos. Sin embargo, confirmar secuencias de comandos de exploits (exploit.sh) o archivos Markdown internos (PLAN.md, LOG.md) en la rama del repositorio contamina el historial de Git y puede activar alertas falsas de otros escáneres de seguridad.
Para solucionar este problema, implementa el flujo de trabajo de corrección de repositorios privados dedicado (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)
Cómo funciona la corrección de repositorios privados
Verificación dinámica de PoC (cm verify): Sintetiza y prueba un exploit en funcionamiento antes de generar la corrección para confirmar la explotabilidad, lo que omite automáticamente cm fix si la verificación marca un hallazgo no explotable como DISMISSED.
Embedded PR Audit Collapsibles: Extrae REPORT.md, PLAN.md y exploit.sh en /tmp/codemender-evidence/ y les da formato directamente en la descripción de la solicitud de extracción dentro de los bloques contraíbles de <details open> para que el revisor los inspeccione con un solo clic.
Archivado de artefactos: Archiva la carpeta de evidencia completa a través de actions/upload-artifact@v4.
Confirmaciones de Git impecables: Limpia todos los metadatos del entorno de ejecución y los directorios .exploit para que la confirmación de Git de la solicitud de extracción contenga estrictamente los cambios en el código de producción.
Lista de tareas para solucionar problemas de la federación de identidades para cargas de trabajo (WIF)
De forma predeterminada, google-github-actions/auth@v2 escribe un archivo de configuración de credenciales federadas local durante la configuración, y el intercambio de tokens de OAuth 2.0 real se produce cuando se inicia cm health --strict o cm find. Usa la siguiente lista de tareas para diagnosticar errores de autenticación de HTTP 400 o HTTP 403:
Síntoma del error | Causa raíz común | Verificación y corrección |
HTTP 403 ( | Falta la vinculación | Confirma que |
HTTP 400 ( | El nombre del repositorio de OIDC | Vuelve a ejecutar el paso 4 (pasos 1 y 6) y asegúrate de que |
HTTP 400 ( | Asignación de | Confirma que |
HTTP 403 transitorio inmediatamente después de la configuración | La propagación global de IAM y de la federación de identidades para cargas de trabajo puede tardar entre 1 y 5 minutos en las vinculaciones recién creadas. | Espera entre 1 y 2 minutos y haz clic en Re-run failed jobs en GitHub Actions. |
Para inspeccionar la vinculación de Workload Identity activa en tu cuenta de servicio de CI/CD en Cloud Shell, ejecuta lo siguiente:
gcloud iam service-accounts get-iam-policy "${SERVICE_ACCOUNT_EMAIL}" \
--project="${PROJECT_ID}" \
--flatten="bindings[].members" \
--filter="bindings.role=roles/iam.workloadIdentityUser"
Confirma que el resultado vincule roles/iam.workloadIdentityUser con 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
Solución de problemas de la verificación previa de CI/CD y del código de salida de la CLI
Los comandos de CodeMender (cm health --strict, cm find, cm verify y cm fix) devuelven códigos de salida deterministas para que las canalizaciones de CI/CD puedan distinguir de inmediato los hallazgos de seguridad de los errores de configuración o de servicio:
Código de salida | Categoría | Causa raíz y solución comunes |
| Listo | Se aprobaron las verificaciones de estado o se completó el análisis sin hallazgos de bloqueo. |
| Accesorios/General |
|
|
| Se produjo un error en el intercambio de tokens de OAuth/ADC de WIF ( |
|
| Sintaxis de |
|
| El ejecutor no puede comunicarse con |
|
| A la cuenta de servicio le falta |
|
| La verificación preliminar |
|
| El agente alcanzó su límite de tareas activas simultáneas. Vuelve a ejecutar el flujo de trabajo después de un breve retraso. |
Para obtener información sobre otros errores de tiempo de ejecución, como la resolución de la rama base de diferencias de Git (fetch-depth: 0), los retrasos en la propagación de recursos o los permisos de creación de solicitudes de extracción de GitHub Actions, consulta la Guía oficial para solucionar problemas de CI/CD de CodeMender.
11. Limpia los recursos
Para evitar el consumo continuo de recursos o limpiar las configuraciones de prueba en tus entornos de Google Cloud y GitHub, realiza los siguientes pasos de limpieza.
Paso 1: Quita los secretos del repositorio de GitHub e inhabilita los flujos de trabajo a través de la CLI de gh
Usa la CLI de GitHub (gh) para borrar de forma limpia los secretos de las acciones del repositorio y, luego, inhabilita los flujos de trabajo de 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
Paso 2: Inhabilita o borra los recursos de la federación de identidades para cargas de trabajo de Google Cloud
Los grupos de identidades para cargas de trabajo, los proveedores y las cuentas de servicio generan un costo de inactividad de cero cuando no se intercambian tokens. Elige el modo de limpieza que coincida con tu flujo de trabajo:
Opción A: Pausar el acceso (recomendado si planeas volver a ejecutar en este proyecto): Inhabilita el intercambio de tokens de OIDC de inmediato sin activar la retención de eliminación no definitiva de 30 días de Cloud IAM de Google Cloud ni los retrasos de propagación de la cuenta de servicio uniqueId:
gcloud iam workload-identity-pools providers update-oidc "${WORKLOAD_IDENTITY_PROVIDER}" \
--workload-identity-pool="${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--disabled \
--project="${PROJECT_ID}"
Opción B: Desglose completo: Borra el proveedor de WIF, el grupo (se conserva en estado DELETED durante 30 días) y la cuenta de servicio 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. ¡Felicitaciones!
¡Felicitaciones! Completaste el codelab Protege tu canalización de CI/CD con CodeMender.
Diseñaste, compilaste y automatizaste correctamente una canalización de DevSecOps de confianza cero de nivel de producción con la federación de identidades para cargas de trabajo de Google Cloud, CodeMender y GitHub Actions.
Temas abordados
Autenticación sin claves de confianza cero: Se eliminaron las claves JSON de cuentas de servicio riesgosas y de larga duración vinculando tokens de OIDC de GitHub efímeros a IAM de Google Cloud a través de la federación de identidades para cargas de trabajo (WIF).
Análisis de AST diferencial de PR y reducción de ruido heredada: Análisis continuo con alcance limitado a los archivos modificados y dependientes (--diff="origin/$BASE_REF"), lo que aísla la deuda técnica heredada ([LEGACY / UNTOUCHED]) para mantener los ciclos de reacción de los desarrolladores en menos de 15 segundos.
Informes multiformato y resúmenes de trabajos nativos: Se combinó OASIS SARIF v2.1.0 para el análisis de código de GitHub centralizado con Markdown nativo (cm report -f md >> $GITHUB_STEP_SUMMARY) para obtener visibilidad ejecutiva instantánea directamente en las páginas de ejecución del flujo de trabajo de CI.
Corrección autónoma con revisión con intervención humana: Se pasó de las notificaciones de alertas pasivas a las canalizaciones de corrección activas que sintetizan de forma autónoma los parches de código propuestos, verifican con paquetes de pruebas de regresión y abren solicitudes de extracción de revisión con artefactos de auditoría para que los ingenieros los aprueben.
Control de calidad automatizado: Se aplicó una protección estricta de las ramas y un control de fusión (--fail-on) para evitar que las vulnerabilidades peligrosas lleguen a la producción.
Transferencia de estado basada en artefactos y aislamiento del espacio de trabajo: Se transfirieron los hallazgos sin problemas entre los trabajos de CI con cm report import, mientras se usaba .git/info/exclude para preservar el historial de Git original y evitar la filtración de credenciales.
Cambio de mentalidad de los desarrolladores
Práctica tradicional de DevSecOps | Canalización de CI/CD autónoma de CodeMender |
Volcado pasivo de alertas: Los escáneres imprimen registros de terminal sin procesar o listas de errores estáticas, lo que traslada la carga de la clasificación por completo a los desarrolladores. | Desarrollador conjunto activo: Sintetiza parches de código verificados y abre solicitudes de extracción listas para combinar para que las apruebe el ingeniero. |
Altos niveles de falsos positivos: Las heurísticas de AST estáticas marcan miles de vulnerabilidades teóricas sin pruebas de que se puedan explotar. | Verificación de exploits de 2 niveles: La generación de pruebas dinámicas en la zona de pruebas ( |
Almacenamiento de secretos riesgoso: Las claves JSON de cuentas de servicio de larga duración almacenadas en secretos de CI corren el riesgo de filtraciones accidentales y proliferación de credenciales. | WIF de confianza cero: Autenticación sin claves a través de tokens de OIDC efímeros intercambiados con el STS de Google Cloud on demand. |
Análisis monolíticos: Cada confirmación activa auditorías de todo el repositorio, lo que retrasa los flujos de trabajo de CI y desperdicia tokens costosos. | Enrutamiento de AST adaptado a eventos: Las solicitudes de extracción ejecutan análisis de AST diferenciales de 15 segundos ( |
Historial de repositorios contaminado: Secuencias de comandos de exploits temporales y registros de ataques confirmados directamente en las ramas del repositorio. | Higiene del espacio de trabajo empresarial: La evidencia de los ataques se incorpora de forma limpia en las descripciones de las solicitudes de extracción y los artefactos de flujo de trabajo, lo que mantiene puros los commits de código. |
Próximos pasos
🚀 Continúa el recorrido de aprendizaje de CodeMender:
Parte 1: Protege tu aplicación con CodeMender: Domina el descubrimiento autónomo de vulnerabilidades en repositorios, la verificación de exploits de PoC y la síntesis de parches locales.
Shift Left Locally & Serverless Cloud Native CI/CD: Explora las implementaciones de referencia de la guía oficial de CI/CD para Google Cloud Build (cloudbuild.yaml) y Local Git Pre-commit Hooks (cm find . --diff --staged).
📖 Explora la documentación y los recursos:
Guía oficial de integración de CI/CD de CodeMender de Google Cloud
Documentación oficial de Google Cloud CodeMender
Repositorio de plantillas de inicio de GitHub Actions de CodeMender
Documentación de la federación de identidades para cargas de trabajo de Google Cloud
💡 Aplica los cambios a tus propios repositorios:
Crea una bifurcación del flujo de trabajo inicial y protege los repositorios de Python, Go, Java, Rust y Node.js de tu organización con CodeMender.