Garantía continua: una práctica integral para la seguridad de la cadena de suministro de software

Este es el segundo de una serie de artículos que examinan las nuevas directrices NIST SP 800-218. El primer artículo se puede encontrar. esta página.

Aseguramiento Continuo:
Una práctica integral para la seguridad de la cadena de suministro de software

Como comentamos en nuestro artículo anterior, las pautas establecidas por el Instituto Nacional de Estándares y Tecnología (NIST) de EE. UU. alterarán drásticamente la forma en que se suministran los productos y servicios de software al gobierno de los Estados Unidos. 

Específicamente, SP 800-218 del NIST establece un conjunto de prácticas de desarrollo de software seguras de alto nivel que deben integrarse en cada ciclo de vida de desarrollo de software (SDLC). Se espera que la incorporación de estas prácticas a lo largo de la cadena de suministro de software promueva productos y servicios más seguros para su entrega no sólo al gobierno de EE. UU. sino, en última instancia, a todas las industrias y en todo el mundo. 

En este artículo, analizamos el papel fundamental de la Garantía Continua (CA) para cumplir con estos nuevos requisitos. 

Descripción general: ¿Qué es la garantía continua y cómo funciona? 

CA es un concepto y un conjunto de soluciones en desarrollo, complementarios a los conceptos ya familiares de integración continua, desarrollo y pruebas de la disciplina DevOps. CA recopila de forma granular evidencia sobre todos los eventos en el ciclo de vida del desarrollo, incluida la creación del producto y la implementación, que podrían afectar la seguridad del producto de software final. Es un medio para que los consumidores de software (como usuarios, compradores y otras partes interesadas en el riesgo) controlen el riesgo de los productos que utilizan. 

Hoy en día, las empresas aplican una gran variedad de herramientas de seguridad para mejorar la seguridad de los productos de software que desarrollan. Sin embargo, rara vez utilizan una política general para establecer el estándar para el uso consistente de estas herramientas. Además, si los consumidores de productos de software son de otra organización, no tienen la información ni las herramientas necesarias para establecer el nivel de riesgo. En pocas palabras, éste es el punto ciego de la cadena de suministro de software que CA pretende disipar. 

El resultado inmediato de CA es un medio para garantizar que los productos de software no hayan sido manipulados y que se hayan realizado pruebas críticas relacionadas con la seguridad durante el desarrollo, pero se puede ganar más con ello.

Para frustrar la manipulación por parte de atacantes o el encubrimiento de proveedores de componentes ocultos de origen dudoso, como los de países prohibidos, CA convierte la evidencia recopilada en una certificación resistente a la manipulación firmando la información criptográficamente y almacenándola en un almacén inmutable en un entorno seguro y aislado. 

Al hacer que la evidencia recopilada sea legible por máquina, un motor de políticas puede validar continuamente las normas o reglas establecidas por la parte interesada en el riesgo para cada versión o actualización del producto. De esta manera, las partes interesadas pueden estar seguras de que un producto cumple con sus estándares de seguridad. 

Conceptualmente, el uso de la metodología CA también mejora la calidad del producto. Al controlar el estándar básico para la revisión de código y las pruebas de seguridad con una política central para los canales de un producto en particular, se eliminarían las inconsistencias y los cambios ad hoc en los procesos ordenados.

¿Por qué continuo?

Las configuraciones de seguridad en el proceso de desarrollo no son nada nuevo. Por ejemplo, es posible que ya haya establecido que ningún binario pasará a producción sin un escaneo de vulnerabilidades. 

Hoy en día, los ciclos de entrega de software son cada vez más cortos. Como resultado, es posible que se tomen atajos. Es posible que se omita la revisión del código o que no se realicen pruebas de seguridad o procedimientos importantes. Además, todo el tiempo se informan nuevos CVE y exploits y constantemente se publican nuevas versiones de componentes. 

Todos estos factores combinados exigen que probemos continuamente los componentes según el estándar de seguridad establecido para verificar que los procesos utilizados sigan cumpliendo con la política de seguridad. 

Las políticas de seguridad las determina el titular del riesgo. A continuación se muestran algunos ejemplos de reglas de políticas que podrían emplearse: 

• Permitir el uso de paquetes de código abierto únicamente de una lista aprobada
• Requiere dos revisores para cada solicitud de extracción.
• Verifique que todos los componentes propietarios en el artefacto final puedan rastrearse hasta los repositorios de control de fuente.

Elevando el nivel de seguridad del software

Los ataques a la cadena de suministro de software cambian el comportamiento esperado de los componentes de software. Hoy en día, estos ataques se basan en la falta de capacidad tanto de los consumidores como de los productores de software para verificar la integridad de los componentes del software. 

Sin embargo, al firmar evidencia de cada parte del ciclo de vida del desarrollo (desde las dependencias de código abierto hasta el producto final) y comparar continuamente esta evidencia con lo esperado, los atacantes enfrentarán mayores dificultades al intentar alterar archivos, herramientas o el sistema. comportamiento esperado de su canalización de CI/CD.     

Recopilación de pruebas: ejemplos y recomendaciones

A continuación se muestran algunos ejemplos de evidencia que se pueden recopilar a lo largo del SDLC:

Y estos son los tipos de políticas que se pueden utilizar, utilizando esta evidencia:

El futuro de la garantía continua del código

En el marco de desarrollo de software seguro de febrero de 2022 (SSDF), el NIST sugiere que la implementación de herramientas de seguridad en todo el proceso de desarrollo debería depender significativamente de la automatización. Nuestro enfoque de Aseguramiento Continuo es consistente con esta recomendación. 

Incluso si está seguro de que todos los pasos y salvaguardas de seguridad se configuraron correctamente, debe proporcionar los medios para garantizar a los clientes y proveedores que su política de seguridad se ha aplicado de manera consistente y continua. Todas las partes interesadas, productores de software (desarrolladores o proveedores) y consumidores (usuarios o compradores) deberían poder examinar y verificar de forma continua y automática la evidencia de cada eslabón de la cadena de suministro de software para asegurarse de que se cumplan sus propios criterios de seguridad. 

La confianza en la cadena de suministro de software es baja en este momento y esto es una fuente constante de preocupación para todas las partes interesadas. Aumentar la visibilidad de las medidas de seguridad que se han implementado y proporcionar evidencia de Garantía de Código Continua son fundamentales para reconstruir la confianza en la cadena de suministro de software y producir productos verificablemente más seguros.