¿Qué es el análisis de la composición del software (SCA)?

¿Cuáles son los riesgos de utilizar componentes de código abierto?

Antes de construir imágenes de contenedor con estos componentes, los desarrolladores deben ser conscientes de los problemas de seguridad derivados de las vulnerabilidades descubiertas previamente en los paquetes. También tienen que asegurarse de que están cumpliendo los requisitos relativos a las licencias de uso de software.

Los miembros de la comunidad encuentran y parchean vulnerabilidades con frecuencia, pero la carga de actualizar su código recae en los desarrolladores. Cuando se encuentra una vulnerabilidad, es sólo cuestión de tiempo que se haga público un exploit, lo que abre la puerta a que incluso los atacantes de bajo nivel se aprovechen del problema.

El problema se agrava por el hecho de que la mayoría de las vulnerabilidades del software no se encuentran en los paquetes inmediatos o raíz, sino en las dependencias de las dependencias, a varias capas de profundidad. Arreglar sólo los paquetes raíz en uso no siempre asegurará las bibliotecas en uso.

Además, existen docenas de licencias de código abierto con una gran variedad de normas. Por ejemplo, algunos exigen la atribución mientras que otros requieren que también se publique el código fuente de la aplicación que utiliza el componente. Hacer un seguimiento de todas las licencias y sus normas puede resultar difícil.

El análisis de la composición del software identifica los riesgos en los paquetes de código abierto

Las herramientas SCA identifican todos los paquetes de código abierto de una aplicación y todas las vulnerabilidades conocidas de esos paquetes. Este conocimiento puede utilizarse para notificar a los desarrolladores los problemas de su código para que los solucionen antes de que sean explotados. Un buen proceso de análisis de la composición del software mirará más allá de los administradores de paquetes hacia la infraestructura como código (IaC) y los manifiestos de Kubernetes, extrayendo imágenes para identificar vulnerabilidades en esas imágenes.

Las herramientas SCA con conexiones a plantillas IaC y el escaneado ilimitado de dependencias garantizan que las vulnerabilidades no pasen desapercibidas ni queden sin resolver.

Las herramientas de análisis de composición de software también pueden utilizarse para generar una lista de materiales de software (SBOM o software BOM) que incluya todos los componentes de código abierto utilizados por una aplicación. El SBOM enumera los detalles sobre la versión del paquete, así como las vulnerabilidades conocidas y las licencias de cada componente en uso. Por ejemplo, para Python, la lista de materiales incluirá todos los paquetes en las declaraciones de importación, como httplib2, junto con el número de versión, las vulnerabilidades descubiertas y las licencias de cada paquete.

Los programas de SCA deben permitir la colaboración entre las partes interesadas, como los equipos de ingeniería, DevOps, seguridad y cumplimiento. Muchas organizaciones utilizarán estos programas para crear alertas y/o bloquear la fusión de código en repositorios si dicho código incluye componentes de código abierto que violan los mandatos de cumplimiento de la organización para controlar la exposición. La determinación de un nivel de gravedad aceptable para las vulnerabilidades y los tipos de licencia debe implicar a las partes interesadas pertinentes.

Cómo utilizar el SCA en los procesos de desarrollo

Un buen proceso de SCA está integrado en todo el proceso de desarrollo. Comenzando en entornos locales, los desarrolladores necesitan poder comprobar su código en busca de vulnerabilidades y el cumplimiento de la licencia a medida que lo escriben.

Aprovechando los complementos de los entornos de desarrollo integrados (IDE), las herramientas SCA pueden notificar a los desarrolladores las vulnerabilidades a medida que añaden paquetes. Antes de confirmar el código en un repositorio, las comprobaciones y los comentarios automatizados de las solicitudes de extracción deben informar a los desarrolladores de cualquier problema que se introduzca y bloquear el código que no cumpla los requisitos.

Esto debería trasladarse a las implementaciones en las que se puede bloquear el despliegue de software con niveles predeterminados de vulnerabilidades o tipos de licencias. Los equipos de seguridad también deben tener una amplia visibilidad de la postura de los componentes de su entorno.

El análisis de la composición del software amplía la cobertura del código a la nube y de la infraestructura a las capas de aplicación para rastrear las vulnerabilidades a lo largo del ciclo de vida del desarrollo.

En todos los ámbitos, los desarrolladores deben ser informados de los riesgos a los que los paquetes pueden exponerles. Las vulnerabilidades deben clasificarse y priorizarse (por ejemplo, utilizando las puntuaciones CVE y el tiempo transcurrido desde que se informó de la vulnerabilidad) en función de la criticidad y los impactos en la infraestructura (por ejemplo, si el paquete vulnerable se encuentra en una VPC privada). Las licencias deben agruparse por aquellas permitidas pero que requieren detalles adicionales, como la atribución, y las que no están permitidas por las políticas de la organización, como las licencias " copyleft".

Las ventajas del análisis de la composición del software

Es importante que los equipos sean conscientes de la postura de sus entornos de aplicación. Al proporcionar información sobre el cumplimiento de las licencias y las vulnerabilidades de forma temprana y frecuente, el análisis de la composición del software ayuda a mitigar algunos de los riesgos de utilizar componentes de código abierto en las aplicaciones. Aunque las tasas de parcheo del 100% son improbables, conocer el riesgo y sopesar el costo de solucionar una vulnerabilidad forma parte de la mejora de la postura de seguridad.

Para saber más sobre la seguridad de los procesos de desarrollo modernos, consulte ¿Qué es DevSecOps?.

Preguntas frecuentes sobre el análisis de la composición del software