¿Qué es el Análisis de Composición de Software (SCA) y por qué es crítico?
Respuesta breve
El SCA inventaría los componentes de código abierto y de terceros que una aplicación incorpora —incluidas las dependencias transitivas— y señala los que tienen CVE conocidos o licencias problemáticas. Importa porque la mayor parte del código moderno son dependencias que no escribiste tú, y un único paquete transitivo vulnerable (como Log4j) puede exponer toda la aplicación. Un buen SCA prioriza por alcanzabilidad y explotabilidad, no solo por el recuento bruto de CVE.
Las aplicaciones modernas son, en su mayoría, código que escribió otra persona. El Análisis de Composición de Software (SCA) es cómo llevas la cuenta de ese código y del riesgo que arrastra.
Qué hace el SCA
Una herramienta de SCA analiza tus manifiestos y lockfiles (package-lock.json, pom.xml, go.sum, etc.) para construir un inventario de cada componente de código abierto que distribuyes. Luego coteja cada componente y versión con bases de datos de vulnerabilidades (la NVD, GitHub Advisories, feeds de fabricantes) para señalar CVE conocidos, y revisa las licencias declaradas para que los componentes con riesgo legal (p. ej. copyleft fuerte en un producto propietario) afloren pronto.
Por qué es crítico
La razón principal son las dependencias transitivas: las bibliotecas de las que dependen tus bibliotecas. Puedes incorporar 20 paquetes directos y heredar 800 transitivos. Nunca los elegiste, rara vez los auditas, y un fallo en lo profundo de ese árbol —siendo Log4Shell el ejemplo canónico— puede comprometer una aplicación cuyo propio código es impecable. El SCA es la única forma práctica de saber qué hay realmente en tu build.
Hacerlo bien
Los recuentos brutos de CVE abruman a los equipos. Un SCA maduro prioriza por alcanzabilidad (¿se llama de verdad a la función vulnerable?), explotabilidad (¿hay un exploit conocido, una ruta expuesta a internet?) y severidad, no solo por el recuento. Se ejecuta en CI para que un CVE recién divulgado en una dependencia existente falle la build, y alimenta el SBOM para que puedas responder "¿estamos afectados?" en minutos cuando salga la próxima gran vulnerabilidad.
Qué buscan los entrevistadores
Quieren que enfatices las dependencias transitivas, que conectes el SCA con la velocidad de la respuesta a incidentes y que demuestres que triarías por alcanzabilidad en lugar de ahogar a los desarrolladores en ruido.
Posibles preguntas de seguimiento
- ¿Por qué las dependencias transitivas son la parte difícil?
- ¿Cómo priorizarías cientos de hallazgos de SCA?
- ¿Cómo se relaciona el SCA con un SBOM?