El código que nadie escribió
Una aplicación moderna puede tener unas pocas miles de líneas propias y cientos de miles de líneas de dependencias: librerías, frameworks, imágenes de sistema operativo. Cada una puede tener vulnerabilidades conocidas, y algunas pueden haber sido manipuladas a propósito antes de llegar.
Revisar el código propio es necesario. Ignorar todo lo demás deja abierta la mayor parte de la superficie.
Qué contiene cada artefacto
La práctica que lo resuelve se apoya en la propia construcción, que ya es una compuerta (como en que falle la construcción, no la producción):
- Lista de componentes. Cada construcción genera un inventario de todo lo que contiene el artefacto (lo que se suele llamar SBOM): cada librería, con su versión.
- Análisis de vulnerabilidades. Ese inventario se cruza con las bases de vulnerabilidades conocidas. Lo crítico detiene la construcción; lo demás se registra con plazo.
- Versiones fijadas. Las dependencias se fijan a versiones concretas, para que la construcción de hoy y la de mañana contengan lo mismo.
- Firma del artefacto. Lo que se publica va firmado, y el despliegue solo acepta artefactos firmados por la propia construcción. Encaja con desplegar por digest: la huella dice qué es; la firma dice quién lo hizo.
Lo que sigue después del despliegue
Una dependencia sin vulnerabilidades hoy puede tenerlas mañana, cuando se descubre una nueva. Como cada artefacto en producción tiene su lista de componentes guardada, responder a "¿estamos afectados por esta vulnerabilidad?" es una consulta de minutos, no una búsqueda de días por todos los repositorios.
También los secretos y la configuración
El código que se publica no debe llevar dentro credenciales (lo vimos en secretos con nombre, nunca con valor), y la configuración de infraestructura se analiza igual que el código de la aplicación, con reglas como código.
Con el software bajo control, queda proteger lo que más importa al final: los datos.
Cómo lo aplicamos: Ciberseguridad.