{"id":713,"date":"2026-01-19T10:10:45","date_gmt":"2026-01-19T09:10:45","guid":{"rendered":"https:\/\/secure-pipelines.com\/ci-cd-security\/ci-cd-pipelines-primary-attack-surface-2\/"},"modified":"2026-07-08T22:45:04","modified_gmt":"2026-07-08T21:45:04","slug":"ci-cd-pipelines-primary-attack-surface","status":"publish","type":"post","link":"https:\/\/secure-pipelines.com\/es\/threats-attacks\/ci-cd-pipelines-primary-attack-surface\/","title":{"rendered":"Por qu\u00e9 los pipelines CI\/CD son la nueva superficie de ataque principal"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">Durante a\u00f1os, los programas de seguridad de aplicaciones se han centrado en los entornos de producci\u00f3n: endurecer servidores, parchear vulnerabilidades, desplegar WAFs y monitorizar el comportamiento en tiempo de ejecuci\u00f3n. Ese enfoque ten\u00eda sentido cuando la mayor\u00eda de los compromisos relevantes ocurr\u00edan <em>despu\u00e9s<\/em> del despliegue, explotando debilidades en las aplicaciones en ejecuci\u00f3n.<\/p>\n\n<p class=\"wp-block-paragraph\">Pero los atacantes modernos eluden cada vez m\u00e1s las defensas de producci\u00f3n. En lugar de atacar la aplicaci\u00f3n en tiempo de ejecuci\u00f3n, comprometen los sistemas que <strong>compilan<\/strong>, <strong>empaquetan<\/strong> y <strong>entregan<\/strong> el software: los pipelines CI\/CD y la cadena de suministro de software que hay detr\u00e1s de ellos.<\/p>\n\n<p class=\"wp-block-paragraph\">En muchas organizaciones, los pipelines CI\/CD son hoy un objetivo m\u00e1s valioso y m\u00e1s fr\u00e1gil que la propia producci\u00f3n. La raz\u00f3n es sencilla: los pipelines se sit\u00faan en la intersecci\u00f3n de la confianza, los privilegios y la distribuci\u00f3n. Si los atacantes pueden controlar el pipeline, pueden controlar lo que llega a producci\u00f3n y lo que llega a los usuarios.<\/p>\n\n<p class=\"wp-block-paragraph\">Este art\u00edculo explica por qu\u00e9 los pipelines se convirtieron en una superficie de ataque principal, qu\u00e9 nos ense\u00f1an los incidentes recientes de la cadena de suministro, en qu\u00e9 se diferencia la seguridad del pipeline de la seguridad en tiempo de ejecuci\u00f3n y qu\u00e9 errores de dise\u00f1o comunes mantienen a los pipelines vulnerables. La conclusi\u00f3n es clara: <strong>el pipeline es una frontera de confianza<\/strong>, y debe dise\u00f1arse como tal.<\/p>\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n<h2 class=\"wp-block-heading\">La evoluci\u00f3n de los ataques al software<\/h2>\n\n<p class=\"wp-block-paragraph\">Las amenazas cl\u00e1sicas de seguridad de aplicaciones apuntaban a vulnerabilidades en tiempo de ejecuci\u00f3n: inyecci\u00f3n SQL, RCE, SSRF, bypass de autenticaci\u00f3n y escalada de privilegios. Los defensores han pasado dos d\u00e9cadas elevando el coste de estos ataques mediante:<\/p>\n\n<ul class=\"wp-block-list\">\n<li>Mejoras en el parcheo, el escaneo de dependencias y la gesti\u00f3n de vulnerabilidades<\/li>\n\n\n\n<li>Controles de seguridad cloud-native e infraestructura gestionada<\/li>\n\n\n\n<li>Mejor aislamiento (contenedores, sandboxes, segmentaci\u00f3n)<\/li>\n\n\n\n<li>Capacidades centralizadas de registro y detecci\u00f3n<\/li>\n<\/ul>\n\n<p class=\"wp-block-paragraph\">Como resultado, los adversarios se adaptaron. Si la producci\u00f3n se vuelve m\u00e1s dif\u00edcil de explotar directamente, los atacantes buscan apalancamiento en otro lugar, y el proceso de entrega de software ofrece ese apalancamiento.<\/p>\n\n<p class=\"wp-block-paragraph\">En lugar de preguntarse \u00ab\u00bfC\u00f3mo entro en este sistema en ejecuci\u00f3n?\u00bb, los atacantes se preguntan cada vez m\u00e1s:<\/p>\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\">\u00bfC\u00f3mo consigo que mi c\u00f3digo se env\u00ede como si fuera leg\u00edtimo?<\/p>\n<\/blockquote>\n\n<p class=\"wp-block-paragraph\">Cuando eso ocurre, las defensas dise\u00f1adas para el compromiso en tiempo de ejecuci\u00f3n pueden volverse irrelevantes. Una actualizaci\u00f3n maliciosa entregada a trav\u00e9s de canales leg\u00edtimos no es una \u00abbrecha\u00bb en el sentido tradicional: puede parecer un funcionamiento normal.<\/p>\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n<h2 class=\"wp-block-heading\">Tres incidentes que ilustran el cambio<\/h2>\n\n<p class=\"wp-block-paragraph\">Los incidentes de la cadena de suministro de gran repercusi\u00f3n no ocurrieron porque las defensas en tiempo de ejecuci\u00f3n fueran d\u00e9biles. Ocurrieron porque los atacantes comprometieron mecanismos de entrega que se sit\u00faan aguas arriba de la producci\u00f3n. Los detalles difieren, pero el patr\u00f3n es consistente: compromete un paso de build o distribuci\u00f3n de confianza y heredar\u00e1s la confianza a escala.<\/p>\n\n<h3 class=\"wp-block-heading\">SolarWinds: compromete el build y llega a todos<\/h3>\n\n<p class=\"wp-block-paragraph\">En el incidente de SolarWinds, los atacantes lograron inyectar c\u00f3digo malicioso en las actualizaciones de software. La caracter\u00edstica definitoria no fue un \u00fanico servidor explotado, sino la capacidad de distribuir software con puerta trasera a trav\u00e9s de un canal de actualizaci\u00f3n de confianza.<\/p>\n\n<p class=\"wp-block-paragraph\">El retorno de la inversi\u00f3n del atacante fue enorme: compromete el pipeline de build o de release una sola vez y luego deja que los clientes instalen tu payload por ti.<\/p>\n\n<h3 class=\"wp-block-heading\">Codecov: compromete el tooling de CI y roba secretos a escala<\/h3>\n\n<p class=\"wp-block-paragraph\">En el incidente de Codecov, un compromiso afect\u00f3 a c\u00f3mo los entornos de CI manejaban un script. El impacto pr\u00e1ctico: los sistemas de CI que se ejecutaban en muchas organizaciones filtraron informaci\u00f3n sensible.<\/p>\n\n<p class=\"wp-block-paragraph\">Los entornos de CI son extremadamente sensibles porque suelen albergar:<\/p>\n\n<ul class=\"wp-block-list\">\n<li>Tokens de repositorio<\/li>\n\n\n\n<li>Credenciales de nube<\/li>\n\n\n\n<li>Claves de firma o acceso a servicios de firma<\/li>\n\n\n\n<li>Secretos de despliegue<\/li>\n<\/ul>\n\n<p class=\"wp-block-paragraph\">Este incidente pone de relieve que el tooling de CI no es \u00absolo automatizaci\u00f3n\u00bb: es un sistema de procesamiento de secretos de alto valor.<\/p>\n\n<h3 class=\"wp-block-heading\">3CX: compromete a un proveedor y convierte la confianza en un arma<\/h3>\n\n<p class=\"wp-block-paragraph\">El incidente de 3CX demostr\u00f3 otra din\u00e1mica de la cadena de suministro: comprometer a un proveedor y convertir la confianza en un arma para distribuir software malicioso a los clientes posteriores.<\/p>\n\n<p class=\"wp-block-paragraph\">Desde el punto de vista de la defensa, la lecci\u00f3n no se limita a los proveedores. Internamente, tu pipeline CI\/CD es, en la pr\u00e1ctica, un \u00abproveedor\u00bb de tu entorno de producci\u00f3n y de tus usuarios: producci\u00f3n conf\u00eda en las salidas del pipeline.<\/p>\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n<h2 class=\"wp-block-heading\">Por qu\u00e9 el pipeline es m\u00e1s atractivo que la producci\u00f3n<\/h2>\n\n<p class=\"wp-block-paragraph\">Los atacantes eligen sus objetivos en funci\u00f3n del apalancamiento. Los pipelines CI\/CD ofrecen un apalancamiento que los sistemas de producci\u00f3n rara vez igualan.<\/p>\n\n<h3 class=\"wp-block-heading\">1) Los pipelines agregan confianza<\/h3>\n\n<p class=\"wp-block-paragraph\">Un pipeline es el tejido conectivo entre:<\/p>\n\n<ul class=\"wp-block-list\">\n<li>Repositorios de c\u00f3digo fuente (Git)<\/li>\n\n\n\n<li>Registros de dependencias (npm, PyPI, Maven, etc.)<\/li>\n\n\n\n<li>Sistemas de build y runners<\/li>\n\n\n\n<li>Repositorios de artefactos (registros de contenedores, repos de paquetes)<\/li>\n\n\n\n<li>Sistemas de firma y metadatos de procedencia<\/li>\n\n\n\n<li>Destinos de despliegue (Kubernetes, cuentas de nube, servidores de producci\u00f3n)<\/li>\n<\/ul>\n\n<p class=\"wp-block-paragraph\">Comprometer la producci\u00f3n normalmente te da acceso a <em>un<\/em> entorno. Comprometer el pipeline puede darte:<\/p>\n\n<ul class=\"wp-block-list\">\n<li>Acceso a m\u00faltiples entornos mediante credenciales de automatizaci\u00f3n<\/li>\n\n\n\n<li>Control sobre los artefactos de release<\/li>\n\n\n\n<li>Influencia sobre qu\u00e9 se despliega y cu\u00e1ndo<\/li>\n<\/ul>\n\n<p class=\"wp-block-paragraph\">Los pipelines son \u00abmultiplicadores de confianza\u00bb: pueden tomar entradas no confiables y producir salidas de confianza. Si los atacantes controlan esa transformaci\u00f3n, controlan la confianza.<\/p>\n\n<h3 class=\"wp-block-heading\">2) Los pipelines operan con privilegios elevados por dise\u00f1o<\/h3>\n\n<p class=\"wp-block-paragraph\">La automatizaci\u00f3n necesita privilegios. Los pipelines a menudo requieren permisos para:<\/p>\n\n<ul class=\"wp-block-list\">\n<li>Leer y escribir en repositorios (incluidas etiquetas y releases)<\/li>\n\n\n\n<li>Descargar dependencias y publicar artefactos<\/li>\n\n\n\n<li>Acceder a secretos para la firma o el despliegue<\/li>\n\n\n\n<li>Desplegar en staging o producci\u00f3n<\/li>\n<\/ul>\n\n<p class=\"wp-block-paragraph\">En muchas organizaciones, las identidades del pipeline se convierten en \u00absuperidentidades\u00bb con el tiempo, porque es m\u00e1s f\u00e1cil conceder acceso amplio que dise\u00f1ar permisos granulares.<\/p>\n\n<p class=\"wp-block-paragraph\">Esto crea una estrategia de ataque predecible: comprometer la identidad del pipeline en lugar de luchar contra las defensas de producci\u00f3n.<\/p>\n\n<h3 class=\"wp-block-heading\">3) El compromiso del pipeline escala mejor<\/h3>\n\n<p class=\"wp-block-paragraph\">El compromiso en tiempo de ejecuci\u00f3n a menudo escala mal: hay que explotar los objetivos de forma repetida, manejar la variabilidad entre entornos y mantener la persistencia por cada objetivo.<\/p>\n\n<p class=\"wp-block-paragraph\">El compromiso del pipeline escala de forma eficiente: inyecta una vez, distribuye por todas partes. Si puedes modificar un paso de build, una ruta de resoluci\u00f3n de dependencias o un artefacto de release, puedes comprometer muchos sistemas mientras pareces leg\u00edtimo.<\/p>\n\n<h3 class=\"wp-block-heading\">4) La detecci\u00f3n es m\u00e1s dif\u00edcil porque \u00abtodo parece normal\u00bb<\/h3>\n\n<p class=\"wp-block-paragraph\">Las herramientas de seguridad de producci\u00f3n buscan comportamientos sospechosos en tiempo de ejecuci\u00f3n: llamadas de red inesperadas, escaladas de privilegios, procesos an\u00f3malos. Pero si el c\u00f3digo malicioso se env\u00eda como un release normal, se ejecuta como parte del comportamiento esperado de la aplicaci\u00f3n.<\/p>\n\n<p class=\"wp-block-paragraph\">Sin controles de integridad y procedencia s\u00f3lidos, los defensores pueden tener dificultades para responder:<\/p>\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\">\u00bfEs este binario\/contenedor realmente lo que pretend\u00edamos compilar?<\/p>\n<\/blockquote>\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n<h2 class=\"wp-block-heading\">Seguridad del pipeline frente a seguridad en tiempo de ejecuci\u00f3n<\/h2>\n\n<p class=\"wp-block-paragraph\">Un error com\u00fan es pensar que la seguridad del pipeline es simplemente \u00abseguridad en tiempo de ejecuci\u00f3n m\u00e1s temprano en el ciclo de vida\u00bb. Ese planteamiento es incompleto. La seguridad del pipeline y la seguridad en tiempo de ejecuci\u00f3n protegen garant\u00edas diferentes.<\/p>\n\n<h3 class=\"wp-block-heading\">La seguridad en tiempo de ejecuci\u00f3n responde:<\/h3>\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\">\u00bfQu\u00e9 est\u00e1 haciendo este sistema ahora mismo y es malicioso?<\/p>\n<\/blockquote>\n\n<h3 class=\"wp-block-heading\">La seguridad del pipeline responde:<\/h3>\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\">\u00bfPor qu\u00e9 deber\u00edamos confiar en este software en absoluto?<\/p>\n<\/blockquote>\n\n<p class=\"wp-block-paragraph\">Si el pipeline est\u00e1 comprometido, las defensas en tiempo de ejecuci\u00f3n podr\u00edan proteger fielmente una aplicaci\u00f3n maliciosa, porque desde la perspectiva del sistema es \u00abla aplicaci\u00f3n\u00bb. El verdadero fallo ocurri\u00f3 aguas arriba, en el punto donde se estableci\u00f3 la confianza.<\/p>\n\n<p class=\"wp-block-paragraph\">Por eso la seguridad de la cadena de suministro se centra en:<\/p>\n\n<ul class=\"wp-block-list\">\n<li>La integridad de las salidas del build<\/li>\n\n\n\n<li>La procedencia (qui\u00e9n\/qu\u00e9 lo construy\u00f3, d\u00f3nde y c\u00f3mo)<\/li>\n\n\n\n<li>Las puertas de verificaci\u00f3n antes del despliegue<\/li>\n\n\n\n<li>Reducir la capacidad de manipular los pasos de build y de release<\/li>\n<\/ul>\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n<h2 class=\"wp-block-heading\">D\u00f3nde son realmente vulnerables los pipelines<\/h2>\n\n<p class=\"wp-block-paragraph\">Para asegurar los pipelines, debemos ser espec\u00edficos sobre d\u00f3nde ocurren los ataques. \u00abCI\/CD\u00bb no es un \u00fanico componente. Es una cadena de componentes y transiciones de confianza. Estos son los puntos atacables m\u00e1s comunes.<\/p>\n\n<h3 class=\"wp-block-heading\">Fuente: pull requests y contribuciones no confiables<\/h3>\n\n<p class=\"wp-block-paragraph\">Muchos pipelines ejecutan c\u00f3digo procedente de pull requests. Si el pipeline trata el c\u00f3digo de un PR como confiable (o filtra secretos a los builds de PR), los atacantes pueden exfiltrar credenciales o modificar las salidas del build.<\/p>\n\n<h3 class=\"wp-block-heading\">Dependencias: confianza transitiva a escala de internet<\/h3>\n\n<p class=\"wp-block-paragraph\">Los builds modernos incorporan cientos o miles de dependencias de terceros. Una dependencia comprometida, un paquete de typosquatting o la dependency confusion pueden desplazar la ejecuci\u00f3n dentro del entorno de build, a menudo sin tocar tu c\u00f3digo fuente.<\/p>\n\n<h3 class=\"wp-block-heading\">Configuraci\u00f3n del pipeline: \u00abc\u00f3digo\u00bb que a menudo se revisa menos<\/h3>\n\n<p class=\"wp-block-paragraph\">Las definiciones de CI (workflows YAML, plantillas compartidas, actions reutilizables) controlan la ejecuci\u00f3n. Un cambio sutil puede:<\/p>\n\n<ul class=\"wp-block-list\">\n<li>Ampliar permisos<\/li>\n\n\n\n<li>Introducir exfiltraci\u00f3n de datos<\/li>\n\n\n\n<li>Cambiar las fuentes de artefactos<\/li>\n\n\n\n<li>Deshabilitar comprobaciones de seguridad<\/li>\n<\/ul>\n\n<p class=\"wp-block-paragraph\">Sin embargo, la configuraci\u00f3n de CI a veces recibe una revisi\u00f3n menos rigurosa que el c\u00f3digo de aplicaci\u00f3n.<\/p>\n\n<h3 class=\"wp-block-heading\">Runners: el entorno de ejecuci\u00f3n es una frontera de seguridad<\/h3>\n\n<p class=\"wp-block-paragraph\">Los runners alojados, los runners autoalojados y los contenedores ef\u00edmeros tienen perfiles de riesgo diferentes. Pero el punto clave es universal: los runners ejecutan entradas no confiables. Si los runners no est\u00e1n aislados correctamente, se convierten en el punto de apoyo de un atacante.<\/p>\n\n<h3 class=\"wp-block-heading\">Artefactos: la integridad y la procedencia a menudo se asumen, no se demuestran<\/h3>\n\n<p class=\"wp-block-paragraph\">Muchas organizaciones dan por sentado que \u00absi viene de CI, es seguro\u00bb. Esa es precisamente la suposici\u00f3n que los atacantes explotan. Sin firmas, atestaciones y puertas de verificaci\u00f3n, la integridad de los artefactos es fr\u00e1gil.<\/p>\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n<h2 class=\"wp-block-heading\">Errores de dise\u00f1o comunes en los pipelines<\/h2>\n\n<p class=\"wp-block-paragraph\">La mayor\u00eda de los compromisos de pipeline tienen \u00e9xito debido a errores de ingenier\u00eda predecibles, normalmente motivados por la velocidad, la comodidad o una propiedad poco clara. Estos errores crean violaciones de confianza silenciosas.<\/p>\n\n<h3 class=\"wp-block-heading\">Error n.\u00ba 1: tratar los runners de CI como \u00abinternos y de confianza\u00bb<\/h3>\n\n<p class=\"wp-block-paragraph\">Los runners a menudo se ejecutan dentro de redes de confianza y tienen acceso a recursos sensibles. Pero ejecutan c\u00f3digo que puede estar influido por colaboradores externos, dependencias o actions de terceros. Si el runner se ve comprometido, el atacante puede:<\/p>\n\n<ul class=\"wp-block-list\">\n<li>Robar secretos de las variables de entorno<\/li>\n\n\n\n<li>Extraer tokens de la configuraci\u00f3n local<\/li>\n\n\n\n<li>Modificar las salidas del build<\/li>\n\n\n\n<li>Persistir a trav\u00e9s de cach\u00e9s, im\u00e1genes o vol\u00famenes compartidos<\/li>\n<\/ul>\n\n<h3 class=\"wp-block-heading\">Error n.\u00ba 2: identidades de pipeline con privilegios excesivos<\/h3>\n\n<p class=\"wp-block-paragraph\">Los tokens amplios (por ejemplo, tokens de repositorio \u00abwrite-all\u00bb, credenciales de nube multientorno) son habituales. Facilitan la automatizaci\u00f3n, pero tambi\u00e9n dan a los atacantes una v\u00eda r\u00e1pida hacia el impacto.<\/p>\n\n<h3 class=\"wp-block-heading\">Error n.\u00ba 3: fronteras d\u00e9biles entre las etapas del pipeline<\/h3>\n\n<p class=\"wp-block-paragraph\">Si una etapa temprana puede influir en los artefactos usados por etapas posteriores sin verificaci\u00f3n de integridad, el envenenamiento de artefactos se vuelve trivial. Esto incluye:<\/p>\n\n<ul class=\"wp-block-list\">\n<li>Cach\u00e9s de build sin verificar<\/li>\n\n\n\n<li>Espacios de trabajo compartidos entre jobs<\/li>\n\n\n\n<li>Artefactos pasados entre etapas sin comprobaciones<\/li>\n<\/ul>\n\n<h3 class=\"wp-block-heading\">Error n.\u00ba 4: componentes de terceros sin controlar<\/h3>\n\n<p class=\"wp-block-paragraph\">Las actions, plugins y plantillas reutilizables son potentes. Pero tambi\u00e9n a\u00f1aden riesgo de cadena de suministro dentro del propio CI. Si los componentes de terceros no se fijan, revisan y restringen, se convierten en un vector de ejecuci\u00f3n.<\/p>\n\n<h3 class=\"wp-block-heading\">Error n.\u00ba 5: \u00abcomprobaciones de seguridad\u00bb que no controlan el despliegue<\/h3>\n\n<p class=\"wp-block-paragraph\">El escaneo de seguridad que no bloquea los releases a menudo se considera \u00absuficientemente bueno\u00bb. Desde la perspectiva de un atacante, es irrelevante. Los controles deben ser aplicables: deben afectar a lo que puede compilarse, firmarse y desplegarse.<\/p>\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n<h2 class=\"wp-block-heading\">El pipeline es una frontera de confianza<\/h2>\n\n<p class=\"wp-block-paragraph\">El modelo mental correcto no es \u00abCI\/CD como automatizaci\u00f3n\u00bb. Es <strong>CI\/CD como frontera de confianza<\/strong>.<\/p>\n\n<p class=\"wp-block-paragraph\">Una frontera de confianza es donde las entradas no confiables se convierten en salidas de confianza. Eso es exactamente lo que hace un pipeline:<\/p>\n\n<ul class=\"wp-block-list\">\n<li>Toma c\u00f3digo fuente (potencialmente influido por muchos actores)<\/li>\n\n\n\n<li>Resuelve dependencias (a menudo de ecosistemas externos)<\/li>\n\n\n\n<li>Ejecuta las instrucciones de build<\/li>\n\n\n\n<li>Produce artefactos en los que producci\u00f3n confiar\u00e1<\/li>\n<\/ul>\n\n<p class=\"wp-block-paragraph\">Si no haces expl\u00edcita la confianza, obtienes confianza impl\u00edcita. La confianza impl\u00edcita es lo que los atacantes monetizan.<\/p>\n\n<p class=\"wp-block-paragraph\">Dise\u00f1ar el pipeline como una frontera de confianza significa:<\/p>\n\n<ul class=\"wp-block-list\">\n<li><strong>Fronteras de etapa expl\u00edcitas<\/strong> con aislamiento y verificaci\u00f3n entre ellas<\/li>\n\n\n\n<li><strong>M\u00ednimo privilegio<\/strong> para las identidades del pipeline, por job y por entorno<\/li>\n\n\n\n<li><strong>Ejecuci\u00f3n ef\u00edmera<\/strong> (o aislamiento fuerte) para los runners y los builds<\/li>\n\n\n\n<li><strong>Integridad criptogr\u00e1fica<\/strong> para los artefactos (firma y verificaci\u00f3n)<\/li>\n\n\n\n<li><strong>Procedencia<\/strong> y atestaciones que puedan validarse en el momento del despliegue<\/li>\n<\/ul>\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n<h2 class=\"wp-block-heading\">Qu\u00e9 deber\u00eda incluir una estrategia de seguridad moderna<\/h2>\n\n<p class=\"wp-block-paragraph\">Si los pipelines son superficies de ataque principales, los programas de seguridad deben invertir en consecuencia. No a\u00f1adiendo m\u00e1s \u00abcomprobaciones\u00bb, sino incorporando garant\u00edas s\u00f3lidas al proceso de entrega.<\/p>\n\n<h3 class=\"wp-block-heading\">1) Modela las amenazas del pipeline (no solo de la aplicaci\u00f3n)<\/h3>\n\n<p class=\"wp-block-paragraph\">Mapea las fronteras de confianza: entradas de PR, resoluci\u00f3n de dependencias, runners, almacenamiento de artefactos, firma y despliegue. Identifica d\u00f3nde puede entrar la influencia no confiable.<\/p>\n\n<h3 class=\"wp-block-heading\">2) Reduce el privilegio y el alcance de forma agresiva<\/h3>\n\n<p class=\"wp-block-paragraph\">Usa identidades delimitadas por job, credenciales delimitadas por entorno, tokens de corta vida y fronteras de permisos expl\u00edcitas. Evita los \u00absuperusuarios del pipeline\u00bb.<\/p>\n\n<h3 class=\"wp-block-heading\">3) Endurece los runners y los entornos de ejecuci\u00f3n<\/h3>\n\n<p class=\"wp-block-paragraph\">Prefiere los runners ef\u00edmeros siempre que sea posible. Si usas runners autoalojados, a\u00edslalos: restricciones de red, controles del sistema de archivos, sin estado compartido de larga vida y una segregaci\u00f3n estricta entre las cargas de trabajo no confiables y las de confianza.<\/p>\n\n<h3 class=\"wp-block-heading\">4) Haz que la integridad sea verificable, no asumida<\/h3>\n\n<p class=\"wp-block-paragraph\">Firma los artefactos, genera atestaciones y verif\u00edcalas antes del despliegue. Aseg\u00farate de que producci\u00f3n conf\u00ede en la <em>verificaci\u00f3n<\/em>, no meramente en el hecho de que \u00ablo produjo CI\u00bb.<\/p>\n\n<h3 class=\"wp-block-heading\">5) Valida los cambios del pipeline como cambios de producci\u00f3n<\/h3>\n\n<p class=\"wp-block-paragraph\">Trata la configuraci\u00f3n de CI como c\u00f3digo de alto riesgo. Usa code owners, revisiones y aplicaci\u00f3n de pol\u00edticas para evitar la ampliaci\u00f3n silenciosa de privilegios o la inyecci\u00f3n de pasos no confiables.<\/p>\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n<h2 class=\"wp-block-heading\">Conclusi\u00f3n<\/h2>\n\n<p class=\"wp-block-paragraph\">Los pipelines CI\/CD se han convertido silenciosamente en algunos de los componentes m\u00e1s cr\u00edticos \u2014y m\u00e1s explotados\u2014 de los ecosistemas de software modernos. Agregan confianza, operan con privilegios elevados y proporcionan a los atacantes una v\u00eda de gran apalancamiento hacia el impacto a escala.<\/p>\n\n<p class=\"wp-block-paragraph\">El paso m\u00e1s importante es cambiar el modelo mental:<\/p>\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\">Un pipeline CI\/CD no es \u00absolo automatizaci\u00f3n\u00bb. Es una frontera de confianza.<\/p>\n<\/blockquote>\n\n<p class=\"wp-block-paragraph\">Las organizaciones que dise\u00f1en sus pipelines con fronteras de confianza expl\u00edcitas \u2014mediante aislamiento, m\u00ednimo privilegio, integridad y procedencia\u2014 estar\u00e1n en una posici\u00f3n mucho mejor para defenderse de la pr\u00f3xima generaci\u00f3n de ataques a la cadena de suministro de software.<\/p>\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\r\n    <div class=\"secure-pipelines-author-box\" >\r\n        <strong>Sobre el autor<\/strong>\r\n        <p>Este art\u00edculo est\u00e1 escrito por un arquitecto senior de seguridad y DevSecOps, con m\u00e1s de 15 a\u00f1os de experiencia en ingenier\u00eda de software y seguridad de aplicaciones. El contenido refleja un enfoque pragm\u00e1tico, basado en restricciones reales y pr\u00e1cticas de ingenier\u00eda probadas.<\/p>\r\n    <\/div>\r\n\r\n    \n\n<script type=\"application\/ld+json\">\n{\n  \"@context\": \"https:\/\/schema.org\",\n  \"@type\": \"FAQPage\",\n  \"mainEntity\": [\n    {\n      \"@type\": \"Question\",\n      \"name\": \"\u00bfPor qu\u00e9 son los pipelines CI\/CD una superficie de ataque importante?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"Los pipelines CI\/CD agregan confianza, operan con privilegios elevados y distribuyen software a escala. Comprometer un pipeline permite a los atacantes inyectar c\u00f3digo malicioso antes del despliegue, eludiendo muchas defensas en tiempo de ejecuci\u00f3n.\"\n      }\n    },\n    {\n      \"@type\": \"Question\",\n      \"name\": \"\u00bfEn qu\u00e9 se diferencia la seguridad del pipeline de la seguridad en tiempo de ejecuci\u00f3n?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"La seguridad en tiempo de ejecuci\u00f3n se centra en detectar comportamientos maliciosos despu\u00e9s del despliegue, mientras que la seguridad del pipeline se centra en garantizar que el software que se compila y entrega sea digno de confianza desde el principio.\"\n      }\n    },\n    {\n      \"@type\": \"Question\",\n      \"name\": \"\u00bfCu\u00e1les son los errores de seguridad comunes en los pipelines CI\/CD?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"Los errores comunes incluyen identidades de pipeline con privilegios excesivos, un aislamiento d\u00e9bil de los runners, actions de terceros sin verificar, la falta de comprobaciones de integridad de los artefactos y una revisi\u00f3n insuficiente de los cambios en la configuraci\u00f3n CI\/CD.\"\n      }\n    },\n    {\n      \"@type\": \"Question\",\n      \"name\": \"\u00bfC\u00f3mo pueden las organizaciones asegurar sus pipelines CI\/CD?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"Las organizaciones deber\u00edan tratar los pipelines como fronteras de confianza, aplicar el m\u00ednimo privilegio a las identidades del pipeline, aislar los entornos de build, firmar y verificar los artefactos y validar los cambios en la configuraci\u00f3n del pipeline.\"\n      }\n    }\n  ]\n}\n<\/script>\n","protected":false},"excerpt":{"rendered":"<p>Durante a\u00f1os, los programas de seguridad de aplicaciones se han centrado en los entornos de producci\u00f3n: endurecer servidores, parchear vulnerabilidades, desplegar WAFs y monitorizar el comportamiento en tiempo de ejecuci\u00f3n. Ese enfoque ten\u00eda sentido cuando la mayor\u00eda de los compromisos relevantes ocurr\u00edan despu\u00e9s del despliegue, explotando debilidades en las aplicaciones en ejecuci\u00f3n. Pero los atacantes &#8230; <a title=\"Por qu\u00e9 los pipelines CI\/CD son la nueva superficie de ataque principal\" class=\"read-more\" href=\"https:\/\/secure-pipelines.com\/es\/threats-attacks\/ci-cd-pipelines-primary-attack-surface\/\" aria-label=\"Leer m\u00e1s sobre Por qu\u00e9 los pipelines CI\/CD son la nueva superficie de ataque principal\">Leer m\u00e1s<\/a><\/p>\n","protected":false},"author":1,"featured_media":1412,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[60,55],"tags":[],"post_folder":[],"class_list":["post-713","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-threats-attacks","category-ci-cd-security"],"_links":{"self":[{"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts\/713","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=713"}],"version-history":[{"count":5,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts\/713\/revisions"}],"predecessor-version":[{"id":1594,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts\/713\/revisions\/1594"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/media\/1412"}],"wp:attachment":[{"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/media?parent=713"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/categories?post=713"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/tags?post=713"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/post_folder?post=713"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}