Comprender c\u00f3mo se atacan los pipelines CI\/CD es solo la mitad del panorama. El modelado de amenazas y la taxonom\u00eda de ataques nos proporcionan un mapa del campo de batalla, pero sin patrones defensivos concretos y mitigaciones de ingenier\u00eda, ese conocimiento permanece te\u00f3rico. Esta gu\u00eda cierra la brecha entre la concienciaci\u00f3n y la acci\u00f3n.<\/p>\n
El objetivo no es construir una fortaleza impenetrable \u2014 eso no existe. En cambio, nos enfocamos en reducir la superficie de ataque, limitar el radio de explosi\u00f3n cuando algo sale mal y hacer que los pipelines sean lo suficientemente resilientes como para recuperarse r\u00e1pidamente. Cada control descrito aqu\u00ed se relaciona con patrones de ataque del mundo real: pipelines envenenados, robo de credenciales, secuestro de dependencias y manipulaci\u00f3n de artefactos.<\/p>\n
Recorreremos las defensas capa por capa \u2014 desde el c\u00f3digo fuente hasta el runtime \u2014 y luego cubriremos las capacidades de detecci\u00f3n y respuesta a incidentes que cierran el ciclo. Ya sea que est\u00e9s asegurando GitHub Actions, GitLab CI, Jenkins o cualquier otra plataforma CI\/CD, los principios siguen siendo los mismos.<\/p>\n
Ning\u00fan control de seguridad individual es suficiente para proteger un pipeline CI\/CD. Los atacantes son creativos y encontrar\u00e1n la brecha en cualquier defensa de una sola capa. La \u00fanica estrategia viable es la defensa en profundidad: controles superpuestos en cada etapa del ciclo de vida de entrega de software.<\/p>\n
Los OWASP Top 10 CI\/CD Security Risks<\/a> proporcionan un marco estructurado para comprender qu\u00e9 puede salir mal. Cada riesgo \u2014 desde CICD-SEC-1 (Insufficient Flow Control Mechanisms) hasta CICD-SEC-10 (Insufficient Logging and Visibility) \u2014 requiere mitigaciones espec\u00edficas. Las defensas en esta gu\u00eda est\u00e1n organizadas para abordar estos riesgos de manera sistem\u00e1tica.<\/p>\n Piensa en el pipeline CI\/CD como una cadena de l\u00edmites de confianza:<\/p>\n Cada capa tiene amenazas distintas y requiere defensas distintas. El compromiso en una capa no deber\u00eda propagarse autom\u00e1ticamente a la siguiente.<\/p>\n La capa de fuente es donde comienzan la mayor\u00eda de los ataques a CI\/CD. Un atacante que puede modificar c\u00f3digo, definiciones de pipelines o archivos de configuraci\u00f3n controla lo que ejecuta el pipeline. Las defensas de la capa de fuente aseguran que solo los cambios autorizados, revisados y verificados ingresen al pipeline.<\/p>\n La protecci\u00f3n de ramas es la primera l\u00ednea de defensa. Como m\u00ednimo, las ramas main y de release deben aplicar:<\/p>\n No todos los archivos en un repositorio conllevan el mismo riesgo. Las definiciones de pipelines, las plantillas de infrastructure-as-code y las configuraciones de contenedores son objetivos de alto valor. Usa CODEOWNERS para requerir revisi\u00f3n de equipos espec\u00edficos para rutas sensibles:<\/p>\n La firma de commits proporciona prueba criptogr\u00e1fica de autor\u00eda. Sin ella, un atacante que comprometa el token de acceso de un desarrollador puede enviar commits que parecen provenir de cualquier persona. Habilita la verificaci\u00f3n de firma de commits en ramas protegidas para asegurar que cada commit est\u00e9 firmado con una clave GPG o SSH verificada.<\/p>\n La revisi\u00f3n de c\u00f3digo es un control humano, y necesita barandillas:<\/p>\n No todos los eventos deben activar una ejecuci\u00f3n completa del pipeline, especialmente una que tenga acceso a secretos:<\/p>\n La capa de build es donde el c\u00f3digo se convierte en ejecutable. Un compromiso aqu\u00ed significa que un atacante puede inyectar l\u00f3gica maliciosa en tus artefactos sin modificar el c\u00f3digo fuente. Las defensas de la capa de build se centran en el aislamiento, la efimeralidad y el privilegio m\u00ednimo.<\/p>\n Los runners CI persistentes acumulan estado: credenciales en cach\u00e9, archivos sobrantes de builds anteriores, variables de entorno que se filtran entre jobs. Los runners ef\u00edmeros eliminan esta clase de riesgo por completo al aprovisionar una VM o contenedor nuevo para cada job y destruirlo inmediatamente despu\u00e9s.<\/p>\n Incluso con runners ef\u00edmeros, los builds que comparten cach\u00e9s o namespaces de red pueden filtrar informaci\u00f3n entre jobs. Asegura:<\/p>\n Un paso de build comprometido con acceso de red sin restricciones puede exfiltrar secretos a infraestructura controlada por el atacante. Restringe el acceso de red saliente:<\/p>\n Cada herramienta instalada en una imagen de build es una superficie de ataque potencial. Reduce las im\u00e1genes de build al m\u00ednimo necesario:<\/p>\n El logging de debug y la salida detallada son invaluables durante el desarrollo pero peligrosos en pipelines de producci\u00f3n. Pueden filtrar secretos, rutas internas y detalles de infraestructura. Aseg\u00farate de que Las credenciales son el objetivo m\u00e1s valioso en cualquier pipeline CI\/CD. Un atacante que obtenga una clave de acceso a la nube, un token de despliegue o un secreto de API puede pivotar mucho m\u00e1s all\u00e1 del pipeline en s\u00ed. Las defensas de credenciales se centran en minimizar lo que existe, lo que se puede acceder y por cu\u00e1nto tiempo.<\/p>\n El Los secretos de larga duraci\u00f3n almacenados en sistemas CI\/CD son bombas de tiempo. Reempl\u00e1zalos con federaci\u00f3n de identidad de carga de trabajo basada en OIDC siempre que sea posible:<\/p>\n Con OIDC, la plataforma CI\/CD emite un JWT de corta duraci\u00f3n, y el proveedor de nube lo intercambia por credenciales temporales. No se almacenan secretos est\u00e1ticos en ning\u00fan lugar.<\/p>\n Un \u00fanico conjunto de credenciales compartido entre todos los entornos es un radio de explosi\u00f3n catastr\u00f3fico. Segmenta las credenciales:<\/p>\n Los pull requests desde forks nunca deben tener acceso a los secretos del repositorio. Esta es una mala configuraci\u00f3n com\u00fan que permite a los atacantes exfiltrar secretos enviando un PR malicioso. En GitHub Actions, usa Para credenciales que no pueden usar OIDC (contrase\u00f1as de bases de datos, claves API para servicios de terceros), usa un gestor de secretos como HashiCorp Vault con secretos din\u00e1micos y de corta duraci\u00f3n:<\/p>\n Los secretos din\u00e1micos se generan bajo demanda, est\u00e1n delimitados a la identidad solicitante y se revocan autom\u00e1ticamente cuando expiran. Incluso si se filtran, la ventana de exposici\u00f3n se mide en minutos, no en meses.<\/p>\n Cada recuperaci\u00f3n de secreto debe generar una entrada en el registro de auditor\u00eda. Si tu gestor de secretos no registra los accesos, no tienes forma de investigar un compromiso. Aseg\u00farate de que los registros capturen: qui\u00e9n accedi\u00f3 a qu\u00e9, cu\u00e1ndo, desde qu\u00e9 ejecuci\u00f3n de pipeline y desde qu\u00e9 direcci\u00f3n IP.<\/p>\n Los artefactos de build \u2014 im\u00e1genes de contenedores, binarios, paquetes \u2014 son el puente entre tu pipeline y producci\u00f3n. Si un atacante puede manipular los artefactos despu\u00e9s de construidos, todas las defensas anteriores se vuelven irrelevantes. Las defensas de la capa de artefactos aseguran integridad, procedencia e inmutabilidad.<\/p>\n La firma de artefactos proporciona prueba criptogr\u00e1fica de que un artefacto fue producido por tu pipeline y no ha sido modificado desde entonces. Cosign de Sigstore hace pr\u00e1ctica la firma sin claves:<\/p>\n Con la firma sin claves, la clave de firma es ef\u00edmera y est\u00e1 vinculada a la identidad OIDC del workflow CI\/CD. No hay una clave de firma de larga duraci\u00f3n que robar.<\/p>\n SLSA (Supply-chain Levels for Software Artifacts) provenance registra c\u00f3mo, d\u00f3nde y por qui\u00e9n se construy\u00f3 un artefacto. En SLSA Level 3, la provenance es generada por la propia plataforma de build y no puede ser falsificada por el proceso de build:<\/p>\n Los artefactos publicados nunca deben sobrescribirse. Si un atacante puede reemplazar una versi\u00f3n publicada, puede inyectar c\u00f3digo malicioso en cada despliegue que haga referencia a esa versi\u00f3n. Configura tus registros para inmutabilidad:<\/p>\n Un Software Bill of Materials (SBOM) lista cada componente en tu artefacto. Generar un SBOM en tiempo de build y atestiguarlo junto al artefacto crea un inventario verificable para la gesti\u00f3n de vulnerabilidades:<\/p>\n Firmar artefactos solo es \u00fatil si verificas las firmas antes del despliegue. Usa admission controllers de Kubernetes para aplicar esto autom\u00e1ticamente:<\/p>\n Con esta pol\u00edtica en vigor, cualquier imagen de contenedor que carezca de una firma Cosign v\u00e1lida de tus workflows de GitHub Actions ser\u00e1 rechazada en el momento de admisi\u00f3n \u2014 antes de que se ejecute en tu cl\u00faster.<\/p>\n La capa de despliegue es la \u00faltima puerta antes de que los cambios lleguen a producci\u00f3n. Las defensas aqu\u00ed aseguran que solo los artefactos verificados y aprobados sean desplegados, y que el proceso de despliegue en s\u00ed sea controlado y auditable.<\/p>\n Para despliegues en producci\u00f3n, los pipelines automatizados deben pausarse y requerir aprobaci\u00f3n humana expl\u00edcita. Esto proporciona un punto de verificaci\u00f3n final donde un humano puede confirmar que el cambio es esperado, probado y autorizado.<\/p>\n En la configuraci\u00f3n del repositorio de GitHub, configura el entorno \u00abproduction\u00bb para requerir aprobaci\u00f3n de revisores designados antes de que el job proceda.<\/p>\n Los pipelines CI\/CD tradicionales hacen push a producci\u00f3n: el pipeline tiene credenciales para modificar la infraestructura de producci\u00f3n. Esto es una gran superficie de ataque. GitOps con despliegue pull-based invierte el modelo:<\/p>\n Incluso con todas las defensas anteriores, un despliegue puede introducir problemas. Los despliegues canary limitan la exposici\u00f3n al desplegar cambios a un peque\u00f1o porcentaje del tr\u00e1fico primero. Si las m\u00e9tricas se degradan, el rollback automatizado revierte el cambio antes de que afecte a todos los usuarios.<\/p>\n Durante incidentes activos, ventanas de mantenimiento o per\u00edodos de alto tr\u00e1fico, los despliegues deben congelarse. Implementa pol\u00edticas de congelaci\u00f3n de despliegues que prevengan despliegues iniciados por pipelines durante ventanas especificadas, y asegura que solo los comandantes de incidentes designados puedan anular la congelaci\u00f3n.<\/p>\n La prevenci\u00f3n eventualmente fallar\u00e1. Las capacidades de detecci\u00f3n determinan si detectas un compromiso en minutos o en meses. El monitoreo de CI\/CD es un punto ciego para muchas organizaciones \u2014 su SIEM ingiere logs de aplicaciones e infraestructura pero ignora completamente la telemetr\u00eda del pipeline.<\/p>\n Establece l\u00edneas base para el comportamiento normal del pipeline y genera alertas sobre desviaciones:<\/p>\n Las nuevas dependencias a\u00f1adidas en PRs deben activar revisi\u00f3n automatizada y alertas. Una herramienta de diff de dependencias puede:<\/p>\n Los secretos se filtran a trav\u00e9s de commits, logs y artefactos. Combina m\u00faltiples enfoques de escaneo:<\/p>\n Las definiciones de pipelines deben cambiar a trav\u00e9s del proceso normal de PR. Monitorea cambios inesperados:<\/p>\n Reenv\u00eda los logs de auditor\u00eda de CI\/CD a tu SIEM junto con los logs de aplicaciones e infraestructura. Las fuentes de logs clave incluyen:<\/p>\n Correlaciona la actividad del pipeline con cambios en la infraestructura de nube. Si una ejecuci\u00f3n de pipeline coincide con modificaciones inesperadas de pol\u00edticas IAM o creaci\u00f3n de recursos, esa es una alerta de alta prioridad.<\/p>\n Cuando se detecta \u2014 o se sospecha \u2014 un compromiso de CI\/CD, la velocidad importa. El atacante puede a\u00fan tener acceso activo, y cada minuto de retraso ampl\u00eda el radio de explosi\u00f3n. Un playbook de respuesta a incidentes preparado para escenarios espec\u00edficos de CI\/CD es esencial.<\/p>\n Determina a qu\u00e9 pudo haber accedido el atacante:<\/p>\n Verifica si los artefactos publicados fueron manipulados:<\/p>\n Recopila evidencia de m\u00faltiples fuentes:<\/p>\n Despu\u00e9s de la contenci\u00f3n e investigaci\u00f3n, restaura las operaciones seguras:<\/p>\n La seguridad de CI\/CD no es una lista de verificaci\u00f3n que completas una vez y olvidas. Es una pr\u00e1ctica de ingenier\u00eda continua que evoluciona con tus pipelines, tu infraestructura y el panorama de amenazas. Los atacantes seguir\u00e1n apuntando a la cadena de suministro de software porque ofrece alto apalancamiento \u2014 un solo pipeline comprometido puede afectar cada despliegue, cada entorno y cada cliente.<\/p>\n Las defensas en esta gu\u00eda est\u00e1n organizadas por capa, pero los puntos de inicio de mayor impacto cruzan todas las capas:<\/p>\n Comienza con estos controles de alto impacto. A\u00f1ade defensas adicionales a medida que tu programa de seguridad madure. Y siempre asume que tu pipeline ser\u00e1 un objetivo \u2014 porque lo ser\u00e1.<\/p>\n En el pr\u00f3ximo art\u00edculo de esta serie, recorreremos la implementaci\u00f3n de estas defensas en un pipeline real de GitHub Actions, con un ejemplo funcional completo que puedes adaptar para tus propios repositorios.<\/p>\n","protected":false},"excerpt":{"rendered":" Introducci\u00f3n Comprender c\u00f3mo se atacan los pipelines CI\/CD es solo la mitad del panorama. El modelado de amenazas y la taxonom\u00eda de ataques nos proporcionan un mapa del campo de batalla, pero sin patrones defensivos concretos y mitigaciones de ingenier\u00eda, ese conocimiento permanece te\u00f3rico. Esta gu\u00eda cierra la brecha entre la concienciaci\u00f3n y la acci\u00f3n. … Leer m\u00e1s<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[55,60],"tags":[],"post_folder":[],"class_list":["post-647","post","type-post","status-publish","format-standard","hentry","category-ci-cd-security","category-threats-attacks"],"_links":{"self":[{"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts\/647","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/comments?post=647"}],"version-history":[{"count":1,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts\/647\/revisions"}],"predecessor-version":[{"id":659,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts\/647\/revisions\/659"}],"wp:attachment":[{"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/media?parent=647"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/categories?post=647"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/tags?post=647"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/post_folder?post=647"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Los Tres Pilares: Prevenci\u00f3n, Detecci\u00f3n, Respuesta<\/h3>\n
\n
Defensa en Cada Capa<\/h3>\n
\n
Defensas de la Capa de Fuente \u2014 Protecci\u00f3n de las Entradas del Pipeline<\/h2>\n
Reglas de Protecci\u00f3n de Ramas<\/h3>\n
\n
CODEOWNERS para Rutas Sensibles<\/h3>\n
# .github\/CODEOWNERS\n\n# Pipeline definitions require security team review\n.github\/workflows\/ @org\/security-team\n.gitlab-ci.yml @org\/security-team\nJenkinsfile @org\/security-team\n\n# Infrastructure as code\nterraform\/ @org\/platform-team @org\/security-team\npulumi\/ @org\/platform-team @org\/security-team\n\n# Container definitions\nDockerfile* @org\/security-team\ndocker-compose*.yml @org\/security-team\n\n# Dependency manifests\npackage.json @org\/security-team\nrequirements.txt @org\/security-team\ngo.sum @org\/security-team<\/code><\/pre>\nCommits Firmados y Verificaci\u00f3n<\/h3>\n
# Configure Git to sign commits with SSH key\ngit config --global gpg.format ssh\ngit config --global user.signingkey ~\/.ssh\/id_ed25519.pub\ngit config --global commit.gpgsign true\n\n# Verify a commit signature\ngit verify-commit HEAD<\/code><\/pre>\nPol\u00edticas de Revisi\u00f3n de PR<\/h3>\n
\n
Limitaci\u00f3n de Triggers del Pipeline<\/h3>\n
\n
Defensas de la Capa de Build \u2014 Asegurando el Proceso de Build<\/h2>\n
Runners Ef\u00edmeros<\/h3>\n
# GitHub Actions: Self-hosted ephemeral runner with actions-runner-controller\napiVersion: actions.summerwind.dev\/v1alpha1\nkind: RunnerDeployment\nmetadata:\n name: ephemeral-runners\nspec:\n replicas: 5\n template:\n spec:\n ephemeral: true\n repository: your-org\/your-repo\n labels:\n - self-hosted\n - ephemeral\n - linux\n dockerdWithinRunnerContainer: false\n image: ghcr.io\/actions\/actions-runner:latest\n resources:\n limits:\n cpu: \"2\"\n memory: \"4Gi\"<\/code><\/pre>\nEntornos de Build Aislados<\/h3>\n
\n
Restricciones de Red Durante los Builds<\/h3>\n
\n
# Kubernetes NetworkPolicy for CI runner pods\napiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n name: ci-runner-egress-restricted\n namespace: ci-runners\nspec:\n podSelector:\n matchLabels:\n role: ci-runner\n policyTypes:\n - Egress\n egress:\n - to:\n - ipBlock:\n cidr: 10.0.0.0\/8 # Internal network only\n ports:\n - protocol: TCP\n port: 443 # HTTPS to internal registries\n - protocol: TCP\n port: 53 # DNS\n - protocol: UDP\n port: 53 # DNS<\/code><\/pre>\nIm\u00e1genes de Build M\u00ednimas<\/h3>\n
\n
# Pin by digest, not by tag\nFROM golang:1.22@sha256:a3b21c5d8e... AS builder\nWORKDIR \/app\nCOPY . .\nRUN CGO_ENABLED=0 go build -o \/app\/binary\n\n# Use distroless for the final image\nFROM gcr.io\/distroless\/static-debian12@sha256:f4e8b1c2d9...\nCOPY --from=builder \/app\/binary \/binary\nENTRYPOINT [\"\/binary\"]<\/code><\/pre>\nDesactivar Modos de Debug en Pipelines de Producci\u00f3n<\/h3>\n
ACTIONS_STEP_DEBUG<\/code>, CI_DEBUG_TRACE<\/code> y flags equivalentes est\u00e9n desactivados en las configuraciones de pipelines de producci\u00f3n.<\/p>\nDefensas de Credenciales e Identidad \u2014 Limitando lo que los Pipelines Pueden Acceder<\/h2>\n
Permisos M\u00ednimos de Tokens<\/h3>\n
GITHUB_TOKEN<\/code> predeterminado en GitHub Actions tiene permisos amplios. Siempre restr\u00edngelo al m\u00ednimo requerido:<\/p>\n# GitHub Actions: Restrict default token permissions\npermissions:\n contents: read\n packages: read\n id-token: write # Only if using OIDC\n\njobs:\n build:\n runs-on: ubuntu-latest\n permissions:\n contents: read\n steps:\n - uses: actions\/checkout@v4\n - run: make build\n\n deploy:\n runs-on: ubuntu-latest\n needs: build\n permissions:\n contents: read\n id-token: write # For OIDC authentication\n steps:\n - name: Authenticate to cloud\n uses: aws-actions\/configure-aws-credentials@v4\n with:\n role-to-assume: arn:aws:iam::123456789012:role\/deploy-role\n aws-region: us-east-1<\/code><\/pre>\nOIDC y Workload Identity<\/h3>\n
\n
aws-actions\/configure-aws-credentials<\/code> con asunci\u00f3n de rol OIDC.<\/li>\ngoogle-github-actions\/auth<\/code> con Workload Identity Federation.<\/li>\nazure\/login<\/code> con credenciales federadas.<\/li>\nCI_JOB_JWT_V2<\/code>) con federaci\u00f3n del proveedor de nube.<\/li>\n<\/ul>\nCredenciales por Entorno y por Etapa<\/h3>\n
\n
Sin Secretos en Workflows de PR\/Fork<\/h3>\n
pull_request<\/code> (no pull_request_target<\/code>) para c\u00f3digo no confiable, y nunca pases secretos a pasos que ejecuten c\u00f3digo del PR.<\/p>\nIntegraci\u00f3n con Vault y Secretos Din\u00e1micos<\/h3>\n
# HashiCorp Vault: Generate short-lived database credentials\nvault read database\/creds\/ci-readonly\n# Returns:\n# Key Value\n# --- -----\n# lease_id database\/creds\/ci-readonly\/abc123\n# lease_duration 1h\n# username v-ci-readonly-xyz789\n# password A1B2-C3D4-E5F6-G7H8<\/code><\/pre>\nAuditor\u00eda de Todos los Accesos a Secretos<\/h3>\n
Defensas de la Capa de Artefactos \u2014 Asegurando la Integridad de las Salidas<\/h2>\n
Firma de Todos los Artefactos con Sigstore\/Cosign<\/h3>\n
# Sign a container image using Cosign (keyless, OIDC-based)\ncosign sign --yes ghcr.io\/your-org\/your-app:v1.2.3@sha256:abc123...\n\n# Verify the signature\ncosign verify \\\n --certificate-identity=https:\/\/github.com\/your-org\/your-app\/.github\/workflows\/build.yml@refs\/heads\/main \\\n --certificate-oidc-issuer=https:\/\/token.actions.githubusercontent.com \\\n ghcr.io\/your-org\/your-app:v1.2.3@sha256:abc123...<\/code><\/pre>\nGeneraci\u00f3n y Almacenamiento de Provenance SLSA<\/h3>\n
# GitHub Actions: Generate SLSA provenance for container images\n- uses: slsa-framework\/slsa-github-generator\/.github\/workflows\/generator_container_slsa3.yml@v2.0.0\n with:\n image: ghcr.io\/your-org\/your-app\n digest: ${{ steps.build.outputs.digest }}\n secrets:\n registry-username: ${{ github.actor }}\n registry-password: ${{ secrets.GITHUB_TOKEN }}<\/code><\/pre>\nAlmacenamiento Inmutable de Artefactos<\/h3>\n
\n
Generaci\u00f3n de SBOM y Attestation<\/h3>\n
# Generate SBOM with Syft and attest with Cosign\nsyft ghcr.io\/your-org\/your-app:v1.2.3 -o spdx-json > sbom.spdx.json\ncosign attest --predicate sbom.spdx.json --type spdxjson \\\n ghcr.io\/your-org\/your-app:v1.2.3@sha256:abc123...<\/code><\/pre>\nAdmission Controllers para Verificaci\u00f3n de Firmas<\/h3>\n
# Kyverno: Require signed images\napiVersion: kyverno.io\/v1\nkind: ClusterPolicy\nmetadata:\n name: require-signed-images\nspec:\n validationFailureAction: Enforce\n background: false\n rules:\n - name: verify-cosign-signature\n match:\n any:\n - resources:\n kinds:\n - Pod\n verifyImages:\n - imageReferences:\n - \"ghcr.io\/your-org\/*\"\n attestors:\n - entries:\n - keyless:\n issuer: \"https:\/\/token.actions.githubusercontent.com\"\n subject: \"https:\/\/github.com\/your-org\/*\"<\/code><\/pre>\nDefensas de la Capa de Despliegue \u2014 Controlando lo que Llega a Producci\u00f3n<\/h2>\n
Aprobaciones Manuales Obligatorias<\/h3>\n
# GitHub Actions: Environment with required reviewers\njobs:\n deploy-production:\n runs-on: ubuntu-latest\n environment:\n name: production\n url: https:\/\/your-app.example.com\n steps:\n - name: Deploy to production\n run: .\/deploy.sh production<\/code><\/pre>\nGitOps con Despliegue Pull-Based<\/h3>\n
\n
# Flux: GitRepository and Kustomization for pull-based deployment\napiVersion: source.toolkit.fluxcd.io\/v1\nkind: GitRepository\nmetadata:\n name: app-manifests\n namespace: flux-system\nspec:\n interval: 1m\n url: https:\/\/github.com\/your-org\/app-manifests\n ref:\n branch: main\n secretRef:\n name: git-credentials\n---\napiVersion: kustomize.toolkit.fluxcd.io\/v1\nkind: Kustomization\nmetadata:\n name: app-production\n namespace: flux-system\nspec:\n interval: 5m\n path: .\/environments\/production\n prune: true\n sourceRef:\n kind: GitRepository\n name: app-manifests\n healthChecks:\n - apiVersion: apps\/v1\n kind: Deployment\n name: your-app\n namespace: production<\/code><\/pre>\nDespliegues Canary y Rollback Automatizado<\/h3>\n
\n
Congelaci\u00f3n de Despliegues<\/h3>\n
Detecci\u00f3n y Monitoreo \u2014 Saber Cu\u00e1ndo Algo Est\u00e1 Mal<\/h2>\n
Detecci\u00f3n de Anomal\u00edas en la Ejecuci\u00f3n del Pipeline<\/h3>\n
\n
Alertas de Diff de Dependencias<\/h3>\n
\n
Escaneo de Secretos<\/h3>\n
\n
gitleaks<\/code> o trufflehog<\/code> capturan secretos antes de que entren al repositorio.<\/li>\n# Pre-commit hook with gitleaks\n# .pre-commit-config.yaml\nrepos:\n - repo: https:\/\/github.com\/gitleaks\/gitleaks\n rev: v8.18.0\n hooks:\n - id: gitleaks<\/code><\/pre>\nMonitoreo de Deriva de Configuraci\u00f3n<\/h3>\n
\n
Integraci\u00f3n SIEM para Logs de Auditor\u00eda de CI\/CD<\/h3>\n
\n
Respuesta a Incidentes para CI\/CD \u2014 Cuando las Defensas Fallan<\/h2>\n
Acciones Inmediatas: Contener el Compromiso<\/h3>\n
\n
An\u00e1lisis del Radio de Explosi\u00f3n<\/h3>\n
\n
Verificaci\u00f3n de Integridad de Artefactos<\/h3>\n
\n
Investigaci\u00f3n Forense<\/h3>\n
\n
Recuperaci\u00f3n Post-Incidente<\/h3>\n
\n
Plantilla de Playbook de Respuesta a Incidentes CI\/CD<\/h3>\n
## CI\/CD Security Incident Playbook\n\n### Phase 1: Detection & Triage (0-15 minutes)\n- [ ] Confirm the alert is a true positive\n- [ ] Classify severity (P1: active compromise, P2: suspected compromise, P3: policy violation)\n- [ ] Notify the incident commander and security team\n\n### Phase 2: Containment (15-60 minutes)\n- [ ] Revoke compromised credentials\n- [ ] Disable affected pipelines\n- [ ] Isolate affected runners\n- [ ] Block attacker's access (revoke tokens, disable accounts)\n\n### Phase 3: Investigation (1-24 hours)\n- [ ] Collect runner logs, audit logs, git history\n- [ ] Determine blast radius (credentials, artifacts, deployments)\n- [ ] Identify attack vector (how did the attacker get in?)\n- [ ] Check artifact integrity for the compromised period\n\n### Phase 4: Recovery (24-72 hours)\n- [ ] Rotate all potentially compromised secrets\n- [ ] Rebuild and republish affected artifacts from known-good source\n- [ ] Redeploy affected environments from verified artifacts\n- [ ] Restore pipeline operations with tightened controls\n\n### Phase 5: Post-Incident (1-2 weeks)\n- [ ] Conduct blameless post-mortem\n- [ ] Document lessons learned and update this playbook\n- [ ] Implement systemic improvements to prevent recurrence\n- [ ] Update detection rules based on IOCs discovered<\/code><\/pre>\nConclusi\u00f3n<\/h2>\n
\n