SBOM, firmas y attestations: saber qué contiene lo que estás desplegando
La mayoría de las organizaciones no puede responder qué componentes contiene el software que corre en producción ni quién los construyó. Con generación asistida y dependencias sugeridas por modelos, esa ceguera se volvió más peligrosa.
Pregunta a un equipo de tecnología qué componentes de terceros contiene el sistema que corre hoy en producción. La respuesta honesta suele ser que habría que revisarlo, y que la revisión llevaría un rato.
Esa ceguera fue tolerable durante mucho tiempo. Dejó de serlo por dos razones que se acumularon. La primera es que los ataques a la cadena de suministro de software se volvieron un vector habitual: comprometer una dependencia usada por miles de organizaciones es más eficiente que atacar a cada una. La segunda es más reciente y menos discutida: la generación asistida por IA sugiere dependencias con la misma naturalidad con la que sugiere código, y esas sugerencias entran al sistema con menos escrutinio del que tenía una decisión de incorporar una biblioteca nueva.
Los tres instrumentos
SBOM. Un inventario de materiales del software: la lista completa de componentes que contiene un artefacto, con sus versiones y sus dependencias transitivas. Es la respuesta a “qué contiene esto”.
Su valor se hace evidente en el escenario que motiva su existencia: se descubre una vulnerabilidad grave en un componente ampliamente usado. La pregunta operativa es cuáles de nuestros sistemas lo contienen. Con inventarios generados automáticamente, la respuesta toma minutos. Sin ellos, toma días de revisión manual, durante los cuales la organización está expuesta y no sabe cuánto.
Firmas. Un mecanismo criptográfico que permite verificar que un artefacto fue producido por quien dice haberlo producido y no fue alterado después. Responde a “de dónde salió esto y llegó intacto”.
Sin firma, la confianza en un artefacto se apoya en que vino de donde se esperaba, lo cual es una suposición sobre la infraestructura de distribución, no una verificación.
Attestations. Declaraciones verificables sobre cómo se construyó un artefacto: con qué código fuente, en qué sistema de construcción, pasando por qué verificaciones. Responden a “cómo se hizo esto y qué controles pasó”.
Juntos, los tres cierran la pregunta completa: qué contiene, de dónde viene, cómo se hizo.
Lo que agrega la generación asistida
Hay tres formas específicas en que el trabajo asistido por IA aumenta la exposición de la cadena de suministro, y conviene nombrarlas porque no son obvias.
Dependencias sugeridas con menos deliberación. Incorporar una biblioteca solía ser una decisión: alguien la buscaba, la evaluaba, la proponía. Cuando aparece sugerida en el flujo de escritura, entra con la fricción de aceptar una línea. La evaluación que antes ocurría naturalmente ahora hay que provocarla.
Nombres plausibles que no existen. Un modelo puede sugerir un componente que suena razonable y no existe con ese nombre exacto. Ese hueco es explotable: alguien puede registrar el nombre sugerido con contenido malicioso, esperando que se instale por error. La defensa es verificación automática de que cada dependencia declarada corresponde a un componente legítimo y conocido.
Volumen. Más código incorporado en menos tiempo significa más superficie, y el escrutinio manual no escala al mismo ritmo.
Ninguno de los tres es un argumento contra la generación asistida. Son argumentos a favor de automatizar la verificación al mismo ritmo al que se automatizó la producción.
Cómo se implementa sin un proyecto grande
La buena noticia es que estos tres instrumentos son de los más automatizables del repertorio de seguridad. No requieren cambio cultural ni proceso nuevo: se agregan a la línea de construcción y corren solos.
Una secuencia razonable en orden de rendimiento:
Generación automática de SBOM en cada construcción. Sin excepciones y sin curaduría manual. El artefacto se produce junto con el software y se almacena con él.
Escaneo de dependencias contra bases de vulnerabilidades conocidas, con una política de qué severidad bloquea la construcción y cuál solo alerta. La política importa: si todo bloquea, la gente busca cómo saltarse el control.
Escaneo de secretos. Detectar credenciales incorporadas por error antes de que lleguen al repositorio. Es de las verificaciones más baratas y de las que más incidentes evita.
Firma de artefactos en el momento de la construcción, con verificación en el momento del despliegue. La verificación es la mitad que se omite con más frecuencia: firmar sin verificar no protege de nada.
Attestations de procedencia para los artefactos que llegan a producción.
Las tres primeras se pueden tener funcionando en días. Las dos últimas requieren más trabajo de infraestructura y conviene abordarlas cuando las primeras ya son rutina.
La política que hace que los controles se usen
Automatizar las verificaciones es la parte fácil. La parte que determina si sirven es la política: qué pasa cuando algo falla.
Una política mal calibrada produce uno de dos resultados, ambos malos. Si todo bloquea, los equipos acumulan trabajo detenido por hallazgos que no representan riesgo real, y en poco tiempo alguien habilita una forma de saltarse el control “por esta vez”, que se vuelve permanente. Si nada bloquea, las alertas se acumulan sin destinatario y el control existe solo en el informe.
Una calibración que funciona distingue por severidad y por explotabilidad.
Bloquea siempre: secretos detectados en el código, dependencias con vulnerabilidad crítica y explotación conocida, artefactos sin firma válida en el camino a producción.
Bloquea con excepción documentada: vulnerabilidades altas sin explotación conocida, componentes sin mantenimiento activo. La excepción requiere un responsable, una razón y una fecha de revisión. Sin fecha, la excepción es permanente.
Alerta sin bloquear: severidad media o baja, hallazgos en dependencias que no llegan a producción, componentes con actualización disponible pero sin vulnerabilidad.
La pieza que sostiene todo esto es el proceso de excepción. Si pedir una excepción es más lento que el trabajo que desbloquea, la gente va a buscar otro camino. Si es demasiado fácil, todo se convierte en excepción. El punto de equilibrio suele estar en que la excepción la otorgue alguien identificable, quede registrada y tenga vencimiento automático.
Hay una métrica que vale la pena mirar mensualmente: cuántas excepciones activas hay y cuántas están vencidas. Un número creciente de excepciones vencidas indica que el proceso se convirtió en un trámite y que los controles ya no están controlando nada.
Es el mismo patrón que en cualquier otro sistema de gobierno: lo que determina si funciona no es la existencia del control, sino qué tan difícil es evadirlo y qué tan visible queda cuando alguien lo hace.
La pregunta que se debe poder responder en minutos
Hay una prueba práctica para saber si esto está resuelto, y es exactamente el escenario que motiva toda la práctica.
Se publica una vulnerabilidad crítica en un componente muy usado. La pregunta llega desde la dirección: ¿estamos expuestos?
Una organización con inventarios generados automáticamente responde en minutos, con una lista de sistemas afectados y versiones. Una organización sin ellos responde “estamos revisando”, y esa respuesta se sostiene durante días mientras alguien recorre repositorios a mano.
La diferencia entre ambas no es de madurez organizacional ni de presupuesto. Es de haber agregado un paso automático a la línea de construcción, una vez.