Análisis de composición de software (SCA)
En seguridad de aplicaciones, el análisis de composición de software es la identificación de los componentes de terceros y de código abierto de los que depende una aplicación, y de las vulnerabilidades conocidas y las obligaciones de licencia que llevan asociadas. La mayor parte del código de una aplicación moderna lo escribió otro, y estas son las herramientas que lo leen.
Cómo funciona
El analizador resuelve el grafo de dependencias, normalmente a partir de los ficheros de bloqueo, de la salida de la compilación o de una imagen de contenedor, identifica cada componente y versión, y los cruza con los datos de vulnerabilidades. Como la mayoría de los componentes los arrastran otros componentes en vez de declararse directamente, el grafo baja varios niveles, y la mayoría de los hallazgos suelen ser transitivos.
Las herramientas mejores añaden análisis de alcanzabilidad: en vez de informar de que hay una versión vulnerable, intentan determinar si la función afectada se llama de verdad desde tu código. Esa distinción suele quitar una parte grande de la cola, que es la diferencia entre una lista que un equipo recorre y una lista que un equipo ignora.
Qué sale mal
Cruzar versiones sin contexto produce volumen, y el volumen produce indiferencia. Una vulnerabilidad en una rutina de análisis sintáctico de una biblioteca que tu aplicación solo usa para dar formato está presente y no es alcanzable, e informar de ella con la misma prioridad que de una alcanzable es como los backlogs llegan a cinco cifras.
El segundo problema es lo que el grafo no ve. El código copiado dentro del repositorio, los componentes instalados en un contenedor por un gestor de paquetes y no por la compilación de la aplicación, las bibliotecas enlazadas estáticamente, y un recurso de front-end empaquetado que se sirve desde tu propio dominio son todos dependencias reales que muchas configuraciones no ven. Donde más duele es en las imágenes de contenedor, porque la capa base lleva un sistema operativo que en el equipo de aplicación nadie considera suyo.
Tercero, actualizar es una decisión con dos caras. Fijar versiones hace reproducibles las compilaciones y te deja atrás; dejarlas flotar te mantiene al día y permite que un compromiso aguas arriba te llegue solo, que es precisamente el mecanismo de un ataque a la cadena de suministro. Ninguna de las dos sale gratis, y una política que no reconozca la contrapartida no es una política.
Dónde aparece esto en una auditoría
Usamos la lista de componentes como mapa hacia la aplicación en marcha y después confirmamos a mano: una biblioteca antigua de la que informa la herramienta se convierte en hallazgo cuando alcanzamos el camino vulnerable a través del sistema desplegado, y en observación cuando no. Eso es lo que separa nuestro informe de la salida de la herramienta, y es también como se encuentra la deserialización insegura, porque las cadenas de gadgets salen de las bibliotecas y no del código propio del cliente. Cuando existe un SBOM lo cotejamos con lo que observamos. Esto forma parte de cómo se confirman los hallazgos de dependencias contra una aplicación en marcha.