Seguridad de dependencias y análisis de composición de software

Las aplicaciones modernas están compuestas en gran medida por bibliotecas y frameworks de código abierto de terceros. Una aplicación típica de Node.js puede tener más de 1.000 dependencias transitivas; un proyecto Java puede incorporar cientos de artefactos de Maven. Cada dependencia constituye una posible superficie de ataque. La vulnerabilidad Log4Shell (CVE-2021-44228) de la biblioteca Log4j demostró que una sola dependencia podía hacer que millones de aplicaciones fueran explotables de inmediato en todo el mundo pocos días después de divulgarse la vulnerabilidad.

Las herramientas de análisis de composición de software (SCA) inventarían automáticamente todos los componentes de código abierto de una aplicación, incluidas las dependencias transitivas (las dependencias de sus dependencias), y los comprueban continuamente con bases de datos de vulnerabilidades en busca de CVE conocidas. SCA genera una lista de materiales de software (SBOM) que enumera cada componente y versión, lo que permite identificar rápidamente los sistemas afectados cuando se divulgan nuevas vulnerabilidades.

Las dependencias transitivas son bibliotecas de las que dependen sus dependencias directas y que usted no ha elegido explícitamente. Puede depender directamente del Paquete A, que depende del Paquete B (versión 1.2), que depende del Paquete C (versión 3.0, una versión vulnerable). Usted no conoce el Paquete C, pero su aplicación lo ejecuta. Las herramientas SCA recorren el árbol completo de dependencias para revelar estas vulnerabilidades ocultas, que los desarrolladores no pueden ver directamente.

Una lista de materiales de software (SBOM) es un inventario formal y legible por máquinas de todos los componentes de un producto de software, similar a la lista de ingredientes de un alimento. Entre los formatos de SBOM se incluyen SPDX (Linux Foundation) y CycloneDX (OWASP). La Orden Ejecutiva 14028 de Estados Unidos (2021) estableció la obligatoriedad de las SBOM para el software vendido al Gobierno federal. Con una SBOM, los equipos de seguridad pueden consultar inmediatamente: «¿cuáles de nuestros productos contienen Log4j?» y obtener respuestas en minutos, en lugar de tardar días con búsquedas manuales.

La fijación de dependencias especifica versiones exactas de las dependencias en lugar de rangos flexibles (^1.2.3 o *). Los archivos de bloqueo (package-lock.json, yarn.lock, Pipfile.lock, Gemfile.lock) registran la versión exacta resuelta de cada dependencia durante la instalación. Estos archivos deben confirmarse en el control de código fuente para garantizar que todos los miembros del equipo y las canalizaciones de CI/CD utilicen versiones idénticas de las dependencias y evitar ataques a la cadena de suministro que envenenen las versiones de los paquetes entre instalaciones.

Los ataques a la cadena de suministro tienen como objetivo el ecosistema de dependencias. El typosquatting consiste en publicar paquetes maliciosos con nombres similares a los de paquetes populares (por ejemplo, lodahs en lugar de lodash) con la esperanza de que los desarrolladores escriban mal el nombre. Los ataques de confusión de dependencias aprovechan el orden en que los administradores de paquetes buscan en los registros: un atacante publica un paquete malicioso con el mismo nombre que un paquete privado interno, pero con un número de versión superior, lo que hace que el administrador de paquetes instale en su lugar la versión pública maliciosa.

En el sector se utilizan ampliamente varias herramientas SCA. Snyk ofrece análisis de dependencias orientado a desarrolladores, con solicitudes de cambios automáticas para corregir problemas. OWASP Dependency-Check es una herramienta gratuita y ampliamente adoptada para Java, .NET, Python y Ruby. GitHub Dependabot abre automáticamente solicitudes de cambios para actualizar dependencias vulnerables en repositorios de GitHub. JFrog Xray y Sonatype Nexus IQ integran SCA en los repositorios de artefactos para impedir que las compilaciones vulnerables lleguen a producción.

SCA resulta más eficaz cuando se integra como una puerta de calidad en la canalización de CI/CD. En cada solicitud de cambios y compilación, la canalización ejecuta la herramienta SCA y falla la compilación si se encuentran CVE de gravedad crítica o alta en las dependencias. Este enfoque de «desplazamiento a la izquierda» detecta las dependencias vulnerables antes de que lleguen a producción, no meses después durante una revisión de seguridad manual ni después de una brecha. Los equipos deben definir umbrales claros de gravedad de vulnerabilidades para distinguir las que bloquean la implementación de las que solo generan advertencias.

Antes de añadir una dependencia, evalúe su postura de seguridad mediante varias señales. Actividad de mantenimiento: ¿se mantiene el proyecto de forma activa? ¿Cuándo se realizaron la última confirmación y la última publicación? Historial de vulnerabilidades conocidas: ¿cuántas CVE ha tenido y con qué rapidez se corrigieron? Volumen de descargas: los paquetes ampliamente utilizados reciben un mayor escrutinio de seguridad. Número de dependencias: los paquetes con menos dependencias introducen menos riesgo transitivo. OpenSSF Scorecard proporciona una puntuación automatizada de las prácticas de seguridad de los proyectos de código abierto.

Cuando SCA identifica una dependencia vulnerable, existen varias estrategias de corrección. Actualícela a una versión corregida: es la opción preferida cuando está disponible. La aplicación de parches virtuales mediante reglas de WAF puede mitigar las rutas de explotación conocidas mientras se prepara una actualización. Elimine la dependencia si ya no es necesaria. Acepte el riesgo con una justificación documentada si la vulnerabilidad no se puede explotar en el contexto de uso específico (por ejemplo, una vulnerabilidad del lado del servidor en una biblioteca del lado del cliente). Nunca deje vulnerabilidades críticas sin abordar ni una aceptación documentada.

Las herramientas SCA tienen una doble finalidad: identifican vulnerabilidades de seguridad y señalan problemas de cumplimiento de licencias en las dependencias de código abierto. Entre las licencias problemáticas más comunes se incluyen GPL v2/v3 (copyleft: exige que su producto también se publique como código abierto si lo distribuye), AGPL (extiende la GPL a los servicios de red) y SSPL. Usar una biblioteca con licencia GPL en software comercial propietario sin una licencia comercial puede generar una responsabilidad legal grave. Herramientas SCA como FOSSA, Black Duck y WhiteSource automatizan el análisis de licencias junto con la detección de vulnerabilidades para garantizar el cumplimiento de las obligaciones del código abierto.

Compruebe su comprensión de los conceptos de CompTIA Security+ (SY0-701) tratados en esta lección.

En esta lección ha aprendido que: las herramientas SCA analizan el árbol completo de dependencias, incluidas las dependencias transitivas, en busca de CVE conocidas; las SBOM proporcionan un inventario legible por máquinas que permite responder rápidamente cuando se divulgan nuevas vulnerabilidades; e integrar SCA como una puerta de calidad de CI/CD detecta las dependencias vulnerables antes de que lleguen a producción. A continuación, exploraremos DevSecOps y cómo desplazar los controles de seguridad hacia la izquierda, integrándolos en toda la canalización de CI/CD.