OWASP SCVS: Reducir los riesgos en la cadena de suministro de software

OWASP SCVS es una metodología útil para prevenir ataques de cadena de suministro a lo largo del ciclo de vida del software

A finales de enero, el ransomware LockBit impactó con éxito en ION Trading UK. Esta empresa suministra software financiero a algunas de las principales compañías de la City londinense, así como a otros bancos y entidades financieras de Estados Unidos y Europa. El ciberataque provocó que diversas aplicaciones de ION no pudieran ser usadas, pasando a tener que operar en el mercado financiero de forma manual. Este incidente puso en jaque el funcionamiento de uno de los mercados financieros más importantes del mundo y visibilizó la gravedad que puede adquirir un ataque de cadena de suministro.

Este incidente de seguridad se suma a una lista creciente de ataques que ponen en valor la importancia de reducir los riesgos en la cadena de suministro de software, recurriendo a servicios de ciberseguridad y al conocimiento y experiencias acumulados en este terreno.

Precisamente, la fundación OWASP, un referente mundial en la generación de conocimiento sobre ciberseguridad, ha lanzado SVCS, un estándar que busca reducir los riesgos en la cadena de suministro de software.

El Software Component Verification Standard (OWASP SCVS) tiene por objetivo recopilar y sistematizar las mejores prácticas llevadas a cabo a nivel global en la securización del software en todo su ciclo de vida, así como en la detección de vulnerabilidades en cualquiera de los componentes que lo conforman.

En este artículo vamos a desgranar las claves de este estándar, así como su utilidad para que las empresas que desarrollan software puedan reducir los riesgos en la cadena de suministro.

1. ¿Qué es OWASP SCVS?

SCVS es un estándar que sigue la senda marcada por un proyecto de OWASP ampliamente aceptado en el sector de la ciberseguridad: Application Security Verification Standard (ASVS), centrado en la seguridad de las aplicaciones.

En este sentido, OWASP SCVS es una prolongación de esta guía que se centra en la securización de los componentes que conforman un software, de cara a reducir los riesgos en la cadena de suministro de software.

Este estándar está diseñado para servir como un punto de partido para aquellas empresas y administraciones públicas que decidan situar la ciberseguridad y la protección de la cadena de suministro de software en el centro de su estrategia.

A este respecto, la fundación OWASP sostiene que las compañías e instituciones que realizan esfuerzos en materia de ciberseguridad para proteger la cadena de suministro de software pueden:

1. Proteger su marca y reputación
2. Aumentar la confianza de los usuarios que emplean sus soluciones
3. Reducir el time-to-market o el tiempo que tarda en salir al mercado, de forma segura, un software
4. Gestionar los costes económicos, legales y reputacionales asociados a un incidente de seguridad provocado por un ataque de cadena de suministro.

Al igual que sucede con otras metodologías de OWASP, el SCVS está diseñado para poder ser implementado por niveles. De tal forma que la ejecución de los controles de verificación puede ser paulatina y ajustarse a los recursos y necesidades de cada organización, para ayudarla a mitigar los riesgos en la cadena de suministro de software.

2. Niveles de verificación de los componentes de software

Como venimos de señalar, SCVS opera de la misma manera que otros estándares de OWASP como ASVS o MASVS (Mobile Application Security Verification Standard). La guía de SCVS propone tres niveles de implementación del estándar. Los cuales funcionan de forma acumulativa. Es decir, los requerimientos de seguridad que se señalan para el nivel 1 se deben implementar también en el nivel 2 y 3.

De tal forma que las compañías que opten por el nivel 1 deberán cumplir los requisitos de seguridad básicos para mitigar los riesgos de la cadena de suministro de software. Mientras que las organizaciones que apuesten por el nivel 3, tendrán que asegurarse de que cumplen todos los requerimientos de verificación de cada control.

• Nivel 1. Está centrado en aplicar las mejores prácticas en el desarrollo y vigilancia de software. Por ejemplo, contar con un catálogo detallado de los componentes y materiales de software empleados.
• Nivel 2. Este nivel está pensado para compañías que disponen de un marco de gestión de riesgos de seguridad. Y que, además, deban cumplir con requisitos normativos más rigurosos y tengan que garantizar la seguridad de su software ante sus clientes. Este nivel no solo se centra en aspectos técnicos, sino que incluye el papel que juegan otros departamentos como el legal.
• Nivel 3. El máximo nivel de verificación de SCVS es el más idóneo para las infraestructuras críticas y sistemas de seguridad más avanzados. Con este nivel se busca conseguir la auditabilidad de la cadena de suministro de un extremo a otro de la misma.

2.1. Diseñar una estrategia adaptada a las necesidades de cada empresa

Cabe señalar que la acción combinada de niveles y controles de verificación permite a las empresas diseñar su estrategia de protección de la cadena de suministro de software a la carta empleando el estándar OWASP SCVS.

Así, una compañía puede implementar un control optando por el nivel 2 de seguridad, porque aborda un área de vital importancia a nivel técnico y de negocio. Pero, en cambio, implementar solo el nivel 1 en otro control menos relevante.

Al fin y al cabo, todas las empresas y administraciones cuentan con unos recursos limitados. El estándar SCVS, al igual que otros estándares de OWASP tiene muy presente esta cuestión. De ahí que sea de gran utilidad para sentar las bases de una estrategia de ciberseguridad que sea eficaz a la hora de securizar la cadena de suministro de software, atendiendo tanto a los componentes y procesos de origen, como al software de terceros o los componentes de código abierto.

3. Controles de verificación

Como ya adelantamos al abordar los niveles de verificación, los controles se articulan en torno a una serie de requerimientos que se deben comprobar. Por ejemplo, el Control 1 (Inventario) está conformado por 10 requerimientos. Las compañías que opten por el nivel 1 de SCVS tendrán que implementar cinco de estos requisitos. Las empresas que apuesten por el nivel 2, seis. Y, finalmente, las organizaciones más avanzadas deberían garantizar el cumplimiento de los 10 requerimientos.

3.1. Inventario

A la hora de poner en marcha una estrategia para securizar un software a lo largo de su ciclo de vida es fundamental comenzar por la realización de un inventario.

Resulta imprescindible contar con un inventario preciso en el que figuren todos los componentes empleados en el software. Solo así se podrán analizar los diferentes componentes para buscar vulnerabilidades explotables por los ciberdelincuentes.

El inventario realizado por una compañía o institución no debe tener en cuenta solo los componentes que pertenecen a la organización porque los ha creado ella. Sino que es fundamental, también, incluir los componentes de los proveedores de software, así como los componentes de código abierto.

Solo así se puede incrementar el nivel de transparencia y auditabilidad de la cadena de suministro y realizar auditorías para detectar riesgos y amenazas.

3.2. SBOM

Los SBOMS son listas de materiales de software, que no solo constituyen un inventario como el que abordamos en el primer control de OWASP SCVS. Sino que incluyen información de vital importancia sobre los componentes del software como la licencia, los números de versión o los datos del proveedor que los creó.

¿Por qué es importante? Pensemos, por ejemplo, en un caso archiconocido, el ciberataque Log4Shell que logró vulnerar el componente Log4j empleado en miles de software en todo el mundo. Si una empresa puede saber con facilidad en qué aplicaciones ha usado un componente vulnerable, podrá hacer frente al incidente de seguridad con prontitud y eficacia.

Dada la relevancia de los SBOMS, OWASP SCVS pone el foco en las ventajas de que las empresas sean capaces de crear automáticamente SBOMS en el proceso de compilación, incrementando así su nivel de madurez en los procesos de desarrollo. Precisamente, ese nivel de madurez, hace que el requerimiento de automatización del SBOM (2.2.) solo sea aplicable para los niveles 2 y 3 de verificación de la cadena de suministro de software.

Asimismo, SCVS indica, también, que es fundamental que las listas de materiales de software estén en un formato legible por una máquina. De cara a garantizar que el SBOM se analiza continuamente en búsqueda de riesgos en la cadena de suministro de software (2.8. aplicable a todos los niveles).

Otro aspecto a destacar es la necesidad de que el SBOM no solo disponga de un inventario completo de todos los componentes perfectamente descritos (2.9.), sino también que dichos componentes cuenten con su respectiva información de licencia (2.14.). Ambos requerimientos también deben ser tenidos en cuenta en los tres niveles de verificación.

3.3. Entorno de compilación

El tercer control de OWASP SCVS es clave para securizar la cadena de suministro de software en uno de sus puntos más importantes: la propia creación de las soluciones.

En las cadenas de creación de software pueden entrar en juego repositorios de código, repositorios de paquetes, procesos de integración continuos, la infraestructura de red… Por ello es fundamental securizar cada uno de los sistemas que participan en la cadena, puesto que una vulnerabilidad en cualquiera de ellos puede abrir una puerta de entrada para un ciberataque contra el software.

Defectos, errores, malas configuraciones… Todas estas cuestiones pueden comprometer la seguridad de la cadena de suministro de software. De ahí que este control busque ayudar a las compañías a endurecer los sistemas implicados en la creación de software.

Para ello, OWASP SCVS establece hasta 21 requerimientos de verificación. Seis de ellos están pensados para que sean adaptados, también, por las compañías que opten por el nivel 1 del estándar. Como, por ejemplo, la necesidad de que la aplicación use un canal de compilación de integración continua (3.3.) o que todas las manipulaciones del código fuente o de los binarios que se llevan a cabo a lo largo del proceso de compilación son conocidas y están bien definidas (3.17).

3.4. Gestión de paquetes

Maven, .NET, Python… existen repositorios centralizados de componentes de código abierto para muchos sistemas de compilación.

Ello no quita que sea conveniente contar con repositorios internos dentro de una empresa, tanto para facilitar la reutilización de los componentes de origen, como para tener un mejor acceso a componentes de proveedores en los que la empresa confíe.

De ahí que sea relevante, a la hora de reducir los riesgos de la cadena de suministro, prestar especial atención a los gestores de paquetes.

OWASP SCVS advierte de que, a pesar de que el uso de gestores de paquetes y repositorios centralizados trae consigo indudables ventajas tanto económicas, como técnicas, como de seguridad, es fundamental establecer una serie de buenas prácticas para reducir al máximo los riesgos de la cadena de suministro de software.

Este control de verificación contempla hasta 19 requerimientos. Algunos son de tipo básico, aplicados a todos los niveles de SCVS, como la necesidad de verificar que los contenidos de los repositorios de paquetes son congruentes con un punto de origen de componentes de código abierto autorizado (4.2.). Mientras que otros están pensados para las compañías más maduras en el terreno de la ciberseguridad, como el hecho de que el repositorio de paquetes notifique de forma automática los incidentes de seguridad que afectan a los componentes que contiene (4.7.).

3.5. Análisis de componentes

Este control, como su propio nombre indica, consiste en realizar un análisis para identificar los posibles riesgos asociados a emplear componentes de software de proveedores o de código abierto. La propia guía de SCVS resume la cuestión con la siguiente frase: «cada componente, directo o transitivo, es un candidato para el análisis».

Este análisis de los componentes que no tienen su origen en la propia empresa es clave para detectar vulnerabilidades que puedan dar origen a un ataque de cadena de suministro.

3.5.1. Aspectos centrales

OWASP SCVS pone el foco en seis grandes cuestiones a tener en cuenta a la hora de realizar un análisis de componentes para detectar vulnerabilidades en la cadena de suministro de software:

• Vulnerabilidades conocidas. Es fundamental tener en cuenta las vulnerabilidades detectadas a nivel global.
• Versión de los componentes. Las versiones de los componentes que se emplean permiten saber si estos se encuentran desfasados o, incluso, si ya han llegado al final de su ciclo de vida. Resulta evidente que componentes que se encuentren en estas circunstancias son más proclives a presentar vulnerabilidades.
• Tipos de componentes. Librerías, frameworks, aplicaciones, contenedores… Estas tipologías son muy comunes en el desarrollo software y presentan desafíos y riesgos diferentes entre sí, que se deben tener en cuenta para securizar la cadena de suministro de software.
• Funciones de los componentes. Cada componente de un software tiene una función. Si se auditan bien es posible detectar aquellos que están duplicados o que se emplean para realizar la misma función. Eliminar los componentes innecesarios permite reducir riesgos que son, también, innecesarios.
• Cantidad de componentes. Los costes de mantenimiento crecen cuando se adopta un nuevo componente y también aumenta la dificultad de llevar a cabo las tareas de mantenimiento.
• Licencias. El software de proveedores y de código abierto se publica bajo licencias. Estas licencias recogen los tipos de uso, las limitaciones a la hora de distribuir estos componentes o cómo se debe actuar si el software se modifica. Es fundamental que estas licencias no entren en contradicción con los objetivos de la empresa.

Este control está conformado por 12 requerimientos que atienden a las cuestiones que venimos de tratar. Y ponen el foco en la automatización de múltiples procesos de identificación de riesgos. Por ejemplo, la identificación de los componentes caducados que se usan (5.6.).

3.6. Pedigrí y procedencia

Conocer con precisión la procedencia de cada componente es clave para actuar en caso de que o el punto de origen u otro elemento de la cadena se vea comprometido. De ahí que los gestores de paquetes internos tengan que disponer de la información sobre los componentes de terceros que se importan.

El pedigrí del software consiste, según el NIST, en la validación de la composición del código abierto y de los componentes de terceros, así como de sus versiones. El pedigrí ofrece certezas sobre la composición interna de cada componente.

Entre los siete requerimientos de verificación de este control, se encuentran requisitos básicos como disponer de la información sobre la procedencia de los componentes modificados (6.3.). Y algunos más avanzados, como verificar que la cadena de custodia es auditable para código fuente y componentes binarios.

4. Verificación continua a lo largo del ciclo de vida del software

Los controles que venimos de desgranar evidencian que, en lo que respecta a la protección de un software frente a los ciberataques, no solo es importante incrementar los controles y mecanismos de seguridad durante su desarrollo. Todas las fases de vida de un software son importantes. Los problemas de seguridad pueden surgir en cualquiera de ellas.

De ahí que el diseño de los controles de OWASP SCVS esté pensado para servir de base a la hora de poner en marcha un sistema de evaluación continua de los riesgos de cadena de suministro de software.

Es más, muchos de los requerimientos del estándar ponen el foco sobre la necesidad de automatizar acciones. Y la aplastante mayoría son automatizables en sí mismos. Esto permite a las empresas gestionar mejor sus recursos y no renunciar a una tarea de verificación continua de todo el ciclo de vida del software.

Además, debemos tener en cuenta la velocidad en la que se producen los cambios tanto en lo que respecta al desarrollo de software, como en lo relativo a la aparición de nuevas técnicas y metodologías de ataque.

Si la composición del software cambia, los sistemas para securizarlo deben estar preparados para evaluarlo continuamente de cara a detectar nuevos riesgos o vulnerabilidades. Las verificaciones únicas, por la contra, solo evalúan la seguridad en un momento concreto. No a lo largo de todo el ciclo de vida del software.

5. Estandarizar la evaluación de proveedores IT

Como hemos podido ver a lo largo del artículo, el estándar OWASP SCVS permite que las empresas diseñen una estrategia integral para reducir los riesgos de cadena de suministro de software. De tal forma que sean capaces de analizar los componentes de origen y procesos internos, pero también el software de sus proveedores.

Precisamente, uno de los objetivos centrales de OWASP SCVS es estandarizar cómo se evalúa a los proveedores de software, de cara a evitar ataques de cadena de suministro que pongan en jaque a la empresa.

La transparencia y la trazabilidad del software contratado es esencial. En este sentido, una compañía que contrata una solución puede solicitarle al proveedor que le facilite un SBOM que permita visualizar los componentes que emplea dicha herramienta. Así como discernir a todos los proveedores que intervienen en un software concreto.

Es más, los controles y requerimientos de verificación de OWASP SCVS se pueden emplear como un baremo para evaluar el nivel de protección y garantías que ofrece un proveedor de software y tomar decisiones empresariales de primer nivel. Desde decidir a qué proveedor se contrata, hasta poner punto y final a una relación con un proveedor que no securiza de forma correcta su solución.

Además, la evaluación de los proveedores no debe limitarse al momento previo a la contratación del software o en un momento en concreto de su ciclo de vida. El estándar OWASP SCVS permite supervisar los riesgos de una solución de forma continua, más allá de las notificaciones de incidencias o las actualizaciones de seguridad que lleve a cabo el proveedor. Esto es crucial para exigir a los proveedores la corrección de vulnerabilidades en un plazo adecuado, de cara a evitar que dichas brechas de seguridad sean aprovechadas por los actores maliciosos.

6. Política de código abierto

Aunque en la elaboración de los controles de SCVS no se incorporó la cuestión del código abierto como un control en sí mismo, esta materia está muy presente a lo largo del estándar, siendo una cuestión transversal a diversos controles.

Aún así, dada su relevancia, la guía recomienda, al final, que las compañías que emplean código abierto en su software dispongan de una política de código abierto para sistematizar su uso y verificar su seguridad.

Esta política de código abierto debe abordar cuestiones de capital importancia en esta materia como:

• La antigüedad de cada componente.
• El número de revisiones mayores o menores que son aceptables de un componente.
• La actualización continua de los componentes, recurriendo a la automatización de esta tarea.
• Los criterios de exclusión de componentes que presenten vulnerabilidades conocidas.
• El tiempo medio que se puede tardar en reparar un componente de riesgo a través de una actualización del mismo.
• Las restricciones de uso de aquellos componentes que han llegado al final de su ciclo de vida o que carecen de soporte técnico.
• Los criterios de selección o exclusión de proveedores de software.
• El listado de licencias aceptables, de acuerdo a su uso.
• El inventario de los componentes prohibidos.
• Los mecanismos para traspasar las modificaciones a la comunidad de código abierto que ha producido el componente.

En definitiva, OWASP SCVS es una metodología de gran ayuda para las compañías que desean securizar la cadena de suministro de su software y protegerse frente a los ciberataques. Este estándar permite priorizar los recursos de una organización y poner el foco en los aspectos más relevantes para mitigar las vulnerabilidades de un software y de sus componentes a lo largo de todo su ciclo de vida.