OSV-Scanner, SBOM y la pregunta de cadena de suministro que ahora hacen los clientes
El escaneo de dependencias es maduro; lo que ha cambiado es que clientes y reguladores piden ahora el inventario en sí. Cómo generar SBOM útiles y no ceremoniales, y cómo responder a "¿nos afecta?" en una hora.
La pregunta de la cadena de suministro ha pasado de ser una preocupación del equipo de seguridad a ser una línea del cuestionario de compras. Los clientes piden una lista de materiales de software. NIS2 espera gestión del riesgo de cadena de suministro en las entidades en alcance. La orden ejecutiva estadounidense convirtió los SBOM en condición de venta federal y la expectativa se extendió desde ahí.
Casi todas las organizaciones responden generando un SBOM en el momento de la entrega, adjuntándolo a una carpeta de cumplimiento y no volviendo a mirarlo. Eso satisface el cuestionario y no aporta nada. El mismo artefacto, usado de otra forma, responde a la única pregunta que importa el día en que se publica un fallo grave de biblioteca: ¿nos afecta, dónde, y en cuánto podemos entregar la corrección?
Genera desde la compilación, no desde el repositorio
Un SBOM producido leyendo package.json o requirements.txt lista lo que pediste. Un SBOM producido desde el artefacto compilado lista lo que te llevaste, que es una lista distinta y más larga, porque las dependencias transitivas son donde viven las vulnerabilidades interesantes.
Genera en tiempo de compilación, desde el fichero de bloqueo y desde la imagen resultante:
syft packages dir:. -o spdx-json > sbom-fuente.json
syft packages miimagen@sha256:... -o spdx-json > sbom-imagen.json
Adjunta ambos a la entrega. SPDX y CycloneDX se aceptan los dos; elige uno y sé consistente, porque el utillaje que los consume difiere en soporte y mezclar formatos entre repositorios hace doloroso agregarlos después.
Escanea los ficheros de bloqueo con OSV-Scanner
OSV-Scanner consulta la base OSV, que agrega avisos de todos los ecosistemas con rangos de versiones afectadas precisos, en vez de los rangos laxos que producen falsos positivos en otras herramientas.
osv-scanner --lockfile=package-lock.json --lockfile=poetry.lock --lockfile=go.sum .
osv-scanner --sbom=sbom-imagen.json
Lee ficheros de bloqueo directamente, lo que significa que ve las versiones resueltas y no las restricciones declaradas, y lee SBOM, lo que significa que puedes reescanear una entrega de hace dos años sin recompilarla.
La salida suele ser más pequeña y más precisa que la de un escáner genérico, y esa precisión es la diferencia entre una lista sobre la que la gente actúa y una lista que la gente ignora.
La alcanzabilidad es el filtro que importa
Una vulnerabilidad en un paquete presente en el árbol de dependencias no es lo mismo que una vulnerabilidad en tu aplicación. La biblioteca puede ser una herramienta de compilación, una dependencia transitiva de un marco de pruebas, o estar presente pero no importarse nunca.
osv-scanner --call-analysis hace análisis estático del grafo de llamadas para Go y, cada vez más, para otros ecosistemas, marcando los hallazgos como alcanzables o no. Donde funciona, elimina la mayor parte de la lista. Donde no, aproxima: ¿se llama a la función vulnerable desde alguna ruta de tu código? Veinte minutos con grep y la lista de funciones afectadas del aviso responden a eso mejor que cualquier puntuación de severidad.
Deja constancia del razonamiento. "No alcanzable: parseXml no se llama; usamos solo la ruta JSON" es una posición defendible ante un auditor y una nota útil para la siguiente persona que vea el mismo CVE.
La hora que cuenta
Cuando caiga el siguiente fallo de biblioteca ampliamente explotado, el trabajo es:
- Consultar todos los SBOM almacenados buscando el paquete. Si los SBOM están en un sitio y son legibles por máquina, esto es un comando sobre un directorio, y cubre servicios que nadie desarrolla activamente, que es donde siempre está la copia sin parchear.
- Determinar la alcanzabilidad por servicio.
- Entregar la actualización primero a los alcanzables.
- Revisar los logs en busca de intentos de explotación anteriores al parche.
El paso uno es la razón de generar SBOM. Las organizaciones que los tienen responden en una hora. Las que no, pasan tres días preguntando a los equipos si usan la biblioteca, y se equivocan, porque la respuesta para el servicio escrito en 2020 por un equipo que ya no existe es "sí, transitivamente".
Firma y procedencia, en breve
Una vez existe el inventario, la siguiente pregunta es si el artefacto es el que compiló tu pipeline. Sigstore y cosign firman imágenes sin gestionar claves, y las atestaciones de procedencia SLSA registran qué compilación produjo qué digest. Verifica en la admisión del clúster, para que una imagen que no compiló tu pipeline no pueda ejecutarse.
Es un paso más pequeño de lo que suena —una tarea de firma en el pipeline y una política de admisión— y cierra el hueco que el escaneo no puede cerrar: un SBOM impecable de una imagen que no es la imagen que estás ejecutando no te dice nada.
Que sea honesto
El modo de fallo de los programas de SBOM es generar documentos que nadie consulta. La prueba es simple: ¿puedes responder, ahora mismo, qué servicios en marcha incluyen cierto paquete en cierta versión, sin preguntar a ningún equipo? Si sí, el programa funciona. Si no, tienes artefactos de cumplimiento, no una capacidad de cadena de suministro, y la diferencia se verá el día que importe.