Análisis de composición de software - Enciclopedia

Análisis de composición de software (SCA) es una práctica en los campos de la información tecnológica y la ingeniería de software para analizar aplicaciones de software personalizadas para detectar software de código abierto integrado y verificar si están actualizados, contienen fallos de seguridad o tienen requisitos de licencia.

Antecedentes
Es una práctica común en la ingeniería de software desarrollar software utilizando diferentes componentes. El uso de componentes de software segmenta la complejidad de elementos más grandes en trozos más pequeños de código y aumenta la flexibilidad, permitiendo un mayor uso repetido de componentes para abordar nuevas necesidades. Esta práctica se ha expandido ampliamente desde finales de los años 90 con la popularización del software de código abierto (OSS) para ayudar a acelerar el proceso de desarrollo de software y reducir el tiempo de mercado.
Sin embargo, el uso de software de código abierto introduce muchos riesgos para las aplicaciones de software en desarrollo. Estos riesgos se pueden organizar en 5 categorías:

Control de versión de OSS: riesgos de cambios introducidos por nuevas versiones
Seguridad: riesgos de vulnerabilidades en componentes - Comúnmente Utilizadas y Expuestas (o CVEs)
Licencia: riesgos de requisitos legales de propiedad intelectual (PI)
Desarrollo: riesgos de compatibilidad entre la base de código existente y el software de código abierto
Soporte: riesgo de documentación deficiente y componentes de software obsoletos
Poco después de la fundación de la Iniciativa de Código Abierto en febrero de 1998, se plantearon los riesgos asociados con el OSS, y las organizaciones intentaron gestionar esto utilizando hojas de cálculo y documentos para rastrear todos los componentes de código abierto utilizados por sus desarrolladores.
Para las organizaciones que utilizan extensamente componentes de código abierto, existía la necesidad de ayudar a automatizar el análisis y la gestión del riesgo de código abierto. Esto resultó en una nueva categoría de productos de software llamada Análisis de Composición de Software (SCA) que ayuda a las organizaciones a gestionar el riesgo de código abierto.
SCA busca detectar todos los componentes de terceros en uso dentro de una aplicación de software para ayudar a reducir los riesgos asociados con las vulnerabilidades de seguridad, los requisitos de licencia de PI y la obsolescencia de los componentes que se utilizan.

Principio de funcionamiento
Los productos de SCA suelen funcionar de la siguiente manera:

Un motor escanea el código fuente del software y los artefactos asociados utilizados para compilar una aplicación de software.
El motor identifica los componentes de OSS y sus versiones y, generalmente, almacena esta información en una base de datos, creando un catálogo de OSS utilizados en la aplicación escaneada.
Este catálogo se compara con bases de datos que refieren a vulnerabilidades de seguridad conocidas para cada componente, los requisitos de licencia para el uso del componente y las versiones históricas del componente. Para la detección de vulnerabilidades de seguridad, este comparativo se realiza típicamente contra vulnerabilidades de seguridad conocidas (CVEs) que se rastrean en la Base de Datos Nacional de Vulnerabilidades (NVD). Algunos productos utilizan una base de datos adicional propietaria de vulnerabilidades. Para la conformidad de PI / Legal, los productos de SCA extraerán y evaluarán el tipo de licencia utilizado para el componente de OSS. Las versiones de los componentes se extraen de repositorios de código abierto populares como GitHub, Maven, PyPi, NuGet y muchos otros.
Los resultados se hacen disponibles a los usuarios finales utilizando diferentes formatos digitales. El contenido y el formato dependen del producto de SCA y pueden incluir orientaciones para evaluar e interpretar el riesgo, y recomendaciones, especialmente cuando se refiere a los requisitos legales de los componentes de código abierto como licencias de copyleft fuerte o débil. El resultado también puede contener un Acta de Materiales de Software (SBOM) que detalla todos los componentes de código abierto y los atributos asociados utilizados en una aplicación de software.

Uso
Como el SCA afecta a diferentes funciones en las organizaciones, diferentes equipos pueden utilizar los datos según el tamaño y la estructura de la empresa. El departamento de TI a menudo utiliza SCA para implementar y operar la tecnología con stakeholders comunes, incluyendo al director de información (CIO), el director tecnológico (CTO) y los arquitectos de empresa (EA). Los datos de seguridad y licencia se utilizan a menudo por roles como el director de seguridad de información (CISO) para riesgos de seguridad y el director de PI / Cumplimiento para la gestión de riesgos de PI.
Dependiendo de las capacidades del producto de SCA, se puede implementar directamente en el entorno de desarrollo integrado (IDE) de un desarrollador que utiliza e integra componentes de OSS, o puede implementarse como un paso dedicado en el proceso de control de calidad del software.
Los productos de SCA, y especialmente su capacidad para generar un SBOM, son requeridos en algunos países como Estados Unidos para reforzar la seguridad del software entregado por un vendedor a una de sus agencias.
Otro caso de uso común para el SCA es la Deber de Diligencia Tecnológica. Antes de una transacción de fusión y adquisición (M&A), las firmas de asesoría revisan los riesgos asociados con el software de la empresa objetivo.

Fortalezas
La naturaleza automatizada de los productos de SCA es su principal fortaleza. Los desarrolladores no tienen que realizar trabajos adicionales manuales al usar e integrar componentes de OSS. La automatización también se aplica a referencias indirectas a otros componentes de OSS dentro del código y los artefactos.

Debilidades
Por el contrario, algunas debilidades clave de los productos de SCA actuales pueden incluir:

Implantación compleja y laboriosa que puede demorar meses en funcionar completamente
Cada producto utiliza su propia base de datos propietaria de componentes de OSS que puede variar dramáticamente en términos de tamaño y cobertura
Limitar los datos de vulnerabilidad a la presentación solo de vulnerabilidades oficialmente reportadas en la NVD (que pueden ser meses después de que se descubrió la vulnerabilidad original)
Falta de orientación automatizada sobre las acciones a tomar basándose en informes y datos de SCA
Falta de orientación sobre los requisitos legales de las licencias de OSS detectadas

Véase también
Pruebas de seguridad
Software de código abierto
Vulnerabilidades comunes y expuestas
Licencia de código abierto
Inteligencia de software

Referencias