- 1. ¿Qué es el análisis de composición de software?
- 2. ¿Qué riesgo conlleva usar componentes de código abierto?
- 3. El análisis de composición de software identifica riesgos en paquetes de código abierto
- 4. Cómo usar el SCA en los procesos de desarrollo
- 5. Ventajas del análisis de composición de software
¿Qué es el análisis de composición de software (SCA)?
El análisis de composición de software (SCA) ofrece un análisis en profundidad de los paquetes de código abierto que usa una aplicación. El SCA identifica las vulnerabilidades y las licencias en dependencias para realizar evaluaciones de riesgos y cumplimiento normativo, y puede generar una lista de materiales de software (SBOM) de todos los recursos para compartirla con las partes interesadas internas y los clientes externos.
¿Qué es el análisis de composición de software?
El análisis de composición de software permite a los desarrolladores aprovechar paquetes de código abierto de forma segura y sin exponer a las organizaciones a vulnerabilidades innecesarias ni a problemas legales o de cumplimiento normativo.
El uso de componentes de código abierto para desarrollar software moderno se ha generalizado hasta el punto de que la mayoría de las bases de código de las aplicaciones modernas se componen de paquetes de este tipo. Este método permite a los desarrolladores avanzar más rápido, puesto que pueden usar código de libre acceso y aprobado por la comunidad en lugar de crearlo desde cero. Sin embargo, este proceso también conlleva ciertos riesgos.
¿Qué riesgo conlleva usar componentes de código abierto?
Antes de crear imágenes de contenedor con estos componentes, los desarrolladores deben conocer los aspectos relacionados con la seguridad que pueden ser un riesgo y que se derivan de vulnerabilidades previamente detectadas en los paquetes. También deben satisfacer los requisitos de cumplimiento normativo asociados a las licencias de uso de software.
Con frecuencia, los miembros de la comunidad detectan y crean parches para las vulnerabilidades, pero son los desarrolladores quienes deben encargarse de actualizar su código. Cuando se detecta una vulnerabilidad, es solo cuestión de tiempo que empiece a circular un exploit público, lo que abre la puerta a que incluso quienes perpetran ataques básicos se aprovechen del problema.
El peligro es aún mayor debido a que la mayoría de las vulnerabilidades de software no se encuentran en los paquetes raíz o inmediatos, sino en las dependencias que están varias capas por debajo. Aplicar correcciones a los paquetes raíz en uso no siempre sirve para proteger las bibliotecas en uso.
Además, hay decenas de licencias de código abierto con numerosas reglas diferentes. Por ejemplo, algunas requieren atribuciones, y otras que el código abierto de la aplicación que usa el componente se publique también. Llevar un registro de todas las licencias y sus reglas puede ser una tarea compleja.
El análisis de composición de software identifica riesgos en paquetes de código abierto
Las herramientas de SCA identifican todos los paquetes de código abierto que incluye una aplicación y todas las vulnerabilidades conocidas de dichos paquetes. Esta información puede usarse para avisar a los desarrolladores de los problemas que contiene su código, con el fin de que los corrijan antes de que alguien se aproveche de ellos. Un buen proceso de SCA no se centra solo en los gestores de paquetes, sino que también abarca la infraestructura como código (IaC) y los manifiestos de Kubernetes, y extrae imágenes para detectar las vulnerabilidades que estas puedan contener.
Las herramientas de SCA conectadas a plantillas de IaC y un análisis ilimitado de dependencias permiten detectar y resolver todas las vulnerabilidades.
Las herramientas de SCA también pueden usarse para generar una lista de materiales de software (SBOM o BOM de software) que incluye todos los componentes de código abierto que se usan en una aplicación. La SBOM indica todos los detalles sobre la versión del paquete, así como las licencias y vulnerabilidades conocidas de cada componente en uso. En Python, por ejemplo, la BOM incluirá todos los paquetes en sentencias de importación, como httplib2, además del número de versión y las licencias y vulnerabilidades detectadas de cada paquete.
Los programas de SCA deben posibilitar la colaboración entre las partes interesadas, como los equipos de ingeniería, DevOps, seguridad y cumplimiento normativo. Muchas organizaciones usarán estos programas para crear alertas o evitar que el código se incorpore a los repositorios si incluye componentes de código abierto que infrinjan los requisitos de cumplimiento normativo de la organización que rigen la exposición. Las partes interesadas relevantes deben determinar cuál es el nivel de gravedad aceptable de las vulnerabilidades y los tipos de licencia.
Cómo usar el SCA en los procesos de desarrollo
Un buen proceso de SCA debe integrarse en todas las etapas del desarrollo. Empezando por los entornos locales, los desarrolladores deben ser capaces de comprobar si hay vulnerabilidades en el código y garantizar el cumplimiento normativo de las licencias a medida que lo escriben..
Las herramientas de SCA pueden notificar las vulnerabilidades a los desarrolladores a medida que añaden paquetes mediante complementos de entornos de desarrollo integrados (IDE). Antes de que el código se confirme y llegue a un repositorio, las comprobaciones y los comentarios automáticos sobre solicitudes de incorporación de cambios deben informar a los desarrolladores acerca de los problemas que pueden introducirse e impedir que se añada el código que no cumpla los requisitos.
Esto debe trasladarse también a las implementaciones que tengan software con niveles de vulnerabilidades o tipos de licencias predeterminados cuya implementación puede impedirse. Los equipos de seguridad también deben tener una visibilidad amplia del estado de los componentes del entorno.
El SCA amplía la cobertura del código a la nube y de la infraestructura a las capas de aplicación para hacer un seguimiento de las vulnerabilidades a lo largo del ciclo de desarrollo.
En todas las áreas, los desarrolladores deben recibir información sobre los riesgos a los que pueden exponerles los paquetes. Las vulnerabilidades se deben categorizar y priorizar (por ejemplo, usando puntuaciones según el sistema de vulnerabilidades y exposiciones comunes [CVE] y el tiempo transcurrido desde que se detectó la vulnerabilidad) según su gravedad y repercusiones en la infraestructura (por ejemplo, si el paquete vulnerable se encuentra en una nube privada virtual [VPC]). Las licencias deben dividirse en dos grupos: las que se permiten, pero sobre las que se precisan más detalles (como la atribución), y las que no se permiten de conformidad con las políticas de la organización (como las licencias «copyleft»).
Ventajas del análisis de composición de software
Es importante que los equipos conozcan el estado de sus entornos de aplicaciones. Al proporcionar información sobre las vulnerabilidades y el cumplimiento normativo de las licencias desde el principio y con frecuencia, el SCA ayuda a mitigar algunos de los riesgos de usar componentes de código abierto en las aplicaciones. Aunque es prácticamente imposible aplicar parches al 100 % de las vulnerabilidades, conocer el riesgo y sopesar el coste de corregirlas forman parte del proceso de mejora de la estrategia de seguridad.
Para obtener más información sobre la protección de los procesos de desarrollo moderno, consulte ¿Qué es la filosofía DevSecOps?