Inspección y validación de bases de código para el cumplimiento

Antes de implementar herramientas automatizadas de análisis de composición de software, las organizaciones deben comprender qué es necesario inspeccionar y validar en sus bases de código. Las aplicaciones modernas contienen cientos o miles de dependencias, lo que hace que la inspección manual no sea práctica. Los enfoques sistemáticos para la detección de dependencias, la evaluación de vulnerabilidades y la validación de cumplimiento son esenciales.

¿Por qué la inspección y la validación son importantes?

Desafío de dependencia: Las aplicaciones no solo dependen de los paquetes que importe directamente. Cada dependencia directa normalmente depende de paquetes adicionales (dependencias transitivas), creando árboles de dependencia profundos. Una aplicación típica podría hacer referencia directamente a paquetes de 20 a 30, pero depende transitivamente de los paquetes 200-500. Usted es responsable de las vulnerabilidades y las obligaciones de licencia en todas las dependencias, no solo las directas.

El imperativo de seguridad: Las vulnerabilidades de seguridad en las dependencias representan riesgos significativos. Los atacantes aprovechan activamente las vulnerabilidades conocidas de los paquetes populares, lo que hace que las dependencias no actualizadas sean objetivos atractivos. Las infracciones de alto perfil suelen implicar la explotación de vulnerabilidades conocidas en componentes de código abierto que las organizaciones no pudieron actualizar.

Requisito de cumplimiento: Las infracciones de licencia pueden dar lugar a una acción legal, el suministro abierto forzado del código propietario, las restricciones de distribución y los daños de reputación. Las organizaciones deben realizar un seguimiento de las obligaciones de licencia para cada dependencia y garantizar el cumplimiento de los términos de licencia.

La realidad operativa: Las dependencias cambian constantemente. Las nuevas vulnerabilidades se divulgan diariamente, los paquetes reciben actualizaciones, los mantenedores abandonan proyectos y se publican nuevas versiones. La inspección única no es suficiente: se requiere la validación continua.

Qué inspeccionar y validar

La inspección completa de la base de código cubre varias dimensiones:

Inventario de dependencias

Crear una lista completa de materiales:

• Dependencias directas: Los paquetes se enumeran explícitamente en archivos de manifiesto de paquete (package.json, requirements.txt, pom.xml, *.csproj).
• Dependencias transitivas: Paquetes requeridos por tus dependencias directas, a varios niveles de profundidad.
• Dependencias de desarrollo: Paquetes usados durante el desarrollo y las pruebas, pero no enviados con código de producción.
• Seguimiento de versiones: Versiones específicas de cada paquete actualmente en uso.
• Orígenes de dependencia: Qué registros de paquetes proporcionan dependencias (npm, PyPI, NuGet, Maven Central, registros privados).

Por qué es importante completar inventarios:

• Administración de vulnerabilidades: No puede corregir las vulnerabilidades que no conoce.
• Cumplimiento de licencias: Debe realizar un seguimiento de las obligaciones de licencia para todas las dependencias, no solo para las directas.
• Planeación de actualizaciones: Comprender las relaciones de dependencia ayuda a planear las actualizaciones que no interrumpirán la compatibilidad.
• Visibilidad de la cadena de suministro: Sepa exactamente qué código externo se incluye en las aplicaciones.

Detección de vulnerabilidades de seguridad

Identificación de vulnerabilidades conocidas:

• Mapeo de CVE (Vulnerabilidades y Exposiciones Comunes): Emparejar versiones de dependencias con bases de datos CVE que contienen vulnerabilidades conocidas.
• Evaluación de gravedad: Evalúe la gravedad de la vulnerabilidad mediante puntuaciones de CVSS (sistema de puntuación de vulnerabilidades comunes) que van desde 0 a 10.
• Análisis de vulnerabilidades de seguridad: Determine si las vulnerabilidades se aprovechan activamente en la naturaleza.
• Disponibilidad de revisiones: Identifique qué versiones corrigen vulnerabilidades y si hay revisiones disponibles.

Descripción de las bases de datos de vulnerabilidades:

• Base de datos nacional de vulnerabilidades (NVD): Repositorio de datos de vulnerabilidades del gobierno de EE. UU. basados en identificadores CVE.
• Base de datos de avisos de GitHub: Avisos de seguridad curados para paquetes en varios ecosistemas.
• Listas de distribución de correo de seguridad: Notificaciones de seguridad específicas del lenguaje y del marco.
• Bases de datos del proveedor: Las herramientas comerciales de SCA mantienen bases de datos de vulnerabilidades propietarias con inteligencia adicional.

Categorías de vulnerabilidades en dependencias:

• Errores de inyección: Inyección de código SQL, inyección de comandos, vulnerabilidades de scripting entre sitios en marcos web.
• Problemas de autenticación: Implementaciones de autenticación débiles, problemas de administración de sesiones, errores de control de credenciales.
• Exposición de datos confidenciales: Almacenamiento de datos no seguro, cifrado inadecuado, pérdida de información.
• Configuración incorrecta de seguridad: Configuraciones predeterminadas con puntos débiles conocidos, características innecesarias habilitadas.
• Denegación de servicio: Vulnerabilidades de agotamiento de recursos, problemas de complejidad algorítmica.
• Errores de deserialización: Deserialización no segura que conduce a la ejecución remota de código.

Validación de cumplimiento de licencias

Identificación de las obligaciones de licencia:

• Detección de licencias: Identifique qué licencias se aplican a cada dependencia.
• Clasificación de licencias: clasifique las licencias como permisivas, copyleft débil, copyleft fuerte o propietarias.
• Análisis de compatibilidad: Compruebe que las licencias de diferentes dependencias son compatibles cuando se combinan.
• Seguimiento de obligaciones: Requisitos de documentos como atribución, divulgación de código fuente o licencias de trabajo derivadas.

Problemas comunes de cumplimiento:

• Contaminación de Copyleft: las dependencias con licencia GPL en software propietario pueden requerir el aprovisionamiento abierto de toda la aplicación.
• Errores de atribución: Faltan avisos de copyright necesarios y texto de licencia en software distribuido.
• Combinaciones incompatibles: Uso de dependencias con licencias en conflicto que no se pueden combinar legalmente.
• Cambios de licencia: A veces, los proyectos cambian las licencias entre versiones, lo que requiere volver a evaluar.

Evaluación del riesgo de licencia:

• Alto riesgo: licencias seguras de copyleft (GPL, AGPL) en la distribución de software propietario.
• Riesgo medio: licencias de copyleft débiles (LGPL, MPL) que requieren prácticas de integración cuidadosas.
• Bajo riesgo: Licencias permisivas (MIT, Apache 2.0, BSD) con restricciones mínimas.
• Riesgo desconocido: Licencias personalizadas, licencias poco claras o información de licencia que falta.

Evaluación de la calidad de las dependencias

Evaluación de la capacidad de mantenimiento de dependencias:

• Estado de mantenimiento: Determine si las dependencias se mantienen o abandonan activamente.
• Frecuencia de actualización: Evalúe la frecuencia con la que las dependencias reciben actualizaciones y correcciones de errores.
• Salud de la comunidad: Evaluar la actividad de colaborador, los tiempos de respuesta de problemas y la participación de la comunidad.
• Calidad de la documentación: Revise si las dependencias tienen documentación adecuada para su uso adecuado.
• Prácticas de seguridad: Compruebe que los proyectos tienen procesos de divulgación responsables y avisos de seguridad.

Indicadores de calidad:

• Mantenimiento activo: Confirmaciones periódicas, versiones recientes, mantenedores dinámicos.
• Comunidad grande: Muchos colaboradores, estrellas, bifurcaciones y usuarios proporcionan sostenibilidad.
• Comunicación clara: Seguimiento activo de problemas, discusiones receptivas, notas claras de la versión.
• Concienciación sobre seguridad: Política de seguridad publicada, corrección rápida de vulnerabilidades, los avisos de seguridad.

Marcas rojas:

• Proyectos abandonados: No hay actualizaciones durante años, mantenedores que no responden, acumulando problemas no conocidos.
• Riesgo de un único mantenedor: Dependencia crítica mantenida por una persona que podría dejar de estar disponible.
• Mala calidad: Pruebas inadecuadas, errores frecuentes, cambios que rompen la compatibilidad en versiones secundarias.
• Falta de seguridad: No hay ninguna directiva de seguridad, respuesta a vulnerabilidades lentas, problemas de seguridad no ocultos.

Desafíos de inspección manual

Por qué la inspección manual no es escalable:

Cantidad de datos abrumadora

• Cientos de dependencias: Incluso las aplicaciones pequeñas dependen transitivamente de cientos de paquetes.
• Varias aplicaciones: Las organizaciones mantienen docenas o cientos de aplicaciones, multiplicando el recuento de dependencias.
• Cambios constantes: Las nuevas versiones publicadas diariamente hacen que cualquier inventario manual se desactualice inmediatamente.
• Fallo humano: El seguimiento manual inevitablemente pierde las dependencias, especialmente las transitivas.

Información dispersa

• Varios orígenes: La información de vulnerabilidad procede de las bases de datos CVE, las listas de distribución de correo de seguridad, los avisos de GitHub, las notificaciones del proveedor y las divulgaciones del investigador de seguridad.
• Investigación de licencias: Determinar las licencias exactas requiere examinar los archivos de código fuente, los documentos léame y los archivos de licencia de cada paquete.
• Detalles específicos de la versión: Las vulnerabilidades y licencias pueden cambiar entre versiones, lo que requiere una investigación específica de la versión.
• Información en conflicto: A veces, diferentes orígenes proporcionan información de vulnerabilidades o licencias opuestas.

Análisis que consume mucho tiempo

• Evaluación de vulnerabilidades: La investigación de la gravedad, vulnerabilidad y estado de revisión de cada vulnerabilidad tarda mucho tiempo.
• Análisis de licencias: Comprender los términos de licencia, la compatibilidad y las obligaciones requiere experiencia legal.
• Planeación de actualizaciones: Determinar rutas de actualización seguras considerando cambios importantes y conflictos de dependencias es complejo.
• Supervisión continua: La supervisión continua de nuevas vulnerabilidades y actualizaciones requiere recursos dedicados.

Detección retrasada

• Retraso de detección: Los procesos manuales detectan vulnerabilidades semanas o meses después de la divulgación.
• Respuesta reactiva: Las organizaciones aprenden sobre las vulnerabilidades de los incidentes de seguridad en lugar de un examen proactivo.
• Ciclos de auditoría: Las auditorías periódicas dejan las aplicaciones vulnerables entre auditorías.
• Parches de emergencia: Sin la supervisión continua, las vulnerabilidades críticas requieren parches de emergencia disruptivos.

La solución automatizada

Las herramientas de análisis de composición de software resuelven los desafíos manuales de inspección:

Detección automatizada

• Análisis de dependencias: Las herramientas de SCA analizan automáticamente los archivos de manifiesto del paquete para identificar las dependencias.
• Resolución transitiva: Las herramientas siguen las cadenas de dependencia para crear una lista completa de materiales.
• Análisis de archivos de bloqueo: Analice los archivos de bloqueo (package-lock.json, Pipfile.lock) que muestran exactamente qué versiones están instaladas.
• Examen binario: Algunas herramientas examinan los archivos binarios y contenedores compilados para detectar dependencias insertadas.

Supervisión continua

• Alertas de vulnerabilidades en tiempo real: Reciba notificaciones inmediatas cuando las nuevas vulnerabilidades afecten a las dependencias.
• Actualizaciones automatizadas: Las herramientas como GitHub Dependabot crean solicitudes de incorporación de cambios automáticamente cuando hay actualizaciones de seguridad disponibles.
• Visibilidad del panel: Los paneles centralizados muestran el estado de vulnerabilidad en todas las aplicaciones.
• Examen programado: Los exámenes automatizados normales garantizan que los datos de dependencia permanecen actualizados.

Bases de datos completas

• Datos de vulnerabilidad agregados: Las herramientas de SCA agregan información de NVD, base de datos de asesoramiento de GitHub, listas de correo de seguridad y bases de datos de proveedor.
• Bases de datos de licencias: Mantenga información completa sobre licencias, incluidos los textos completos de licencia y los resúmenes de obligaciones.
• Curación y comprobación: Los proveedores comprueban y curan los datos de vulnerabilidad para reducir los falsos positivos.
• Inteligencia propietaria: Las herramientas comerciales proporcionan investigación y análisis adicionales más allá de las bases de datos públicas.

Análisis inteligente

• Puntuación de gravedad: Calcule automáticamente las puntuaciones de CVSS y priorice las vulnerabilidades por riesgo.
• Análisis de accesibilidad: Determine si las rutas de acceso de código vulnerables se usan realmente en la aplicación.
• Guía de corrección: Proporcione recomendaciones de versión específicas que corrijan vulnerabilidades al tiempo que mantienen la compatibilidad.
• Cumplimiento de directivas: Se produce un error automático en las compilaciones o se bloquean las implementaciones cuando se detectan infracciones de directivas.

Establecimiento de líneas base de validación

Antes de implementar el examen automatizado, establezca criterios de validación:

Directivas de seguridad

• Tolerancia a vulnerabilidades: defina qué gravedades de vulnerabilidades son aceptables (por ejemplo, sin críticos o altos, medios limitados).
• Plazos de parcheo: Establezca la rapidez con la que se deben corregir las vulnerabilidades de diferentes niveles de gravedad.
• Procesos de excepción: Cree procedimientos para aceptar riesgos cuando la aplicación de revisiones inmediatas no sea factible.
• Requisitos de informes: Defina quién necesita notificaciones de vulnerabilidad y la rapidez.

Directivas de cumplimiento

• Licencias aprobadas: Enumera las licencias que siempre son aceptables (por ejemplo, MIT, Apache 2.0).
• Licencias restringidas: Identificar licencias que requieran aprobación especial (por ejemplo, LGPL) o prohibición (por ejemplo, GPL para software propietario).
• Requisitos de atribución: Defina cómo se debe proporcionar la atribución en el software distribuido.
• Seguimientos de auditoría: Especifique los requisitos de documentación para la evidencia de cumplimiento.

Estándares de calidad

• Requisitos de mantenimiento: Defina las expectativas de mantenimiento mínimas (por ejemplo, actualizaciones en el último año).
• Tamaño de la comunidad: Establezca umbrales para las métricas de estado de la comunidad aceptables.
• Estándares de documentación: Especifique los requisitos mínimos de documentación para las dependencias.
• Prácticas de seguridad: Requerir que las dependencias tengan directivas de seguridad publicadas y control de vulnerabilidades con capacidad de respuesta.

Comprender qué inspeccionar y validar proporciona la base para implementar herramientas automatizadas de análisis de composición de software. En la siguiente unidad se exploran los aspectos básicos de SCA y cómo las herramientas automatizadas abordan los desafíos de la administración manual de dependencias.