{"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-03-25T06:50:40","modified_gmt":"2026-03-25T05:50:40","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":"

Durante a\u00f1os, los programas de seguridad de aplicaciones se han centrado en los entornos de producci\u00f3n: fortalecer 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 significativos ocurr\u00edan despu\u00e9s<\/em> del despliegue, al explotar debilidades en las aplicaciones en ejecuci\u00f3n.<\/p>\n

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 construyen<\/strong>, empaquetan<\/strong> y entregan<\/strong> el software: los pipelines CI\/CD y la software supply chain que los respalda.<\/p>\n

En muchas organizaciones, los pipelines CI\/CD son ahora un objetivo m\u00e1s valioso y m\u00e1s fr\u00e1gil que la propia producci\u00f3n. La raz\u00f3n es simple: 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\u2014y lo que llega a los usuarios.<\/p>\n

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 supply chain, c\u00f3mo la seguridad de pipelines difiere de la seguridad en tiempo de ejecuci\u00f3n, y qu\u00e9 errores de dise\u00f1o comunes mantienen vulnerables a los pipelines. La conclusi\u00f3n es clara: el pipeline es un l\u00edmite de confianza<\/strong>, y debe ser dise\u00f1ado como tal.<\/p>\n

\n

La evoluci\u00f3n de los ataques al software<\/h2>\n

Las amenazas cl\u00e1sicas a la seguridad de aplicaciones se dirig\u00edan a vulnerabilidades en tiempo de ejecuci\u00f3n: SQL injection, RCE, SSRF, auth bypass y escalada de privilegios. Los defensores han dedicado dos d\u00e9cadas a aumentar el coste de estos ataques mediante:<\/p>\n

    \n
  • Mejoras en el parcheo, el escaneo de dependencias y la gesti\u00f3n de vulnerabilidades<\/li>\n
  • Controles de seguridad cloud-native e infraestructura gestionada<\/li>\n
  • Mejor aislamiento (contenedores, sandboxes, segmentaci\u00f3n)<\/li>\n
  • Capacidades centralizadas de logging y detecci\u00f3n<\/li>\n<\/ul>\n

    Como resultado, los adversarios se adaptaron. Si la producci\u00f3n se vuelve m\u00e1s dif\u00edcil de explotar directamente, los atacantes buscan ventaja en otro lugar\u2014y el proceso de entrega de software ofrece esa ventaja.<\/p>\n

    En lugar de preguntar \u201c\u00bfC\u00f3mo puedo entrar en este sistema en ejecuci\u00f3n?\u201d, los atacantes preguntan cada vez m\u00e1s:<\/p>\n

    \n

    \u00bfC\u00f3mo puedo hacer que mi c\u00f3digo se distribuya como si fuera leg\u00edtimo?<\/p>\n<\/blockquote>\n

    Cuando eso sucede, las defensas dise\u00f1adas para compromisos en tiempo de ejecuci\u00f3n pueden volverse irrelevantes. Una actualizaci\u00f3n maliciosa entregada a trav\u00e9s de canales leg\u00edtimos no es una \u201cbrecha\u201d en el sentido tradicional\u2014 puede parecer una operaci\u00f3n normal del negocio.<\/p>\n

    \n

    Tres incidentes que ilustran el cambio<\/h2>\n

    Los incidentes de supply chain de alto perfil 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 producci\u00f3n. Los detalles difieren, pero el patr\u00f3n es consistente: comprometer un paso de construcci\u00f3n o distribuci\u00f3n confiable, y heredas la confianza a escala.<\/p>\n

    SolarWinds: comprometer el build y alcanzar a todos<\/h3>\n

    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\u2014fue la capacidad de distribuir software con backdoor a trav\u00e9s de un canal de actualizaci\u00f3n confiable.<\/p>\n

    El ROI del atacante fue masivo: comprometer el pipeline de build o release una vez, y luego dejar que los clientes instalen tu payload por ti.<\/p>\n

    Codecov: comprometer las herramientas de CI y robar secretos a escala<\/h3>\n

    En el incidente de Codecov, un compromiso afect\u00f3 la forma en que los entornos de CI manejaban un script. El impacto pr\u00e1ctico: los sistemas CI que se ejecutaban en muchas organizaciones filtraron informaci\u00f3n sensible.<\/p>\n

    Los entornos de CI son extremadamente sensibles porque com\u00fanmente contienen:<\/p>\n

      \n
    • Tokens de repositorios<\/li>\n
    • Credenciales de la nube<\/li>\n
    • Claves de firma o acceso a servicios de firma<\/li>\n
    • Secretos de despliegue<\/li>\n<\/ul>\n

      Este incidente destaca que las herramientas de CI no son \u201csolo automatizaci\u00f3n\u201d\u2014son un sistema de procesamiento de secretos de alto valor.<\/p>\n

      3CX: comprometer un proveedor y convertir la confianza en arma<\/h3>\n

      El incidente de 3CX demostr\u00f3 otra din\u00e1mica de supply chain: comprometer un proveedor y convertir la confianza en arma para distribuir software malicioso a los clientes downstream.<\/p>\n

      Desde el punto de vista de la defensa, la lecci\u00f3n no se limita a los proveedores. Internamente, tu pipeline CI\/CD es efectivamente un \u201cproveedor\u201d para tu entorno de producci\u00f3n y para tus usuarios: producci\u00f3n conf\u00eda en las salidas del pipeline.<\/p>\n

      \n

      Por qu\u00e9 el pipeline es m\u00e1s atractivo que producci\u00f3n<\/h2>\n

      Los atacantes eligen objetivos basados en el apalancamiento. Los pipelines CI\/CD ofrecen un apalancamiento que los sistemas de producci\u00f3n rara vez igualan.<\/p>\n

      1) Los pipelines agregan confianza<\/h3>\n

      Un pipeline es el tejido conectivo entre:<\/p>\n

        \n
      • Repositorios de c\u00f3digo fuente (Git)<\/li>\n
      • Registros de dependencias (npm, PyPI, Maven, etc.)<\/li>\n
      • Sistemas de build y runners<\/li>\n
      • Repositorios de artefactos (registros de contenedores, repos de paquetes)<\/li>\n
      • Sistemas de firma y metadatos de provenance<\/li>\n
      • Objetivos de despliegue (Kubernetes, cuentas cloud, servidores de producci\u00f3n)<\/li>\n<\/ul>\n

        Comprometer producci\u00f3n generalmente te da acceso a un<\/em> entorno. Comprometer el pipeline puede darte:<\/p>\n

          \n
        • Acceso a m\u00faltiples entornos a trav\u00e9s de credenciales de automatizaci\u00f3n<\/li>\n
        • Control sobre los artefactos de release<\/li>\n
        • Influencia sobre lo que se despliega y cu\u00e1ndo<\/li>\n<\/ul>\n

          Los pipelines son \u201cmultiplicadores de confianza\u201d: pueden tomar entradas no confiables y producir salidas confiables. Si los atacantes controlan esa transformaci\u00f3n, controlan la confianza.<\/p>\n

          2) Los pipelines operan con altos privilegios por dise\u00f1o<\/h3>\n

          La automatizaci\u00f3n necesita privilegios. Los pipelines a menudo requieren permisos para:<\/p>\n

            \n
          • Leer y escribir en repositorios (incluyendo tags y releases)<\/li>\n
          • Descargar dependencias y publicar artefactos<\/li>\n
          • Acceder a secretos para firma o despliegue<\/li>\n
          • Desplegar en staging o producci\u00f3n<\/li>\n<\/ul>\n

            En muchas organizaciones, las identidades de los pipelines se convierten en \u201csuperidentidades\u201d con el tiempo, porque es m\u00e1s f\u00e1cil otorgar acceso amplio que dise\u00f1ar permisos granulares.<\/p>\n

            Esto crea una estrategia predecible para los atacantes: comprometer la identidad del pipeline en lugar de luchar contra las defensas de producci\u00f3n.<\/p>\n

            3) El compromiso de pipelines escala mejor<\/h3>\n

            El compromiso en tiempo de ejecuci\u00f3n a menudo escala mal: debes explotar objetivos repetidamente, manejar la variabilidad entre entornos y mantener la persistencia por objetivo.<\/p>\n

            El compromiso de pipelines escala eficientemente: inyectar una vez, distribuir a 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

            4) La detecci\u00f3n es m\u00e1s dif\u00edcil porque \u201ctodo parece normal\u201d<\/h3>\n

            Las herramientas de seguridad de producci\u00f3n buscan comportamiento sospechoso en tiempo de ejecuci\u00f3n: llamadas de red inesperadas, escaladas de privilegios, procesos anormales. Pero si el c\u00f3digo malicioso se distribuye como un release normal, se ejecuta como parte del comportamiento esperado de la aplicaci\u00f3n.<\/p>\n

            Sin controles de integridad s\u00f3lidos y provenance, los defensores pueden tener dificultades para responder:<\/p>\n

            \n

            \u00bfEste binario\/contenedor es realmente lo que pretend\u00edamos construir?<\/p>\n<\/blockquote>\n

            \n

            Seguridad de pipelines vs seguridad en tiempo de ejecuci\u00f3n<\/h2>\n

            Un error com\u00fan es pensar que la seguridad de pipelines es simplemente \u201cseguridad en tiempo de ejecuci\u00f3n aplicada m\u00e1s temprano en el ciclo de vida.\u201d Ese enfoque es incompleto. La seguridad de pipelines y la seguridad en tiempo de ejecuci\u00f3n protegen garant\u00edas diferentes.<\/p>\n

            La seguridad en tiempo de ejecuci\u00f3n responde:<\/h3>\n
            \n

            \u00bfQu\u00e9 est\u00e1 haciendo este sistema ahora mismo, y es malicioso?<\/p>\n<\/blockquote>\n

            La seguridad de pipelines responde:<\/h3>\n
            \n

            \u00bfPor qu\u00e9 deber\u00edamos confiar en este software en primer lugar?<\/p>\n<\/blockquote>\n

            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 \u201cla aplicaci\u00f3n.\u201d El verdadero fallo ocurri\u00f3 aguas arriba, en el punto donde se estableci\u00f3 la confianza.<\/p>\n

            Es por esto que la seguridad de supply chain se centra en:<\/p>\n

              \n
            • Integridad de las salidas del build<\/li>\n
            • Provenance (qui\u00e9n\/qu\u00e9 lo construy\u00f3, d\u00f3nde y c\u00f3mo)<\/li>\n
            • Puertas de verificaci\u00f3n antes del despliegue<\/li>\n
            • Reducir la capacidad de manipular los pasos de build y release<\/li>\n<\/ul>\n
              \n

              D\u00f3nde son realmente vulnerables los pipelines<\/h2>\n

              Para asegurar los pipelines, debemos ser espec\u00edficos sobre d\u00f3nde ocurren los ataques. \u201cCI\/CD\u201d no es un solo componente. Es una cadena de componentes y transiciones de confianza. Estos son los puntos de ataque m\u00e1s comunes.<\/p>\n

              C\u00f3digo fuente: pull requests y contribuciones no confiables<\/h3>\n

              Muchos pipelines ejecutan c\u00f3digo de pull requests. Si el pipeline trata el c\u00f3digo del PR como confiable (o filtra secretos a los builds de PR), los atacantes pueden exfiltrar credenciales o modificar las salidas del build.<\/p>\n

              Dependencias: confianza transitiva a escala de internet<\/h3>\n

              Los builds modernos descargan cientos o miles de dependencias de terceros. Una dependencia comprometida, un paquete de typosquatting o dependency confusion pueden desviar la ejecuci\u00f3n dentro del entorno de build\u2014a menudo sin tocar tu c\u00f3digo fuente.<\/p>\n

              Configuraci\u00f3n del pipeline: \u201cc\u00f3digo\u201d que a menudo se revisa menos<\/h3>\n

              Las definiciones de CI (workflows YAML, templates compartidos, acciones reutilizables) controlan la ejecuci\u00f3n. Un cambio sutil puede:<\/p>\n

                \n
              • Expandir permisos<\/li>\n
              • Introducir exfiltraci\u00f3n de datos<\/li>\n
              • Cambiar las fuentes de artefactos<\/li>\n
              • Desactivar verificaciones de seguridad<\/li>\n<\/ul>\n

                Sin embargo, la configuraci\u00f3n de CI a veces recibe una revisi\u00f3n menos rigurosa que el c\u00f3digo de la aplicaci\u00f3n.<\/p>\n

                Runners: el entorno de ejecuci\u00f3n es un l\u00edmite de seguridad<\/h3>\n

                Los runners alojados, los runners self-hosted y los contenedores ef\u00edmeros tienen todos perfiles de riesgo diferentes. Pero el punto clave es universal: los runners ejecutan entradas no confiables. Si los runners no est\u00e1n aislados adecuadamente, se convierten en un punto de apoyo para el atacante.<\/p>\n

                Artefactos: la integridad y el provenance a menudo se asumen, no se demuestran<\/h3>\n

                Muchas organizaciones asumen que \u201csi vino de CI, es seguro.\u201d Esa es precisamente la suposici\u00f3n que explotan los atacantes. Sin firmas, attestations y puertas de verificaci\u00f3n, la integridad de los artefactos es fr\u00e1gil.<\/p>\n

                \n

                Errores comunes en el dise\u00f1o de pipelines<\/h2>\n

                La mayor\u00eda de los compromisos de pipelines tienen \u00e9xito debido a errores de ingenier\u00eda predecibles\u2014generalmente impulsados por la velocidad, la conveniencia o la falta de claridad en la propiedad. Estos errores crean violaciones de confianza silenciosas.<\/p>\n

                Error #1: Tratar los runners de CI como \u201cinternos y confiables\u201d<\/h3>\n

                Los runners a menudo se ejecutan dentro de redes confiables y tienen acceso a recursos sensibles. Pero ejecutan c\u00f3digo que puede estar influenciado por contribuidores externos, dependencias o acciones de terceros. Si el runner est\u00e1 comprometido, el atacante puede:<\/p>\n

                  \n
                • Robar secretos de las variables de entorno<\/li>\n
                • Extraer tokens de la configuraci\u00f3n local<\/li>\n
                • Modificar las salidas del build<\/li>\n
                • Persistir a trav\u00e9s de cach\u00e9s, im\u00e1genes o vol\u00famenes compartidos<\/li>\n<\/ul>\n

                  Error #2: Identidades de pipeline con exceso de privilegios<\/h3>\n

                  Los tokens amplios (por ejemplo, tokens de repositorio \u201cwrite-all\u201d, credenciales cloud multi-entorno) son comunes. Facilitan la automatizaci\u00f3n\u2014pero tambi\u00e9n dan a los atacantes un camino r\u00e1pido hacia el impacto.<\/p>\n

                  Error #3: L\u00edmites d\u00e9biles entre las etapas del pipeline<\/h3>\n

                  Si una etapa temprana puede influir en los artefactos utilizados por etapas posteriores sin verificaci\u00f3n de integridad, el envenenamiento de artefactos se vuelve trivial. Esto incluye:<\/p>\n

                    \n
                  • Cach\u00e9s de build no verificadas<\/li>\n
                  • Espacios de trabajo compartidos entre jobs<\/li>\n
                  • Artefactos pasados entre etapas sin verificaciones<\/li>\n<\/ul>\n

                    Error #4: Componentes de terceros sin control<\/h3>\n

                    Las acciones reutilizables, plugins y templates son poderosos. Pero tambi\u00e9n a\u00f1aden riesgo de supply chain dentro del propio CI. Si los componentes de terceros no est\u00e1n fijados, revisados y restringidos, se convierten en un vector de ejecuci\u00f3n.<\/p>\n

                    Error #5: \u201cVerificaciones de seguridad\u201d que no bloquean el despliegue<\/h3>\n

                    El escaneo de seguridad que no bloquea los releases a menudo se trata como \u201csuficiente.\u201d Desde la perspectiva del atacante, es irrelevante. Los controles deben ser aplicables: deben afectar lo que se puede construir, firmar y desplegar.<\/p>\n

                    \n

                    El pipeline es un l\u00edmite de confianza<\/h2>\n

                    El modelo mental correcto no es \u201cCI\/CD como automatizaci\u00f3n.\u201d Es CI\/CD como un l\u00edmite de confianza<\/strong>.<\/p>\n

                    Un l\u00edmite de confianza es donde las entradas no confiables se convierten en salidas confiables. Eso es exactamente lo que hace un pipeline:<\/p>\n

                      \n
                    • Toma c\u00f3digo fuente (potencialmente influenciado por muchos actores)<\/li>\n
                    • Resuelve dependencias (a menudo de ecosistemas externos)<\/li>\n
                    • Ejecuta instrucciones de build<\/li>\n
                    • Produce artefactos en los que producci\u00f3n confiar\u00e1<\/li>\n<\/ul>\n

                      Si no haces la confianza expl\u00edcita, obtienes confianza impl\u00edcita. La confianza impl\u00edcita es lo que los atacantes monetizan.<\/p>\n

                      Dise\u00f1ar el pipeline como un l\u00edmite de confianza significa:<\/p>\n

                        \n
                      • L\u00edmites de etapa expl\u00edcitos<\/strong> con aislamiento y verificaci\u00f3n entre ellos<\/li>\n
                      • Privilegio m\u00ednimo<\/strong> para las identidades del pipeline, por job y por entorno<\/li>\n
                      • Ejecuci\u00f3n ef\u00edmera<\/strong> (o aislamiento fuerte) para runners y builds<\/li>\n
                      • Integridad criptogr\u00e1fica<\/strong> para artefactos (firma y verificaci\u00f3n)<\/li>\n
                      • Provenance<\/strong> y attestations que puedan ser validadas en el momento del despliegue<\/li>\n<\/ul>\n
                        \n

                        Qu\u00e9 debe incluir una estrategia de seguridad moderna<\/h2>\n

                        Si los pipelines son superficies de ataque principales, los programas de seguridad deben invertir en consecuencia. No a\u00f1adiendo m\u00e1s \u201cverificaciones,\u201d sino construyendo garant\u00edas s\u00f3lidas en el proceso de entrega.<\/p>\n

                        1) Modelar las amenazas del pipeline (no solo de la aplicaci\u00f3n)<\/h3>\n

                        Mapear los l\u00edmites de confianza: entradas de PR, resoluci\u00f3n de dependencias, runners, almacenamiento de artefactos, firma y despliegue. Identificar d\u00f3nde puede entrar influencia no confiable.<\/p>\n

                        2) Reducir privilegios y alcance de forma agresiva<\/h3>\n

                        Usar identidades con alcance por job, credenciales con alcance por entorno, tokens de corta duraci\u00f3n y l\u00edmites de permisos expl\u00edcitos. Evitar los \u201csuperusuarios de pipeline.\u201d<\/p>\n

                        3) Fortalecer los runners y los entornos de ejecuci\u00f3n<\/h3>\n

                        Preferir runners ef\u00edmeros cuando sea posible. Si se usan runners self-hosted, aislarlos: restricciones de red, controles de sistema de archivos, sin estado compartido de larga duraci\u00f3n, y segregaci\u00f3n estricta entre cargas de trabajo confiables y no confiables.<\/p>\n

                        4) Hacer que la integridad sea verificable, no asumida<\/h3>\n

                        Firmar artefactos, generar attestations y verificarlos antes del despliegue. Asegurar que producci\u00f3n conf\u00ede en la verificaci\u00f3n<\/em>, no simplemente en el hecho de que \u201cCI lo produjo.\u201d<\/p>\n

                        5) Validar los cambios de pipeline como cambios de producci\u00f3n<\/h3>\n

                        Tratar la configuraci\u00f3n de CI como c\u00f3digo de alto riesgo. Usar code owners, revisiones y aplicaci\u00f3n de pol\u00edticas para prevenir la expansi\u00f3n silenciosa de privilegios o la inyecci\u00f3n de pasos no confiables.<\/p>\n

                        \n

                        Conclusi\u00f3n<\/h2>\n

                        Los pipelines CI\/CD se han convertido silenciosamente en algunos de los componentes m\u00e1s cr\u00edticos\u2014y m\u00e1s explotados\u2014de los ecosistemas de software modernos. Agregan confianza, operan con altos privilegios y proporcionan a los atacantes un camino de alto apalancamiento para lograr impacto a escala.<\/p>\n

                        El paso m\u00e1s importante es cambiar el modelo mental:<\/p>\n

                        \n

                        Un pipeline CI\/CD no es \u201csolo automatizaci\u00f3n.\u201d Es un l\u00edmite de confianza.<\/p>\n<\/blockquote>\n

                        Las organizaciones que dise\u00f1en pipelines con l\u00edmites de confianza expl\u00edcitos\u2014a trav\u00e9s de aislamiento, privilegio m\u00ednimo, integridad y provenance\u2014estar\u00e1n en una posici\u00f3n mucho mejor para defenderse contra la pr\u00f3xima generaci\u00f3n de ataques a la software supply chain.<\/p>\n

                        \n
                        \n Sobre el autor<\/strong><\/p>\n

                        Este art\u00edculo est\u00e1 escrito por un arquitecto senior de DevSecOps y seguridad 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, orientado a la ingenier\u00eda, basado en restricciones del mundo real.<\/p>\n<\/p><\/div>\n