Por Camilo Contreras, CTO de WoviGroup
El Código que No Escribiste (Pero del que Igual Eres Responsable)
Durante años, la ciberseguridad se centró en construir perímetros: firewalls, VPNs, antivirus. El supuesto era simple: mantener a los atacantes afuera. Ese modelo ya no alcanza.
Entre el 80% y el 90% del código de una aplicación moderna proviene de paquetes Open Source y componentes de terceros.
Los atacantes lo entendieron antes que la industria. En vez de atacar tus servidores, atacan las librerías que tus desarrolladores descargan.
Eso es un ataque a la cadena de suministro de software. Fortificar el perímetro ya no alcanza: lo que hay que proteger es la integridad de lo que construyes.
I. El Riesgo Invisible
Un ataque a la cadena ocurre cuando un actor compromete un componente legítimo en su origen.
SolarWinds
Actualización comprometida afectó a miles de organizaciones gubernamentales y privadas.
Log4Shell
Vulnerabilidad crítica en una librería usada por millones de aplicaciones Java.
event-stream
Paquete npm popular inyectado con código malicioso para robar criptomonedas.
El problema de fondo es de visibilidad.
¿Puedes decir hoy, con precisión, qué librerías y versiones tienes corriendo en producción?
En la mayoría de las empresas que auditamos, nadie puede responder eso sin abrir el código.
II. SBOM: La Nueva Visibilidad
No puedes proteger lo que no conoces. La industria se mueve hacia el estándar SBOM (Software Bill of Materials): un inventario completo de todos los componentes que conforman tu software.
¿Por qué importa?
Cuando surge una nueva vulnerabilidad crítica, no puedes invertir semanas auditando manualmente. Con un SBOM automático en tu pipeline CI/CD puedes responder en minutos.
¿La usamos?
Identifica si la librería afectada está en tu stack.
¿Qué versión?
Conoce exactamente la versión instalada.
¿Dónde está?
Localiza en qué microservicio se encuentra.
Acción recomendada
Generar y actualizar el SBOM en cada build. Esto está alineado con NIST SSDF y SLSA v1.0.
III. Zero Trust como Segunda Línea de Defensa
Trabaja con el supuesto de que alguna dependencia va a estar comprometida en algún momento. Ahí es donde Zero Trust deja de ser una frase de conferencia y se vuelve una decisión de arquitectura.
Microsegmentación
Si un servicio cae, el daño se queda ahí. Nada de credenciales que abran la base de datos completa ni accesos amplios a la red interna.
Mínimo privilegio
Cada servicio, contenedor y usuario con los permisos justos para hacer su trabajo, revisados cuando el equipo cambia.
Y una tercera pieza que casi siempre queda pendiente: firmar los artefactos. Si a producción solo pueden llegar binarios y contenedores verificados por tu propio pipeline, un paquete alterado en el camino no llega a ejecutarse.
Dónde queda esto
Esto dejó de ser un tema del equipo de infraestructura. Cuando el 85% de tu código lo escribió alguien que no trabaja contigo, la pregunta de quién responde por ese código llega al directorio.
SBOM para saber qué tienes. Pipelines endurecidos para que no entre lo que no firmaste. Zero Trust para el día en que algo igual se cuela.
Si no sabes qué dependencias tienes en producción, ese es el punto de partida.
Levantamos el inventario de tu stack, revisamos el pipeline y dejamos el SBOM corriendo en cada build.
Conversemos