Fugas de código fuente: Los atacantes conocen al proveedor de seguridad antes del parche
8 Min. Tiempo de lectura
Trellix, Okta, LastPass – tres proveedores de seguridad, tres brechas en el código fuente, un patrón. Los atacantes comprometen de forma selectiva a los proveedores de seguridad para conocer las vulnerabilidades en sus productos antes que sus propios clientes. La debida diligencia clásica del proveedor ya no es suficiente. Quien hoy evalúa un proveedor de SIEM, EDR o IAM sin examinar su propia postura de seguridad, está trasladando el riesgo; no lo está eliminando.
Lo más importante en resumen
- El código fuente es un objetivo estratégico de ataque. Quien conoce el código de un proveedor de seguridad, conoce las vulnerabilidades sin parchear antes de que se hagan públicas. Trellix (2024), Okta (2023), LastPass (2022) — esta serie de ataques no es casualidad.
- El intervalo entre la brecha y el parche es el período de mayor riesgo. Según Mandiant M-Trends 2025, en promedio transcurren 10 días entre la compromisión del proveedor y la primera explotación de las vulnerabilidades descubiertas como resultado de esa brecha. Diez días que ningún proceso de parcheo puede cubrir.
- La debida diligencia del proveedor requiere nuevos criterios. El certificado SOC-2 y la auditoría ISO-27001 no son suficientes. Cinco preguntas concretas que los CISO deben hacer antes de firmar un contrato.
- La segmentación protege incluso si el proveedor cae. La arquitectura Zero Trust y las autorizaciones mínimas para los agentes de las herramientas de seguridad son la respuesta estructural a las comprometimientos por parte del proveedor.
¿Qué es una brecha en el código fuente? En una brecha en el código fuente, los atacantes obtienen acceso al código fuente propietario de un proveedor de software. En el contexto de los proveedores de seguridad, esto es especialmente crítico: el código contiene detalles de implementación sobre la lógica de detección, las interfaces API y las posibles vulnerabilidades, lo que otorga a los atacantes una ventaja temporal frente al proveedor y sus clientes.
RelacionadoMultas por GDPR en 2026: Qué deben revisar ahora las pymes / EU AI Act en agosto de 2026: Fecha límite de alto riesgo y vacío de supervisión
El patrón detrás de Trellix, Okta y LastPass
Tres brechas, tres años, tres vectores diferentes, pero un resultado común: los atacantes tuvieron acceso al código de seguridad antes de que los proveedores afectados comprendieran completamente qué se había filtrado. Esto no es una coincidencia ni mala suerte operativa.
La brecha de LastPass (agosto de 2022) comenzó con el portátil comprometido de un desarrollador senior. Los atacantes utilizaron un servidor Plex Media sin parches en el dispositivo privado como punto de entrada. Desde allí, accedieron al entorno de desarrollo de LastPass y extrajeron el código fuente más las variables de entorno con credenciales para recursos en la nube. Resultado: cuatro meses después, la bóveda de copias de seguridad de producción estaba comprometida.
La brecha de Okta (octubre de 2023) afectó al código fuente en un repositorio de GitHub. Los atacantes utilizaron un token de cuenta de servicio comprometido. Lo que se filtró no fue el núcleo principal de autenticación, sino código del sistema de atención al cliente. No obstante: quien conoce el código, conoce los casos límite que los desarrolladores nunca han corregido por razones de compatibilidad hacia atrás.
El incidente de Trellix (2024) sigue un patrón similar. Los detalles aún no son completamente públicos, pero el vector de ataque pasó por una pipeline CI/CD comprometida. El patrón: el objetivo no es el código de producción, sino el proceso de compilación.
Cifras para contextualizar
10 días
Promedio entre el compromiso del proveedor y la primera explotación (Mandiant M-Trends 2025)
62%
de todas las brechas tenían, según Verizon DBIR 2025, una relación con la cadena de suministro de software
18 meses
Promedio desde la brecha de LastPass hasta la comunicación completa a los clientes sobre el alcance
Por qué falla la debida diligencia clásica de proveedores
Certificado SOC-2 Tipo 2, auditoría ISO-27001, pruebas de penetración: estas son las demandas estándar en las evaluaciones de proveedores. Las tres verifican un estado en un momento dado. Ninguna de ellas verifica si un portátil de desarrollador con acceso activo de atacantes está hoy en la pipeline de código fuente.
ISO-27001 es un certificado de sistema de gestión. Verifica si los procesos están documentados y se aplican, no si un token de cuenta de servicio comprometido sigue activo. SOC-2 verifica controles en un periodo definido. Una pipeline CI/CD con una seguridad débil de la cadena de suministro no aparece necesariamente allí. Los informes de pruebas de penetración son instantáneas y suelen verificar la superficie de ataque externa, no la infraestructura de desarrollo interna.
Cinco nuevos criterios para la evaluación de proveedores de seguridad
Estas cinco preguntas deberían incluirse en todo RFI (Solicitud de Información) a un proveedor de seguridad antes de firmar un contrato. Las respuestas revelan más que cualquier certificado.
¿Cómo está protegida vuestra pipeline CI/CD contra ataques a la cadena de suministro?
Esperado: Nivel SLSA 3 o equivalente, commits firmados, Pipeline-as-Code con registro de auditoría, sin acceso directo a producción desde entornos de desarrollo.
¿Cómo aisláis los accesos de los desarrolladores al código fuente de los sistemas de producción?
Esperado: Identidades separadas para Dev frente a Ops, MFA en todas partes, política de dispositivos privados para desarrolladores senior con acceso al código, acceso JIT (Just-In-Time) para operaciones privilegiadas de CI.
¿Cuánto tiempo transcurre desde la detección de una brecha hasta la primera información al cliente?
Esperado: SLA contractual para incidentes de seguridad, idealmente 72 horas. LastPass tardó 4 meses en hacer la divulgación completa. Ese no es un estándar aceptable.
¿Qué permisos necesita vuestro agente/sensor en nuestro entorno?
Esperado: Principio de mínimo privilegio documentado, sin «administrador local» como valor predeterminado, segmentación de red para el tráfico del sensor, firma para todos los paquetes de actualización.
¿Tenéis un programa Bug Bounty y cuál es el tiempo medio de parcheo?
Esperado: Programa público de Bug Bounty, tiempo medio de parcheo inferior a 30 días para CVEs críticos, puntuaciones CVSSv3 en vuestras propias divulgaciones. Un proveedor sin historial público de divulgaciones es una mala señal.
Ventajas e inconvenientes: arquitectura Zero Trust para agentes de herramientas de seguridad
A favor de la segmentación estricta
- Limitación del radio de explosión si el agente del proveedor se ve comprometido
- Impone permisos mínimos en lugar de «debe ver todo»
- Bloquea el movimiento lateral desde un agente comprometido
- Detecta patrones de comunicación inesperados con mayor antelación
En contra
- Algunas herramientas de seguridad requieren amplios permisos para su eficacia
- La segmentación genera sobrecarga de configuración
- Puntos ciegos si el sensor no tiene una visión completa de la red
- Los procesos de soporte del proveedor se vuelven más complejos
Preguntas frecuentes
¿Qué diferencia una violación de código fuente de una violación de datos clásica?
En una violación de datos clásica, se filtran datos de clientes, credenciales o datos financieros. En una violación de código fuente, se filtra código propietario. La diferencia: los datos robados perjudican directamente a las personas afectadas. El código fuente robado otorga a los atacantes conocimiento estructural previo sobre vulnerabilidades, que pueden utilizar contra todos los clientes del proveedor, con ventaja de tiempo antes de aplicar la parche.
¿Cómo debo reaccionar como CISO si mi proveedor de seguridad informa de una violación de código fuente?
Primero: contactar con el proveedor y aclarar el alcance de la violación (qué código, qué período de tiempo, qué sistemas). Segundo: minimizar temporalmente los permisos del agente del proveedor en el propio entorno. Tercero: revisar los registros en busca de actividades inusuales del agente del proveedor durante los últimos 30 días. Cuarto: evaluar si la desactivación temporal de la herramienta conlleva menos riesgos que el funcionamiento continuo.
¿Qué es SLSA y por qué es relevante en las evaluaciones de proveedores?
SLSA (Supply-chain Levels for Software Artifacts) es un marco de Google para la seguridad de los procesos de compilación de software. El nivel 3 significa: el proceso de compilación es reproduciblemente verificable, los artefactos están firmados y el entorno de compilación está aislado. Los proveedores de seguridad que alcanzan el nivel 3 de SLSA tienen una pipeline de compilación estructuralmente más robusta que aquellos sin documentación SLSA.
¿Soy responsable como CISO si mi proveedor de seguridad se ve comprometido?
La cuestión de la responsabilidad depende de la estructura contractual y de la clasificación regulatoria. NIS2 exige a los operadores de infraestructuras críticas un análisis de riesgos de la cadena de suministro; quien no haya documentado un proceso de diligencia debida en seguridad para la selección de proveedores asume corresponsabilidad. Las autoridades supervisoras examinarán cada vez más, en incidentes de infraestructuras críticas, si el comprador ha evaluado adecuadamente al proveedor.
¿Qué sectores están especialmente expuestos?
Todos los sectores que utilicen proveedores de seguridad con acceso profundo al sistema: infraestructura crítica, servicios financieros, sanidad, defensa y aeroespacial. Especialmente crítico: organizaciones que ejecutan herramientas de seguridad directamente en nodos de red OT sin segmentación entre agentes IT y OT.
Recomendaciones de lectura de la redacción
Más de la red de medios MBF
Fuente imagen de portada: Pexels / Polina Zimmerman (px:3779082)
