{"id":599,"date":"2026-03-24T08:53:53","date_gmt":"2026-03-24T07:53:53","guid":{"rendered":"https:\/\/secure-pipelines.com\/?p=599"},"modified":"2026-07-08T22:43:01","modified_gmt":"2026-07-08T21:43:01","slug":"ci-cd-threats-attacks-what-attackers-target-how-to-defend-2","status":"publish","type":"post","link":"https:\/\/secure-pipelines.com\/es\/ci-cd-security\/ci-cd-threats-attacks-what-attackers-target-how-to-defend-2\/","title":{"rendered":"Amenazas y Ataques CI\/CD: Qu\u00e9 Atacan los Adversarios y C\u00f3mo Defenderse"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">La entrega de software moderna se apoya en pipelines de integraci\u00f3n continua y entrega continua (CI\/CD) para construir, probar y desplegar c\u00f3digo a gran escala. Estos pipelines se han convertido en la columna vertebral de DevOps, permitiendo a las organizaciones distribuir funcionalidades m\u00e1s r\u00e1pido y de forma m\u00e1s fiable que nunca. Pero este poder conlleva un compromiso cr\u00edtico: los sistemas CI\/CD se han convertido en una de las superficies de ataque m\u00e1s atractivas de los entornos empresariales.<\/p>\n\n<p class=\"wp-block-paragraph\">A diferencia de la infraestructura tradicional, los pipelines CI\/CD se sit\u00faan en la intersecci\u00f3n del c\u00f3digo, las credenciales y los sistemas de producci\u00f3n. Un \u00fanico pipeline comprometido puede dar a un atacante todo lo que necesita: acceso a los repositorios de c\u00f3digo fuente, credenciales de la nube, claves de firma y la capacidad de publicar artefactos maliciosos directamente en producci\u00f3n. Esto no es una preocupaci\u00f3n te\u00f3rica. Los \u00faltimos cinco a\u00f1os han visto una escalada dr\u00e1stica de los ataques que apuntan a las cadenas de suministro de software a trav\u00e9s de la infraestructura CI\/CD, desde <strong>SolarWinds<\/strong> hasta <strong>XZ Utils<\/strong>.<\/p>\n\n<p class=\"wp-block-paragraph\">Esta gu\u00eda ofrece una taxonom\u00eda completa de las amenazas y ataques a CI\/CD, los relaciona con marcos del sector como el OWASP CI\/CD Top 10, repasa incidentes reales y esboza estrategias defensivas que puedes implementar hoy mismo. Tanto si eres un ingeniero de seguridad, un profesional de DevOps o el responsable de un equipo de plataforma, comprender estos vectores de ataque es el primer paso para construir pipelines resilientes.<\/p>\n\n<h2 class=\"wp-block-heading\">Por qu\u00e9 los atacantes apuntan a los pipelines CI\/CD<\/h2>\n\n<p class=\"wp-block-paragraph\">Para comprender el panorama de amenazas, necesitas pensar en los pipelines CI\/CD como lo hace un atacante. Los pipelines no son solo automatizaci\u00f3n: son <strong>entornos de ejecuci\u00f3n privilegiados<\/strong> con propiedades \u00fanicas que los convierten en objetivos extraordinariamente valiosos.<\/p>\n\n<h3 class=\"wp-block-heading\">Acceso privilegiado a todo<\/h3>\n\n<p class=\"wp-block-paragraph\">Los pipelines CI\/CD poseen habitualmente credenciales de proveedores de nube (AWS, GCP, Azure), container registries, repositorios de paquetes, bases de datos y cl\u00fasteres de Kubernetes de producci\u00f3n. Un solo runner de pipeline suele tener m\u00e1s acceso que cualquier desarrollador individual. Los atacantes que comprometen un pipeline heredan al instante todos estos privilegios.<\/p>\n\n<h3 class=\"wp-block-heading\">La automatizaci\u00f3n como arma<\/h3>\n\n<p class=\"wp-block-paragraph\">Los pipelines est\u00e1n dise\u00f1ados para ejecutar c\u00f3digo autom\u00e1ticamente en respuesta a triggers: un push a una rama, un pull request, un tag o un cron programado. Esta automatizaci\u00f3n, que es la raz\u00f3n de ser de CI\/CD, se convierte en un arma cuando un atacante puede influir en lo que se ejecuta. A diferencia de un revisor humano, un pipeline ejecutar\u00e1 fielmente cualquier instrucci\u00f3n que se le d\u00e9, incluidas las maliciosas.<\/p>\n\n<h3 class=\"wp-block-heading\">Suposiciones de confianza impl\u00edcita<\/h3>\n\n<p class=\"wp-block-paragraph\">La mayor\u00eda de las arquitecturas CI\/CD se construyen sobre una base de confianza impl\u00edcita. Las organizaciones conf\u00edan en que los archivos de configuraci\u00f3n del pipeline no han sido manipulados. Conf\u00edan en que las dependencias resueltas durante el build son leg\u00edtimas. Conf\u00edan en que las GitHub Actions de terceros o las plantillas de pipeline compartidas son seguras. Cada una de estas suposiciones de confianza representa un posible vector de ataque.<\/p>\n\n<h3 class=\"wp-block-heading\">Postura de seguridad d\u00e9bil<\/h3>\n\n<p class=\"wp-block-paragraph\">Los sistemas CI\/CD suelen existir en un punto ciego de seguridad. Los gestionan equipos de ingenier\u00eda en lugar de equipos de seguridad, carecen de la monitorizaci\u00f3n y el logging que reciben los sistemas de producci\u00f3n y acumulan deuda t\u00e9cnica en forma de configuraciones demasiado permisivas, credenciales obsoletas y runners sin parchear. Esto los convierte en objetivos f\u00e1ciles en comparaci\u00f3n con la infraestructura de producci\u00f3n fortalecida.<\/p>\n\n<h3 class=\"wp-block-heading\">Amplificaci\u00f3n por la cadena de suministro<\/h3>\n\n<p class=\"wp-block-paragraph\">Quiz\u00e1 el aspecto m\u00e1s peligroso de los ataques a CI\/CD sea su potencial de amplificaci\u00f3n. Comprometer un \u00fanico pipeline que construye una biblioteca o servicio de uso extendido puede propagar c\u00f3digo malicioso a miles o millones de consumidores downstream. Este efecto de amplificaci\u00f3n en la cadena de suministro es lo que hace que incidentes como SolarWinds y XZ Utils sean tan devastadores.<\/p>\n\n<h2 class=\"wp-block-heading\">Taxonom\u00eda de ataques CI\/CD: relaci\u00f3n con el OWASP CI\/CD Top 10<\/h2>\n\n<p class=\"wp-block-paragraph\">El <a href=\"https:\/\/secure-pipelines.com\/es\/ci-cd-security\/owasp-top-10-ci-cd-risks-explained-real-world-examples\/\">OWASP CI\/CD Top 10<\/a> proporciona un marco estructurado para comprender los riesgos m\u00e1s cr\u00edticos en los entornos CI\/CD. Cada categor\u00eda de riesgo representa una clase de vectores de ataque que los adversarios explotan activamente. As\u00ed es como los principales tipos de ataque se relacionan con este marco:<\/p>\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Riesgo OWASP CI\/CD<\/th><th>Categor\u00eda de ataque<\/th><th>Preocupaci\u00f3n principal<\/th><\/tr><\/thead><tbody><tr><td>CICD-SEC-1<\/td><td>Control de flujo insuficiente<\/td><td>Falta de aprobaciones, sin protecci\u00f3n de ramas<\/td><\/tr><tr><td>CICD-SEC-2<\/td><td>Gesti\u00f3n inadecuada de identidades y accesos<\/td><td>Service accounts demasiado permisivas<\/td><\/tr><tr><td>CICD-SEC-3<\/td><td>Abuso de la cadena de dependencias<\/td><td>Confusi\u00f3n de dependencias, typosquatting<\/td><\/tr><tr><td>CICD-SEC-4<\/td><td>Ejecuci\u00f3n de pipeline envenenada<\/td><td>Configuraci\u00f3n de pipeline maliciosa en PRs\/ramas<\/td><\/tr><tr><td>CICD-SEC-5<\/td><td>PBAC insuficiente<\/td><td>Controles de acceso basados en pipeline ausentes<\/td><\/tr><tr><td>CICD-SEC-6<\/td><td>Higiene de credenciales insuficiente<\/td><td>Secretos hardcodeados, tokens sin rotar<\/td><\/tr><tr><td>CICD-SEC-7<\/td><td>Configuraci\u00f3n de sistema insegura<\/td><td>Configuraciones por defecto, servidores CI sin parchear<\/td><\/tr><tr><td>CICD-SEC-8<\/td><td>Uso no gobernado de servicios de terceros<\/td><td>Actions comprometidas, integraciones sin evaluar<\/td><\/tr><tr><td>CICD-SEC-9<\/td><td>Validaci\u00f3n inadecuada de la integridad de artefactos<\/td><td>Artefactos sin firmar, mutaci\u00f3n de tags<\/td><\/tr><tr><td>CICD-SEC-10<\/td><td>Logging y visibilidad insuficientes<\/td><td>Sin traza de auditor\u00eda, puntos ciegos en la monitorizaci\u00f3n<\/td><\/tr><\/tbody><\/table><\/figure>\n\n<p class=\"wp-block-paragraph\">Para un an\u00e1lisis en profundidad de cada uno de estos riesgos con ejemplos reales, consulta nuestra gu\u00eda detallada: <a href=\"https:\/\/secure-pipelines.com\/es\/ci-cd-security\/owasp-top-10-ci-cd-risks-explained-real-world-examples\/\">Los 10 riesgos CI\/CD del OWASP explicados con ejemplos reales<\/a>.<\/p>\n\n<p class=\"wp-block-paragraph\">Las secciones siguientes exploran en detalle las categor\u00edas de ataque m\u00e1s impactantes, examinando la mec\u00e1nica, los ejemplos reales y las estrategias de detecci\u00f3n de cada una.<\/p>\n\n<h2 class=\"wp-block-heading\">Ejecuci\u00f3n de pipeline envenenada (PPE)<\/h2>\n\n<p class=\"wp-block-paragraph\">La ejecuci\u00f3n de pipeline envenenada (Poisoned Pipeline Execution, PPE) es una de las clases de ataques CI\/CD m\u00e1s peligrosas y prevalentes. Se produce cuando un atacante manipula la configuraci\u00f3n del pipeline CI\/CD o las instrucciones de build para ejecutar c\u00f3digo malicioso dentro del entorno del pipeline. El ataque aprovecha el hecho de que los pipelines ejecutan autom\u00e1ticamente las instrucciones definidas en los archivos de configuraci\u00f3n, y esos archivos a menudo pueden ser modificados por los contribuidores.<\/p>\n\n<h3 class=\"wp-block-heading\">PPE directa (D-PPE)<\/h3>\n\n<p class=\"wp-block-paragraph\">En la PPE directa, el atacante tiene acceso de escritura al repositorio y modifica directamente el archivo de configuraci\u00f3n del pipeline (por ejemplo, <code>.github\/workflows\/*.yml<\/code>, <code>.gitlab-ci.yml<\/code>, <code>Jenkinsfile<\/code> o <code>azure-pipelines.yml<\/code>). El atacante inyecta pasos maliciosos que se ejecutan con todos los privilegios del pipeline. Esto podr\u00eda incluir la exfiltraci\u00f3n de secretos, la inyecci\u00f3n de backdoors en los artefactos de build o el establecimiento de persistencia en el entorno CI\/CD.<\/p>\n\n<p class=\"wp-block-paragraph\">La D-PPE es especialmente eficaz cuando:<\/p>\n\n<ul class=\"wp-block-list\">\n<li>Las reglas de protecci\u00f3n de ramas son d\u00e9biles o inexistentes<\/li>\n\n\n\n<li>Las ejecuciones del pipeline se disparan ante eventos push en cualquier rama<\/li>\n\n\n\n<li>Se utilizan runners autoalojados con estado persistente<\/li>\n\n\n\n<li>Los archivos CODEOWNERS no protegen la configuraci\u00f3n del pipeline<\/li>\n<\/ul>\n\n<h3 class=\"wp-block-heading\">PPE indirecta (I-PPE)<\/h3>\n\n<p class=\"wp-block-paragraph\">La PPE indirecta es m\u00e1s sutil y m\u00e1s dif\u00edcil de detectar. En lugar de modificar directamente la configuraci\u00f3n del pipeline, el atacante modifica archivos que el pipeline <em>consume<\/em> durante la ejecuci\u00f3n. Esto incluye:<\/p>\n\n<ul class=\"wp-block-list\">\n<li><strong>Scripts de build<\/strong> referenciados en el pipeline (por ejemplo, <code>Makefile<\/code>, <code>build.sh<\/code>, scripts de <code>package.json<\/code>)<\/li>\n\n\n\n<li><strong>Manifiestos de dependencias<\/strong> que incorporan paquetes maliciosos durante el build<\/li>\n\n\n\n<li><strong>Archivos de configuraci\u00f3n<\/strong> consumidos por las herramientas de build (por ejemplo, <code>.npmrc<\/code>, <code>setup.py<\/code>, <code>build.gradle<\/code>)<\/li>\n\n\n\n<li><strong>Fixtures de test o archivos de datos<\/strong> que procesan los pasos del pipeline<\/li>\n<\/ul>\n\n<p class=\"wp-block-paragraph\">La I-PPE es especialmente peligrosa porque los procesos de revisi\u00f3n de c\u00f3digo suelen centrarse en los cambios del c\u00f3digo de la aplicaci\u00f3n, no en las implicaciones de seguridad de los scripts de build o los archivos de dependencias modificados. Un atacante puede ocultar instrucciones maliciosas en un cambio aparentemente inocente de un Makefile que se ejecuta con todos los privilegios del pipeline.<\/p>\n\n<h3 class=\"wp-block-heading\">PPE a trav\u00e9s de pull requests<\/h3>\n\n<p class=\"wp-block-paragraph\">Muchos sistemas CI\/CD est\u00e1n configurados para ejecutar pipelines sobre pull requests procedentes de forks, una caracter\u00edstica necesaria para los proyectos open source. Sin embargo, esto crea un vector de ataque directo: un contribuidor externo puede enviar un pull request que modifique la configuraci\u00f3n del pipeline o los scripts de build, y el pipeline ejecutar\u00e1 el c\u00f3digo malicioso antes de que se produzca ninguna revisi\u00f3n humana. Aunque algunas plataformas restringen el acceso a secretos para los PRs de forks, las configuraciones incorrectas exponen secretos con frecuencia, o el propio entorno del pipeline aporta suficiente valor al atacante.<\/p>\n\n<p class=\"wp-block-paragraph\">Para explorar las t\u00e9cnicas de ataque PPE de forma pr\u00e1ctica y aprender contramedidas defensivas, trabaja con nuestro lab dedicado: <a href=\"https:\/\/secure-pipelines.com\/es\/ci-cd-security\/lab-exploiting-defending-poisoned-pipeline-execution-ppe\/\">Lab: explotaci\u00f3n y defensa frente a la ejecuci\u00f3n de pipeline envenenada (PPE)<\/a>.<\/p>\n\n<h2 class=\"wp-block-heading\">Confusi\u00f3n de dependencias y envenenamiento de artefactos<\/h2>\n\n<p class=\"wp-block-paragraph\">Los ataques de confusi\u00f3n de dependencias y de envenenamiento de artefactos explotan la confianza que los sistemas de build depositan en los registries de paquetes y en los mecanismos de resoluci\u00f3n de dependencias. Estos ataques apuntan a la cadena de suministro en su nivel m\u00e1s fundamental: los componentes que se incorporan a tu software durante el build.<\/p>\n\n<h3 class=\"wp-block-heading\">Confusi\u00f3n de dependencias<\/h3>\n\n<p class=\"wp-block-paragraph\">La confusi\u00f3n de dependencias (tambi\u00e9n llamada confusi\u00f3n de namespace o ataques de sustituci\u00f3n) explota la forma en que los gestores de paquetes resuelven las dependencias cuando hay configurados tanto registries p\u00fablicos como privados. El atacante publica un paquete malicioso en un registry p\u00fablico (npm, PyPI, RubyGems) usando el mismo nombre que un paquete interno\/privado utilizado por la organizaci\u00f3n objetivo. Si el gestor de paquetes no est\u00e1 configurado para priorizar el registry privado, puede descargar en su lugar la versi\u00f3n p\u00fablica maliciosa, especialmente si el atacante publica un n\u00famero de versi\u00f3n superior.<\/p>\n\n<p class=\"wp-block-paragraph\">Este ataque fue demostrado de forma c\u00e9lebre por el investigador de seguridad Alex Birsan en 2021, quien utiliz\u00f3 la confusi\u00f3n de dependencias para ejecutar c\u00f3digo dentro de los sistemas de build de Apple, Microsoft, PayPal y decenas de otras grandes organizaciones. El ataque no requer\u00eda ning\u00fan acceso a la organizaci\u00f3n objetivo, solo el conocimiento de los nombres de los paquetes internos, que a veces pueden descubrirse a trav\u00e9s de lock files filtrados, source maps de JavaScript o mensajes de error.<\/p>\n\n<h3 class=\"wp-block-heading\">Typosquatting<\/h3>\n\n<p class=\"wp-block-paragraph\">Relacionado con la confusi\u00f3n de dependencias, el typosquatting consiste en publicar paquetes maliciosos con nombres muy similares a los de paquetes leg\u00edtimos populares (por ejemplo, <code>lodahs<\/code> en lugar de <code>lodash<\/code>, <code>reqeusts<\/code> en lugar de <code>requests<\/code>). Cuando un desarrollador o un script de build comete un error tipogr\u00e1fico en una declaraci\u00f3n de dependencia, se instala el paquete malicioso en su lugar.<\/p>\n\n<h3 class=\"wp-block-heading\">Envenenamiento de artefactos<\/h3>\n\n<p class=\"wp-block-paragraph\">El envenenamiento de artefactos adopta un enfoque diferente, apuntando a los artefactos producidos por los pipelines de build en lugar de a sus entradas. Los atacantes que obtienen acceso al almacenamiento de artefactos (container registries, repositorios de paquetes, almacenamiento de binarios) pueden reemplazar los artefactos leg\u00edtimos por versiones con backdoor. Esto es particularmente eficaz contra las im\u00e1genes de contenedor almacenadas en registries con tags mutables: un atacante que obtenga acceso de escritura puede reemplazar la imagen detr\u00e1s de un tag <code>:latest<\/code> o <code>:v1.2.3<\/code> sin cambiar el propio tag.<\/p>\n\n<p class=\"wp-block-paragraph\">Para una exploraci\u00f3n exhaustiva de estos vectores de ataque y sus defensas, consulta: <a href=\"https:\/\/secure-pipelines.com\/es\/ci-cd-security\/dependency-confusion-artifact-poisoning-attacks-defenses\/\">Confusi\u00f3n de dependencias y envenenamiento de artefactos: ataques y defensas<\/a>.<\/p>\n\n<h2 class=\"wp-block-heading\">Robo de credenciales y exfiltraci\u00f3n de secretos<\/h2>\n\n<p class=\"wp-block-paragraph\">Los pipelines CI\/CD son aut\u00e9nticos tesoros de credenciales. Necesitan acceso a los repositorios de c\u00f3digo fuente, a los proveedores de nube, a los container registries, a las bases de datos, a los destinos de despliegue y a servicios externos. Estas credenciales \u2014claves de API, tokens, contrase\u00f1as, certificados y claves de firma\u2014 son el objetivo principal de muchos ataques a CI\/CD.<\/p>\n\n<h3 class=\"wp-block-heading\">T\u00e9cnicas habituales de exfiltraci\u00f3n de secretos<\/h3>\n\n<p class=\"wp-block-paragraph\">Los atacantes utilizan diversas t\u00e9cnicas para robar secretos de los entornos CI\/CD:<\/p>\n\n<ul class=\"wp-block-list\">\n<li><strong>Volcado de variables de entorno:<\/strong> muchos sistemas CI\/CD inyectan los secretos como variables de entorno. Un simple comando <code>env<\/code> o <code>printenv<\/code> en un paso de pipeline comprometido revela todos los secretos disponibles.<\/li>\n\n\n\n<li><strong>Escaneo del sistema de archivos:<\/strong> los secretos pueden escribirse en disco como archivos (por ejemplo, <code>~\/.docker\/config.json<\/code>, <code>~\/.aws\/credentials<\/code>, <code>~\/.kube\/config<\/code>). Los atacantes escanean el sistema de archivos en busca de archivos de credenciales.<\/li>\n\n\n\n<li><strong>Inspecci\u00f3n de memoria:<\/strong> en los runners autoalojados, los atacantes pueden inspeccionar la memoria de los procesos o <code>\/proc<\/code> para encontrar secretos que se descifraron en tiempo de ejecuci\u00f3n.<\/li>\n\n\n\n<li><strong>Interceptaci\u00f3n de red:<\/strong> si los pipelines se comunican con servicios por canales sin cifrar, los atacantes con acceso a la red pueden interceptar credenciales en tr\u00e1nsito.<\/li>\n\n\n\n<li><strong>Exfiltraci\u00f3n por logs:<\/strong> los secretos que aparecen accidentalmente en los logs de build (algo deprimentemente habitual) pueden ser extra\u00eddos por cualquiera con acceso a los logs.<\/li>\n\n\n\n<li><strong>Exfiltraci\u00f3n por DNS\/HTTP:<\/strong> en entornos restringidos donde las conexiones salientes son limitadas, los atacantes codifican los secretos robados en consultas DNS o cabeceras HTTP para eludir los controles de egress.<\/li>\n<\/ul>\n\n<h3 class=\"wp-block-heading\">El problema acumulativo de la proliferaci\u00f3n de credenciales<\/h3>\n\n<p class=\"wp-block-paragraph\">Un reto clave en la seguridad CI\/CD es la proliferaci\u00f3n de credenciales (credential sprawl): la tendencia de los secretos a acumularse con el tiempo entre configuraciones de pipeline, variables de entorno, almacenes de secretos y archivos de configuraci\u00f3n. Las credenciales de larga duraci\u00f3n que nunca se rotan, las service accounts demasiado permisivas y los secretos compartidos entre m\u00faltiples pipelines aumentan el radio de impacto de un incidente de robo de credenciales.<\/p>\n\n<p class=\"wp-block-paragraph\">La soluci\u00f3n es un enfoque disciplinado de la gesti\u00f3n de secretos que combine credenciales de corta duraci\u00f3n, acceso de m\u00ednimo privilegio, rotaci\u00f3n de secretos e inyecci\u00f3n en tiempo de ejecuci\u00f3n desde un vault centralizado. Para orientaci\u00f3n detallada de implementaci\u00f3n, consulta nuestra gu\u00eda sobre <a href=\"https:\/\/secure-pipelines.com\/es\/ci-cd-security\/secrets-management-ci-cd-pipelines-patterns-vault\/\">Gesti\u00f3n de secretos en pipelines CI\/CD: patrones con Vault<\/a>.<\/p>\n\n<p class=\"wp-block-paragraph\">Para practicar la detecci\u00f3n y prevenci\u00f3n de filtraciones de secretos en un entorno controlado, trabaja con nuestro lab pr\u00e1ctico: <a href=\"https:\/\/secure-pipelines.com\/es\/ci-cd-security\/lab-detecting-preventing-secret-leaks-ci-cd-pipelines-3\/\">Lab: detecci\u00f3n y prevenci\u00f3n de filtraciones de secretos en pipelines CI\/CD<\/a>.<\/p>\n\n<h2 class=\"wp-block-heading\">Manipulaci\u00f3n de artefactos y ataques a registries<\/h2>\n\n<p class=\"wp-block-paragraph\">La integridad de los artefactos es una piedra angular de la seguridad de la cadena de suministro. Si un atacante puede modificar los artefactos que produce tu pipeline \u2014im\u00e1genes de contenedor, paquetes, binarios o manifiestos de despliegue\u2014, puede inyectar c\u00f3digo malicioso que se propaga a todos los entornos que consumen esos artefactos.<\/p>\n\n<h3 class=\"wp-block-heading\">Ataques de mutaci\u00f3n de tags<\/h3>\n\n<p class=\"wp-block-paragraph\">Los container registries permiten por defecto sobrescribir los tags de imagen. Un atacante con acceso de escritura a un registry puede reemplazar la imagen detr\u00e1s de cualquier tag mutable (como <code>:latest<\/code>, <code>:stable<\/code> o incluso un tag de versi\u00f3n aparentemente espec\u00edfico como <code>:v2.1.0<\/code>) por una versi\u00f3n con backdoor. Los sistemas downstream que descarguen ese tag recibir\u00e1n silenciosamente la imagen comprometida.<\/p>\n\n<p class=\"wp-block-paragraph\">Por eso los tags inmutables y las referencias basadas en digest (<code>image@sha256:abc123...<\/code>) son controles de seguridad cr\u00edticos. Los mecanismos de content trust como Docker Content Trust (DCT) y Sigstore\/cosign proporcionan la verificaci\u00f3n criptogr\u00e1fica de la procedencia de las im\u00e1genes.<\/p>\n\n<h3 class=\"wp-block-heading\">Compromiso del registry<\/h3>\n\n<p class=\"wp-block-paragraph\">El compromiso directo de los registries de artefactos \u2014ya sea mediante credenciales robadas, la explotaci\u00f3n de vulnerabilidades del registry o amenazas internas\u2014 da a los atacantes la capacidad de modificar cualquier artefacto almacenado. Los registries autoalojados que carecen de autenticaci\u00f3n, usan credenciales por defecto o ejecutan software sin parchear son particularmente vulnerables.<\/p>\n\n<h3 class=\"wp-block-heading\">Manipulaci\u00f3n del proceso de build<\/h3>\n\n<p class=\"wp-block-paragraph\">En lugar de manipular los artefactos despu\u00e9s de construirlos, los atacantes sofisticados modifican el propio proceso de build para producir artefactos comprometidos. Esto puede implicar manipular Dockerfiles, inyectar capas maliciosas en builds multietapa o modificar los flags de compilaci\u00f3n para insertar backdoors. Estos ataques son particularmente insidiosos porque los artefactos resultantes parecen productos leg\u00edtimos del pipeline CI\/CD.<\/p>\n\n<p class=\"wp-block-paragraph\">Defenderse frente a la manipulaci\u00f3n de artefactos requiere una combinaci\u00f3n de almacenamiento inmutable, firma criptogr\u00e1fica, atestaci\u00f3n de procedencia (como SLSA) y verificaci\u00f3n continua. Para practicar la detecci\u00f3n de manipulaci\u00f3n de artefactos en un entorno pr\u00e1ctico, consulta: <a href=\"https:\/\/secure-pipelines.com\/es\/ci-cd-security\/lab-artifact-tampering-detection-swapping-container-images-registry-2\/\">Lab: detecci\u00f3n de manipulaci\u00f3n de artefactos \u2014 intercambio de im\u00e1genes de contenedor en un registry<\/a>.<\/p>\n\n<h2 class=\"wp-block-heading\">Actions e integraciones de terceros comprometidas<\/h2>\n\n<p class=\"wp-block-paragraph\">Los pipelines CI\/CD modernos no son monol\u00edticos: se ensamblan a partir de decenas de componentes de terceros: GitHub Actions, plantillas de GitLab CI, plugins de Jenkins, providers de Terraform y diversas integraciones SaaS. Cada uno de estos componentes representa una frontera de confianza que los atacantes pueden explotar.<\/p>\n\n<h3 class=\"wp-block-heading\">Ataques a la cadena de suministro de GitHub Actions<\/h3>\n\n<p class=\"wp-block-paragraph\">Las GitHub Actions son un objetivo prioritario porque ejecutan c\u00f3digo arbitrario dentro del contexto del workflow que las invoca. Entre los vectores de ataque est\u00e1n:<\/p>\n\n<ul class=\"wp-block-list\">\n<li><strong>Repositorios de actions comprometidos:<\/strong> un atacante que obtenga acceso al repositorio de una action popular puede publicar c\u00f3digo malicioso que se ejecute en todos los workflows que usen esa action. El incidente de tj-actions\/changed-files en 2023 lo demostr\u00f3 a gran escala.<\/li>\n\n\n\n<li><strong>Manipulaci\u00f3n de tags:<\/strong> las actions referenciadas por tags mutables (por ejemplo, <code>@v3<\/code>) pueden reemplazarse silenciosamente. El atacante mueve el tag para que apunte a un commit malicioso.<\/li>\n\n\n\n<li><strong>Typosquatting:<\/strong> las actions maliciosas publicadas con nombres similares a los de las populares explotan los errores tipogr\u00e1ficos de los desarrolladores.<\/li>\n\n\n\n<li><strong>Apropiaci\u00f3n de actions abandonadas:<\/strong> cuando los mantenedores de una action abandonan sus proyectos, los atacantes a veces pueden reclamar el namespace y publicar actualizaciones maliciosas.<\/li>\n<\/ul>\n\n<h3 class=\"wp-block-heading\">Riesgos de plugins y extensiones<\/h3>\n\n<p class=\"wp-block-paragraph\">Los plugins de Jenkins, los componentes de GitLab CI y otras extensiones CI\/CD afrontan riesgos similares. Muchos plugins los mantienen contribuidores individuales con pr\u00e1cticas de seguridad dispares. Las vulnerabilidades en los plugins pueden exponer toda la infraestructura CI\/CD, ya que los plugins de Jenkins han sido hist\u00f3ricamente una rica fuente de vulnerabilidades de robo de credenciales y ejecuci\u00f3n remota de c\u00f3digo.<\/p>\n\n<p class=\"wp-block-paragraph\">La estrategia defensiva consiste en fijar todos los componentes de terceros a referencias inmutables (SHAs de commit en lugar de tags), auditar las dependencias con regularidad y usar herramientas que detecten actions maliciosas conocidas. Para practicar de forma directa la detecci\u00f3n de GitHub Actions maliciosas, trabaja con: <a href=\"https:\/\/secure-pipelines.com\/es\/ci-cd-security\/lab-detecting-malicious-github-actions-static-analysis-2\/\">Lab: detecci\u00f3n de GitHub Actions maliciosas con an\u00e1lisis est\u00e1tico<\/a>.<\/p>\n\n<h2 class=\"wp-block-heading\">Cronolog\u00eda de ataques CI\/CD reales<\/h2>\n\n<p class=\"wp-block-paragraph\">La siguiente cronolog\u00eda recorre los principales ataques a CI\/CD y a la cadena de suministro de software de 2020 a 2024. Cada incidente ilustra distintos vectores de ataque y refuerza por qu\u00e9 la seguridad CI\/CD merece una atenci\u00f3n espec\u00edfica.<\/p>\n\n<h3 class=\"wp-block-heading\">SolarWinds \/ SUNBURST (diciembre de 2020)<\/h3>\n\n<p class=\"wp-block-paragraph\">El ataque a SolarWinds sigue siendo el compromiso de cadena de suministro CI\/CD por antonomasia. Los atacantes (atribuidos al servicio de inteligencia SVR de Rusia) se infiltraron en la infraestructura de build de SolarWinds e inyectaron el backdoor SUNBURST en el proceso de actualizaci\u00f3n del software Orion. El pipeline de build comprometido produjo actualizaciones troyanizadas que se distribuyeron a aproximadamente 18 000 organizaciones, incluidas agencias gubernamentales de EE. UU., empresas de la lista Fortune 500 y operadores de infraestructuras cr\u00edticas.<\/p>\n\n<p class=\"wp-block-paragraph\"><strong>Lecciones clave:<\/strong> la infraestructura de build debe tratarse como un activo cr\u00edtico. La verificaci\u00f3n de la integridad de los artefactos y los builds reproducibles podr\u00edan haber detectado la manipulaci\u00f3n. El ataque demostr\u00f3 que comprometer un \u00fanico pipeline de build puede tener un impacto a nivel de estado-naci\u00f3n.<\/p>\n\n<h3 class=\"wp-block-heading\">Codecov Bash Uploader (enero\u2013abril de 2021)<\/h3>\n\n<p class=\"wp-block-paragraph\">Los atacantes comprometieron el script Bash Uploader de Codecov, un componente utilizado por miles de pipelines CI\/CD para subir informes de cobertura de c\u00f3digo. Durante tres meses, el script modificado exfiltr\u00f3 variables de entorno (incluidos secretos, tokens y claves CI\/CD) de cada pipeline que lo ejecutaba. El ataque afect\u00f3 a empresas como Twitch, HashiCorp, Confluent y muchas otras.<\/p>\n\n<p class=\"wp-block-paragraph\"><strong>Lecciones clave:<\/strong> los scripts de terceros ejecutados en los pipelines deben verificarse en su integridad (por ejemplo, mediante checksums). Los secretos nunca deber\u00edan estar disponibles de forma amplia como variables de entorno. La monitorizaci\u00f3n de egress en los runners CI\/CD podr\u00eda haber detectado la exfiltraci\u00f3n.<\/p>\n\n<h3 class=\"wp-block-heading\">Secuestro de ua-parser-js (octubre de 2021)<\/h3>\n\n<p class=\"wp-block-paragraph\">El paquete npm <code>ua-parser-js<\/code>, descargado m\u00e1s de 7 millones de veces por semana, fue secuestrado cuando se comprometi\u00f3 la cuenta npm del mantenedor. Se publicaron versiones maliciosas que instalaban criptomineros y malware de robo de credenciales. Como este paquete es una dependencia de miles de otros paquetes y procesos de build CI\/CD, el radio de impacto fue enorme.<\/p>\n\n<p class=\"wp-block-paragraph\"><strong>Lecciones clave:<\/strong> incluso los paquetes confiables y de uso extendido pueden verse comprometidos. Los lock files, la comprobaci\u00f3n de integridad y el escaneo automatizado de dependencias en CI\/CD son esenciales. La seguridad de las cuentas npm (2FA, acotaci\u00f3n de tokens) es una preocupaci\u00f3n de la cadena de suministro.<\/p>\n\n<h3 class=\"wp-block-heading\">Incidente de seguridad de CircleCI (enero de 2023)<\/h3>\n\n<p class=\"wp-block-paragraph\">CircleCI, una de las mayores plataformas CI\/CD, revel\u00f3 que un atacante hab\u00eda obtenido acceso a datos de clientes, incluidas variables de entorno, claves y tokens almacenados en CircleCI. La brecha se origin\u00f3 a partir de malware en el port\u00e1til de un ingeniero que rob\u00f3 un token de sesi\u00f3n SSO v\u00e1lido, que luego se utiliz\u00f3 para acceder a los sistemas internos. CircleCI inst\u00f3 a todos sus clientes a rotar de inmediato todos los secretos almacenados en la plataforma.<\/p>\n\n<p class=\"wp-block-paragraph\"><strong>Lecciones clave:<\/strong> los proveedores de plataformas CI\/CD son objetivos de alto valor. Las organizaciones deber\u00edan implementar defensa en profundidad y no depender \u00fanicamente de la seguridad de su plataforma CI\/CD. Las credenciales de corta duraci\u00f3n y acotadas limitan el impacto de los compromisos de la plataforma. Contar con un plan de respuesta a incidentes para la rotaci\u00f3n de secretos es fundamental.<\/p>\n\n<h3 class=\"wp-block-heading\">Compromiso de tj-actions\/changed-files (marzo de 2023)<\/h3>\n\n<p class=\"wp-block-paragraph\">La popular GitHub Action <code>tj-actions\/changed-files<\/code> (usada por m\u00e1s de 23 000 repositorios) fue comprometida cuando un atacante obtuvo acceso a la cuenta del mantenedor y public\u00f3 c\u00f3digo malicioso. La action comprometida volcaba los secretos CI\/CD en los logs de los workflows, donde pod\u00edan ser recolectados. Como muchos workflows referenciaban la action mediante tags de versi\u00f3n mutables, el c\u00f3digo malicioso se incorpor\u00f3 autom\u00e1ticamente a miles de ejecuciones de pipeline.<\/p>\n\n<p class=\"wp-block-paragraph\"><strong>Lecciones clave:<\/strong> fija siempre las GitHub Actions a SHAs de commit, no a tags de versi\u00f3n. Monitoriza las dependencias de actions en busca de cambios inesperados. Implementa los permisos de workflow siguiendo el principio de m\u00ednimo privilegio.<\/p>\n\n<h3 class=\"wp-block-heading\">Backdoor en XZ Utils (marzo de 2024)<\/h3>\n\n<p class=\"wp-block-paragraph\">El backdoor de XZ Utils (CVE-2024-3094) fue un sofisticado ataque a la cadena de suministro de varios a\u00f1os. Un contribuidor que hab\u00eda ganado confianza dentro del proyecto XZ a lo largo de dos a\u00f1os introdujo gradualmente un backdoor en el sistema de build. El c\u00f3digo malicioso se ocultaba en archivos de fixtures de test y se activaba mediante scripts de build cuidadosamente elaborados: un ejemplo de manual de ejecuci\u00f3n de pipeline envenenada indirecta. El backdoor apuntaba al daemon SSH de los sistemas Linux y habr\u00eda afectado a pr\u00e1cticamente todas las distribuciones de Linux de no haberse descubierto por casualidad.<\/p>\n\n<p class=\"wp-block-paragraph\"><strong>Lecciones clave:<\/strong> la ingenier\u00eda social y la infiltraci\u00f3n a largo plazo de los proyectos open source son amenazas reales. La integridad del sistema de build es tan importante como la integridad del c\u00f3digo fuente. El ataque demostr\u00f3 que las t\u00e9cnicas de I-PPE pueden ser extraordinariamente sutiles y pacientes.<\/p>\n\n<h2 class=\"wp-block-heading\">Patrones defensivos y mitigaciones<\/h2>\n\n<p class=\"wp-block-paragraph\">Defenderse frente a los ataques a CI\/CD requiere un enfoque por capas que aborde cada categor\u00eda de ataque. Los siguientes patrones constituyen la base de una postura de seguridad CI\/CD robusta.<\/p>\n\n<h3 class=\"wp-block-heading\">Configuraci\u00f3n del pipeline como c\u00f3digo con controles estrictos<\/h3>\n\n<ul class=\"wp-block-list\">\n<li>Protege los archivos de configuraci\u00f3n del pipeline con CODEOWNERS y reglas de protecci\u00f3n de ramas<\/li>\n\n\n\n<li>Exige revisi\u00f3n de c\u00f3digo para todos los cambios en la configuraci\u00f3n CI\/CD<\/li>\n\n\n\n<li>Usa plantillas de pipeline gestionadas centralmente en lugar de configuraciones por repo siempre que sea posible<\/li>\n\n\n\n<li>Separa las definiciones de pipeline del c\u00f3digo de la aplicaci\u00f3n en los repositorios sensibles<\/li>\n<\/ul>\n\n<h3 class=\"wp-block-heading\">Fortalecimiento de credenciales<\/h3>\n\n<ul class=\"wp-block-list\">\n<li>Usa credenciales de corta duraci\u00f3n y acotadas (federaci\u00f3n OIDC con los proveedores de nube)<\/li>\n\n\n\n<li>Implementa la inyecci\u00f3n de secretos just-in-time desde un vault centralizado<\/li>\n\n\n\n<li>Nunca expongas secretos como variables de entorno cuando est\u00e9 disponible la inyecci\u00f3n basada en archivos<\/li>\n\n\n\n<li>Rota todas las credenciales seg\u00fan un calendario definido e inmediatamente despu\u00e9s de cualquier incidente<\/li>\n\n\n\n<li>Implementa el escaneo de secretos en los logs CI\/CD y en las salidas de artefactos<\/li>\n<\/ul>\n\n<h3 class=\"wp-block-heading\">Controles de dependencias y cadena de suministro<\/h3>\n\n<ul class=\"wp-block-list\">\n<li>Fija todas las dependencias a versiones exactas con hashes de integridad<\/li>\n\n\n\n<li>Usa proxies de registry privados con acotaci\u00f3n de namespace para prevenir la confusi\u00f3n de dependencias<\/li>\n\n\n\n<li>Fija las GitHub Actions y otros componentes de pipeline de terceros a SHAs de commit<\/li>\n\n\n\n<li>Implementa el escaneo automatizado de vulnerabilidades de dependencias en cada pipeline<\/li>\n\n\n\n<li>Genera y verifica listas de materiales de software (SBOMs)<\/li>\n<\/ul>\n\n<h3 class=\"wp-block-heading\">Integridad de artefactos<\/h3>\n\n<ul class=\"wp-block-list\">\n<li>Firma criptogr\u00e1ficamente todos los artefactos de build (Sigstore\/cosign para contenedores, GPG para paquetes)<\/li>\n\n\n\n<li>Usa tags inmutables y referencias basadas en digest para las im\u00e1genes de contenedor<\/li>\n\n\n\n<li>Implementa la atestaci\u00f3n de procedencia SLSA para verificar el origen de los artefactos<\/li>\n\n\n\n<li>Despliega admission controllers (por ejemplo, Kyverno, OPA Gatekeeper) que verifiquen las firmas antes del despliegue<\/li>\n<\/ul>\n\n<h3 class=\"wp-block-heading\">Monitorizaci\u00f3n y detecci\u00f3n<\/h3>\n\n<ul class=\"wp-block-list\">\n<li>Monitoriza la ejecuci\u00f3n del pipeline en busca de comportamientos an\u00f3malos (conexiones de red inesperadas, accesos al sistema de archivos, jobs de larga duraci\u00f3n)<\/li>\n\n\n\n<li>Implementa controles de egress en los runners CI\/CD para detectar la exfiltraci\u00f3n<\/li>\n\n\n\n<li>Audita todos los cambios en las configuraciones del pipeline, los secretos y los permisos<\/li>\n\n\n\n<li>Correlaciona los eventos CI\/CD con un SIEM para la detecci\u00f3n entre sistemas<\/li>\n<\/ul>\n\n<p class=\"wp-block-paragraph\">Para un an\u00e1lisis exhaustivo de cada uno de estos patrones defensivos con ejemplos de implementaci\u00f3n, consulta: <a href=\"https:\/\/secure-pipelines.com\/es\/ci-cd-security\/defensive-patterns-mitigations-ci-cd-pipeline-attacks\/\">Patrones defensivos y mitigaciones para ataques a pipelines CI\/CD<\/a>.<\/p>\n\n<h2 class=\"wp-block-heading\">Modelado de amenazas para CI\/CD<\/h2>\n\n<p class=\"wp-block-paragraph\">La seguridad CI\/CD eficaz empieza con el modelado de amenazas: identificar de forma sistem\u00e1tica las fronteras de confianza, los flujos de datos y las rutas de ataque dentro de tu arquitectura de pipeline. Sin una comprensi\u00f3n clara de tu modelo de amenazas CI\/CD, los esfuerzos defensivos tienden a ser reactivos e incompletos.<\/p>\n\n<h3 class=\"wp-block-heading\">Fronteras de confianza clave que evaluar<\/h3>\n\n<p class=\"wp-block-paragraph\">Todo sistema CI\/CD tiene fronteras de confianza que los atacantes intentan cruzar:<\/p>\n\n<ul class=\"wp-block-list\">\n<li><strong>De la estaci\u00f3n de trabajo del desarrollador al repositorio:<\/strong> \u00bfpuede una m\u00e1quina de desarrollador comprometida publicar c\u00f3digo malicioso?<\/li>\n\n\n\n<li><strong>Del repositorio al pipeline:<\/strong> \u00bfqu\u00e9 cambios disparan la ejecuci\u00f3n del pipeline, y con qu\u00e9 privilegios?<\/li>\n\n\n\n<li><strong>Del pipeline al almac\u00e9n de secretos:<\/strong> \u00bfqu\u00e9 pipelines pueden acceder a qu\u00e9 secretos, y bajo qu\u00e9 condiciones?<\/li>\n\n\n\n<li><strong>Del pipeline al registry de artefactos:<\/strong> \u00bfqui\u00e9n puede publicar artefactos, y se verifican antes de usarlos?<\/li>\n\n\n\n<li><strong>Del registry de artefactos al despliegue:<\/strong> \u00bfse verifican los artefactos desplegados contra su procedencia de build?<\/li>\n\n\n\n<li><strong>De los servicios de terceros al pipeline:<\/strong> \u00bfqu\u00e9 acceso tienen las integraciones externas?<\/li>\n<\/ul>\n\n<h3 class=\"wp-block-heading\">An\u00e1lisis de rutas de ataque<\/h3>\n\n<p class=\"wp-block-paragraph\">Una vez cartografiadas las fronteras de confianza, el siguiente paso es enumerar las rutas de ataque: las secuencias de acciones que un atacante podr\u00eda llevar a cabo para lograr sus objetivos. Entre los objetivos habituales est\u00e1n:<\/p>\n\n<ul class=\"wp-block-list\">\n<li>Inyectar c\u00f3digo malicioso en los despliegues de producci\u00f3n<\/li>\n\n\n\n<li>Exfiltrar credenciales para el movimiento lateral<\/li>\n\n\n\n<li>Establecer persistencia en la infraestructura CI\/CD<\/li>\n\n\n\n<li>Interrumpir la entrega de software (sabotaje\/denegaci\u00f3n de servicio)<\/li>\n\n\n\n<li>Comprometer a los consumidores downstream mediante la propagaci\u00f3n por la cadena de suministro<\/li>\n<\/ul>\n\n<p class=\"wp-block-paragraph\">Para una gu\u00eda completa sobre el modelado de amenazas CI\/CD con marcos y plantillas pr\u00e1cticos, consulta: <a href=\"https:\/\/secure-pipelines.com\/es\/threats-attacks\/ci-cd-threat-modeling-trust-boundaries-attack-paths-2\/\">Modelado de amenazas CI\/CD: fronteras de confianza y rutas de ataque<\/a>.<\/p>\n\n<h2 class=\"wp-block-heading\">Labs pr\u00e1cticos: practica el ataque y la defensa<\/h2>\n\n<p class=\"wp-block-paragraph\">Comprender los ataques a CI\/CD en teor\u00eda es importante, pero no hay sustituto para la pr\u00e1ctica directa. Los siguientes labs proporcionan entornos controlados donde puedes explorar de forma segura las t\u00e9cnicas de ataque e implementar defensas:<\/p>\n\n<ul class=\"wp-block-list\">\n<li><strong><a href=\"https:\/\/secure-pipelines.com\/es\/ci-cd-security\/lab-exploiting-defending-poisoned-pipeline-execution-ppe\/\">Lab: explotaci\u00f3n y defensa frente a la ejecuci\u00f3n de pipeline envenenada (PPE)<\/a><\/strong> \u2014 practica los ataques de PPE tanto directa como indirecta, y luego implementa protecci\u00f3n de ramas, CODEOWNERS y controles de configuraci\u00f3n del pipeline para defenderte de ellos.<\/li>\n\n\n\n<li><strong><a href=\"https:\/\/secure-pipelines.com\/es\/ci-cd-security\/dependency-confusion-artifact-poisoning-attacks-defenses\/\">Lab: confusi\u00f3n de dependencias y envenenamiento de artefactos<\/a><\/strong> \u2014 ejecuta un ataque de confusi\u00f3n de dependencias contra una configuraci\u00f3n de build vulnerable, y luego implementa la acotaci\u00f3n de namespace, la verificaci\u00f3n de integridad y los controles de registry privado.<\/li>\n\n\n\n<li><strong><a href=\"https:\/\/secure-pipelines.com\/es\/ci-cd-security\/lab-detecting-preventing-secret-leaks-ci-cd-pipelines-3\/\">Lab: detecci\u00f3n y prevenci\u00f3n de filtraciones de secretos en pipelines CI\/CD<\/a><\/strong> \u2014 descubre secretos expuestos a trav\u00e9s de variables de entorno, logs y artefactos, y luego implementa la detecci\u00f3n con herramientas como gitleaks, truffleHog y guards de pipeline personalizados.<\/li>\n\n\n\n<li><strong><a href=\"https:\/\/secure-pipelines.com\/es\/ci-cd-security\/lab-artifact-tampering-detection-swapping-container-images-registry-2\/\">Lab: detecci\u00f3n de manipulaci\u00f3n de artefactos \u2014 intercambio de im\u00e1genes de contenedor en un registry<\/a><\/strong> \u2014 realiza un ataque de mutaci\u00f3n de tags contra un container registry, y luego implementa content trust, fijado por digest y verificaci\u00f3n mediante admission controller.<\/li>\n\n\n\n<li><strong><a href=\"https:\/\/secure-pipelines.com\/es\/ci-cd-security\/lab-detecting-malicious-github-actions-static-analysis-2\/\">Lab: detecci\u00f3n de GitHub Actions maliciosas con an\u00e1lisis est\u00e1tico<\/a><\/strong> \u2014 analiza las GitHub Actions en busca de patrones maliciosos, implementa el fijado por SHA e incorpora la detecci\u00f3n automatizada a tu proceso de aprobaci\u00f3n de workflows.<\/li>\n<\/ul>\n\n<p class=\"wp-block-paragraph\">Cada lab incluye instrucciones paso a paso, un entorno preconfigurado y escenarios tanto de ataque como de defensa. Est\u00e1n dise\u00f1ados para completarse de forma independiente, aunque trabajarlos en el orden indicado arriba te aportar\u00e1 una comprensi\u00f3n integral de la seguridad CI\/CD.<\/p>\n\n<h2 class=\"wp-block-heading\">Conclusi\u00f3n: construir una arquitectura CI\/CD defendible<\/h2>\n\n<p class=\"wp-block-paragraph\">Los pipelines CI\/CD se han convertido en la superficie de ataque m\u00e1s trascendental de las organizaciones de software modernas. Los incidentes catalogados en esta gu\u00eda \u2014de SolarWinds a XZ Utils\u2014 demuestran que los atacantes han reconocido esta realidad y est\u00e1n invirtiendo recursos significativos en t\u00e9cnicas de explotaci\u00f3n de CI\/CD.<\/p>\n\n<p class=\"wp-block-paragraph\">Pero el panorama no es del todo sombr\u00edo. La comunidad de seguridad CI\/CD ha respondido con marcos (OWASP CI\/CD Top 10, SLSA), herramientas (Sigstore, gitleaks, StepSecurity) y patrones arquitect\u00f3nicos que pueden reducir dr\u00e1sticamente tu exposici\u00f3n. Los principios clave que conviene recordar son:<\/p>\n\n<ol class=\"wp-block-list\">\n<li><strong>Trata los pipelines como infraestructura de producci\u00f3n.<\/strong> Aplica a CI\/CD el mismo rigor de seguridad que aplicas a los sistemas de producci\u00f3n: acceso de m\u00ednimo privilegio, monitorizaci\u00f3n, parcheo y respuesta a incidentes.<\/li>\n\n\n\n<li><strong>Elimina la confianza impl\u00edcita.<\/strong> Verif\u00edcalo todo: dependencias, actions de terceros, artefactos y configuraciones de pipeline. Fija a referencias inmutables. Firma y verifica en cada etapa.<\/li>\n\n\n\n<li><strong>Minimiza el radio de impacto.<\/strong> Usa credenciales de corta duraci\u00f3n, permisos acotados, runners aislados y segmentaci\u00f3n de red para limitar lo que un atacante puede lograr desde cualquier compromiso individual.<\/li>\n\n\n\n<li><strong>Invierte en visibilidad.<\/strong> No puedes defender lo que no puedes ver. El logging, la monitorizaci\u00f3n y las alertas exhaustivas para los sistemas CI\/CD son innegociables.<\/li>\n\n\n\n<li><strong>Practica tu respuesta.<\/strong> Usa los labs enlazados a lo largo de esta gu\u00eda para desarrollar memoria muscular tanto en la detecci\u00f3n de ataques como en la implementaci\u00f3n de defensas. Cuando llegue el pr\u00f3ximo incidente CI\/CD, estar\u00e1s listo.<\/li>\n<\/ol>\n\n<p class=\"wp-block-paragraph\">La seguridad CI\/CD no es un proyecto puntual: es una disciplina continua que debe evolucionar a medida que avanzan las t\u00e9cnicas de ataque. Empieza con un <a href=\"https:\/\/secure-pipelines.com\/es\/threats-attacks\/ci-cd-threat-modeling-trust-boundaries-attack-paths-2\/\">modelo de amenazas<\/a>, implementa los <a href=\"https:\/\/secure-pipelines.com\/es\/ci-cd-security\/defensive-patterns-mitigations-ci-cd-pipeline-attacks\/\">patrones defensivos<\/a> que aborden tus mayores riesgos y valida continuamente tus defensas a trav\u00e9s de los labs pr\u00e1cticos de arriba. Tus pipelines son demasiado importantes como para dejarlos sin defensa.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>La entrega de software moderna se apoya en pipelines de integraci\u00f3n continua y entrega continua (CI\/CD) para construir, probar y desplegar c\u00f3digo a gran escala. Estos pipelines se han convertido en la columna vertebral de DevOps, permitiendo a las organizaciones distribuir funcionalidades m\u00e1s r\u00e1pido y de forma m\u00e1s fiable que nunca. Pero este poder conlleva &#8230; <a title=\"Amenazas y Ataques CI\/CD: Qu\u00e9 Atacan los Adversarios y C\u00f3mo Defenderse\" class=\"read-more\" href=\"https:\/\/secure-pipelines.com\/es\/ci-cd-security\/ci-cd-threats-attacks-what-attackers-target-how-to-defend-2\/\" aria-label=\"Leer m\u00e1s sobre Amenazas y Ataques CI\/CD: Qu\u00e9 Atacan los Adversarios y C\u00f3mo Defenderse\">Leer m\u00e1s<\/a><\/p>\n","protected":false},"author":1,"featured_media":1558,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[55,60],"tags":[],"post_folder":[],"class_list":["post-599","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ci-cd-security","category-threats-attacks"],"_links":{"self":[{"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts\/599","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=599"}],"version-history":[{"count":7,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts\/599\/revisions"}],"predecessor-version":[{"id":1593,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts\/599\/revisions\/1593"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/media\/1558"}],"wp:attachment":[{"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/media?parent=599"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/categories?post=599"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/tags?post=599"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/post_folder?post=599"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}