Los expertos en seguridad de código abierto dicen que la reciente vulnerabilidad de ejecución remota de código (RCE) de GitHub, CVE-2026-3854, puede haber sido parcheada, pero expone un problema mayor: la confianza implícita en la cadena de suministro de software.
Esta vulnerabilidad no es un caso aislado. Algunos expertos en seguridad ven esto como una señal de advertencia de una ruptura en la confianza basada en el perímetro. Sirve como un caso de estudio de por qué identidad no es igual a integridad. Saber quién firmó un paquete no significa necesariamente saber qué contiene el paquete.
GitHub, una plataforma de desarrollo basada en la nube y red social para programadores, sufrió una falla crítica de inyección de comandos que permitía a cualquier usuario autenticado ejecutar código arbitrario en sus servidores backend usando un solo comando git push.
Ken Ammon, director ejecutivo cazador de códigosdescribiéndola como una vulnerabilidad de inyección clásica que convierte las operaciones rutinarias del desarrollador en una vulnerabilidad de «Modo Dios». Aunque parcheado, lo ve como un ejemplo de libro de texto de cómo la confianza implícita en las comunicaciones internas puede crear enormes agujeros de seguridad.
«Esto no es sólo un error de GitHub. Es una falla de confianza implícita. Un usuario autenticado emite un comando de rutina y los sistemas posteriores tratan esa entrada como autorizada», dijo a LinuxInsider.
La confianza por sí sola ya no funciona
Amon advirtió que los controles de seguridad verifican quién inició una acción pero no qué hará la acción.
Durante la última década, la industria se ha centrado en el “quién” de la seguridad: autenticación multifactor, gestión de identidades y claves de hardware. GitHub RCE (CVE-2026-3854) demuestra que estamos entrando en una era en la que la identidad importa menos si las organizaciones no pueden cuestionar «qué».
Amon dijo que el incidente pone de relieve un cambio más amplio en la forma en que las empresas deben pensar sobre la confianza en el software.
«Construimos una cadena de suministro de software que asume que las plataformas confiables generan código confiable. CVE-2026-3854 desafía esta suposición. Si los sistemas centrales como GitHub pueden usarse como vector de ataque, la procedencia por sí sola ya no es una señal de confianza suficiente».
El equipo de seguridad aprendió por la puerta trasera XZ que los contribuyentes confiables no garantizan la seguridad del código. «Este nuevo CVE va un paso más allá: una infraestructura confiable no puede garantizar un código seguro», explicó.
La industria de la seguridad debe cambiar de enfoque
Amon está de acuerdo en que la identidad sigue siendo necesaria. Sin embargo, no es suficiente por sí solo. Indica quién impulsó el código, no si se debe confiar en que se ejecute el código y las acciones que puede desencadenar.
La seguridad empresarial debe pasar de la identificación a la intención. La pregunta no puede ser simplemente «¿Hemos visto esto antes?» Tiene que convertirse en «¿Qué hace este código?»
Como parte de un enfoque de confianza cero en el código, dijo, la evaluación debe ocurrir antes de la ejecución, no después.
Preguntas y respuestas: ¿Por qué la identidad por sí sola ya no funciona?
Le preguntamos a Ammon por qué se está rompiendo la confianza implícita en los sistemas CI/CD y cómo las empresas pueden mejorar la seguridad de la cadena de suministro de software.
Sus comentarios abordaron las limitaciones de la identidad, la procedencia y las firmas como señales de confianza, y cómo podría verse en la práctica un modelo de confianza cero para el código.
LinuxInsider: ¿Cómo cambiará este incidente la forma en que las empresas ven a los usuarios confiables?
Ken Amón: Nos obliga a separar la identidad de la intención. Los usuarios confiables pueden autenticarse, autorizar y operar a través de sesiones legítimas, pero esto no significa que los usuarios intermedios deban confiar en cada comando que emitan.
Los entornos de desarrollo modernos están altamente automatizados. Un solo comando puede desencadenar compilaciones, ejecutores, extracciones de dependencias, implementaciones o integraciones en múltiples sistemas. Esto significa que los usuarios son sólo una parte de la decisión de confianza. La seguridad también debe evaluar qué provocará la acción que hagan otros sistemas.
¿Están obsoletos los perímetros de seguridad en la cadena de suministro de software moderna?
Amón: El perímetro no está obsoleto, pero ya no es suficiente. La cadena de suministro de software ya no tiene límites claros. Es una red de desarrolladores, repositorios, sistemas CI/CD, administradores de paquetes, ejecutores, servicios en la nube e integraciones de terceros.
En este entorno, los atacantes no siempre necesitan entrar por la puerta principal. Pueden abusar de lo que ya está en el flujo de trabajo: sesiones autenticadas, repositorios confiables, paquetes firmados o bots.
El modelo antiguo decía: «Esto proviene de un usuario confiable, así que adelante». El modelo más seguro dice: «Esto proviene de un usuario confiable, pero ¿qué puede desencadenar esta acción? ¿Está permitido este comportamiento?».
¿Este incidente socava su procedencia como señal de confianza?
Amón: Creo que está más bien incompleto que equivocado. La procedencia te dice de dónde vino algo y cómo pasó por el proceso. Esto es útil. Pero no le dice si la operación o artefacto resultante es seguro de realizar.
Esta es la misma lección que vimos de manera más amplia con la puerta trasera XZ. Los colaboradores confiables no garantizan la seguridad del código. En este caso, la infraestructura confiable y las operaciones autenticadas no garantizan un comportamiento seguro. La procedencia es necesaria para la rendición de cuentas, pero no es la señal definitiva de confianza.
¿Cómo superamos la pregunta «¿Quién firmó esto?» a «¿Es realmente seguro?»
Amón: Debemos tratar las firmas como señales de autenticidad, no de seguridad. Una firma demuestra que algo proviene de una determinada identidad o proceso. No prueba que el código firmado sea benigno.
El siguiente paso es la verificación del comportamiento. Antes de ejecutar el código, la organización debe preguntarse qué puede hacer: ¿puede generar procesos? ¿Tiene acceso a Internet? ¿Modificar credenciales? ¿Desarrollar persistencia? ¿Elevar privilegios? ¿Movimiento lateral?
¿Por qué la confianza implícita entre plataformas y operadores de CI es el eslabón más débil hoy en día?
Amón: La automatización puede convertir rápidamente la confianza en acción. GitHub, ejecutores de CI, administradores de paquetes y herramientas de implementación escuchan eventos y ejecutan instrucciones. Si bien es eficiente, también crea una suposición peligrosa: si un evento se origina en una plataforma confiable, los sistemas posteriores deberían actuar en consecuencia.
Los atacantes explotan esta suposición. No siempre es necesario que comprometan todos los sistemas de la cadena. Solo necesitan manipular una entrada confiable que otras herramientas consideran autorizada.
Esta es la razón por la que la confianza implícita es tan peligrosa en CI/CD. La debilidad no es sólo la vulnerabilidad original. Luego viene la cascada de ejecución confiable.
¿Cuál es la diferencia entre la confianza cero tradicional y el código de confianza cero?
Amón: La confianza cero tradicional se centra en los usuarios, los dispositivos, las redes y el acceso. Pregunta si se debe permitir que la identidad acceda al recurso. La confianza cero en el código aplica las mismas reglas a la ejecución del software. Pregunta si se debe permitir la ejecución del artefacto de software.
Esta distinción es importante porque el código del programa también ejerce privilegios. Una vez que se ejecuta el software, puede acceder a archivos, llamar a API, modificar el sistema, llamar a otros procesos o mover datos. Si exigimos que los usuarios demuestren confianza antes del acceso, deberíamos exigir que el código demuestre confianza en el comportamiento antes de la ejecución.
¿Cómo pueden las empresas verificar la intención del código en tiempo real?
Amón: La estrella del norte debería ser la confianza en la ejecución: el porcentaje de artefactos de software cuyo comportamiento se verifica antes de permitir su ejecución. Las empresas necesitan tomar decisiones de confianza en tiempo real sobre su código, similares a sus expectativas de identidad y acceso.
El control debe responder claramente a una pregunta: según su funcionalidad, ¿se permite ejecutar este artefacto en este entorno? Esto requiere análisis de intención de comportamiento, ejecución de políticas deterministas y auditabilidad. Si se permite que el código se ejecute antes de que se comprenda, entonces las decisiones de confianza se toman de forma predeterminada.
