A medida que todo el mundo se vuelve cada vez más consciente, protegiendo sus cadenas de suministro de software debería ser una parte vital de la estrategia de seguridad cibernética de cada organización.
Una de las principales dificultades para crear una estrategia integral para mitigar las amenazas a la cadena de suministro de software es la complejidad y diversidad de las cadenas de suministro. Cada cadena de suministro es única y los elementos involucrados cambian constantemente, lo que dificulta confiar en su propia cadena de suministro, y mucho menos en el software que produce.
En este artículo, describiremos una plataforma de cumplimiento continuo que permite a los consumidores y productores de software demostrar de forma transparente confianza y cumplimiento para proteger SDLC, promover las mejores prácticas de seguridad, cumplir con los requisitos regulatorios y mitigar riesgos cibernéticos usando apruebas.
Nuestro modelo propuesto consta de bloques establecidos que se pueden ampliar e integrar fácilmente en su pila, independientemente de su plataforma preferida o casos de uso. Terminaremos demostrando una política de verificación básica usando Herramienta Valint de Scribe para demostrar que este proceso no es tan complicado como podría temer.
Teoría del caos en la cadena de suministro
Uno de los principales desafíos para asegurar las cadenas de suministro es la enorme complejidad de los sistemas involucrados. Su cadena de suministro de software incluye cada pieza de software involucrada en la creación de su producto final, ya sea como parte del entorno o como una pieza de software integrada en su código base. Por esta descripción se puede ver que estas cadenas de suministro son amplias e incluyen todo, desde el momento en que un desarrollador comienza a escribir código hasta la compilación, prueba, integración y hasta el punto en que el producto final se ejecuta e incorpora cada pieza de software y biblioteca utilizados a lo largo del camino.
Definir el modelo de seguridad para tales sistemas requiere comprender la amplia gama de programas lenguajes, administradores de paquetes, productos, pilas de tecnología, servicios de CI, proveedores de nube, importaciones de dependencias, máquinas virtuales, sistemas operativos y otros componentes que pueden incluirse en una cadena de suministro determinada. Es esencial considerar la amplia gama de activos que podrían estar en riesgo dentro de dicho sistema, incluidas aplicaciones, tokens, claves y otras formas de permisos de acceso.
Descripción general del modelo de verificación de políticas
Nuestro modelo propuesto incluye varios componentes básicos que trabajan juntos para garantizar la seguridad y el cumplimiento de una cadena de suministro.. Estos componentes básicos son necesarios para verificar continuamente los aspectos de seguridad del software y el cumplimiento de la regulación de la cadena de suministro de software.
- Evidencia: objetos inmutables que las políticas deben consumir automáticamente. Estos objetos contienen metadatos necesarios para permitir la aplicación de políticas y cumplir con los requisitos de cumplimiento. El contenido de evidencia incluye metadatos sobre artefactos, eventos y configuraciones, pero también puede recopilar informes, configuraciones o análisis reales.
Evidencia Puede venir tanto firmado como sin firmar. Sugerimos seguir la in-toto especificación de atestación utilizando el firmado certificación y sin firmar ambiental formatos, respectivamente.- Atestiguaciones (también conocidas como evidencia firmada verificable): Evidencia verificable vinculada a un determinado contexto ambiental, transmitiendo confianza mediante algún tipo de firmas PKI.
- Contexto ambiental: La información contextual une el modelo.
Responde a la pregunta de dónde proviene la evidencia y qué información contiene. Es importante que el contexto esté vinculado a la evidencia en lugar de ser parte de ella, ya que puede tener múltiples piezas de evidencia vinculadas al mismo contexto y este modelo permite una búsqueda y recuperación de evidencia más fácil y eficiente.
En términos básicos, un contexto ambiental es un sistema de etiquetado donde la mayoría de las etiquetas se leen desde el entorno, la plataforma o los artefactos. Las etiquetas brindan acceso normalizado a muchos procesos de su proceso de desarrollo y canalización de CI/CD. Aspectos relacionados con el origen de las pruebas, como repositorios Git, etiquetas y confirmaciones, pero también nombres de flujos de trabajo, nombres de trabajos, runID, etc. El contexto ambiental también puede incluir aspectos del tema, como hashes, nombres y etiquetas de artefactos.
El contexto puede verse como una extensión del in-toto. Especificaciones de atestación, integrado en la carga útil firmada. Utilizando el sistema de etiquetado, podemos proporcionar a la fase de evaluación de políticas una forma de consultar la evidencia mediante etiquetas en una variedad de aspectos. Además, los datos del contexto se pueden utilizar como parte del proceso de evaluación de políticas, añadiendo “conciencia situacional” a la evidencia.
- Políticas: Un conjunto de módulos de políticas configurados por el usuario que definen el informe de cumplimiento requerido. Las políticas pueden especificar los estándares mínimos de seguridad o los niveles requeridos de cumplimiento para diferentes tipos de productos o sistemas incluidos en su canal de compilación o su proceso de desarrollo. Lo más importante es que las evaluaciones de políticas resultantes crean informes de cumplimiento que son atestaciones también. Esto nos permite no solo gestionar los informes de cumplimiento (por ejemplo, exponer su estado de cumplimiento a las partes interesadas) sino también utilizar el informe de cumplimiento para políticas más complejas que pueden encapsular un alcance más amplio de la regulación de cumplimiento para una organización. Las políticas se pueden agrupar en módulos de políticas. Estos son complementos que implementan conjuntos de reglas de políticas que comparten algunas características (similares a los módulos de software). Estos complementos los proporcionan los proveedores de políticas (más sobre esto más adelante).
La evaluación de un módulo de política proporciona resultados que incluyen valoraciones, detalles de cumplimiento y veredictos referentes a la norma de seguridad en cuestión. Además, los resultados incluyen el historial de evidencia necesario para rastrear el módulo de evidencia evaluado para determinar su cumplimiento. - Tiendas: Servicios que proporcionan alojamiento, carga/descarga y capacidades de consulta de evidencia (más sobre esto más adelante). Se pueden utilizar a través de registros de imágenes (OCI como almacenamiento), servicios dedicados (es decir, Scribe Service) o simplemente el sistema de archivos local.
- Proveedores de pólizas: Se trata de entidades (empresas, organizaciones) responsables de firmar y proporcionar módulos de políticas. Al proporcionar políticas como un tipo de certificación, los proveedores transmiten confianza y transparencia a la política misma. Por ejemplo, una atestación de paquete OPA puede permitir a los reguladores publicar y firmar paquetes oficiales de OPA que implementen módulos de políticas.
Al utilizar estos componentes básicos, nuestro modelo permite a las organizaciones verificar la seguridad y el cumplimiento de sus procesos de construcción y su ciclo de vida de desarrollo con relativa facilidad.
¿Como funciona?
El punto de partida de este flujo de trabajo es un desarrollador o un sistema que genera evidencia para un producto o componente de software. El contenido de la evidencia, así como la información contextual, los sujetos y las firmas, se recopilan y cargan en un almacén de evidencia.
Por otro lado, los informes de cumplimiento se crean evaluando políticas ajustadas a las necesidades y requisitos de la organización.
Utilizando información contextual, las evaluaciones de políticas pueden consultar la evidencia producida por su cadena de suministro y garantizar que contengan toda la información que la regulación pueda requerir..
Como beneficio adicional, las políticas y los informes de cumplimiento son en sí mismos accesibles como evidencia, lo que brinda transparencia y confianza, así como un historial de todas las evidencias involucradas. Esto permite a las organizaciones gestionar informes de cumplimiento, pero también utilizarlos como certificaciones confiables para transmitir confianza a los consumidores de software..
Al utilizar este flujo, las organizaciones y las partes interesadas pueden reducir el riesgo, brindar transparencia y garantizar el cumplimiento dentro de su cadena de suministro, reduciendo el impacto del caos y mejorando la seguridad general y la confianza en sus productos.
Evaluación de políticas
El evaluación La definición de una política se realiza verificando un conjunto de módulos de políticas, cada uno de los cuales cumple con regulaciones y necesidades de cumplimiento específicas.
Una evaluación de políticas plantea a cada módulo dos preguntas sencillas:
- ¿Qué evidencia se requiere para cumplir con el módulo?
- ¿Cuáles son los criterios para que las pruebas demuestren el cumplimiento?
Por ejemplo, en el contexto de la Marco SLSA (Niveles de cadena de suministro para artefactos de software), los módulos de políticas pueden especificar que se requieren evidencia de procedencia SLSA firmada y un escaneo de la postura de seguridad para la canalización de compilación para cumplir con los requisitos de seguridad. Luego se verificaría la evidencia proporcionada por estos módulos para garantizar que cumple con todos los requisitos de SLSA.
- ¿Qué evidencia se requiere para cumplir con los requisitos de SLSA?
- Una certificación de procedencia SLSA (evidencia firmada) del artefacto construido.
- Escaneo de la postura de seguridad de la canalización de CI que produce el artefacto.
- ¿Cuáles son los criterios para que la evidencia demuestre el cumplimiento de los requisitos de SLSA?
- Ambas pruebas deben incluir información que cumpla con todos los requisitos de SLSA.
Para este ejemplo, la atestación de procedencia SLSA debe describir el proceso de creación de la imagen en su totalidad, mientras que la atestación de postura de seguridad debe verificar que el SCM que almacenó el origen de la imagen utiliza reglas de protección de sucursales.
- Ambas pruebas deben incluir información que cumpla con todos los requisitos de SLSA.
Otro ejemplo de módulo de políticas es el Verificar módulo de artefacto, que especifica que algunos artefactos deben estar firmados por una fuente confiable. Utilizando atestaciones (evidencia firmada verificable) Firma PKI (Infraestructura de clave pública), para cumplir con el requisito de alguna persona/entidad específica que necesita firmar los artefactos y además dar fe del contexto de donde se originaron los artefactos.
El Verificar módulo de artefacto responde las siguientes preguntas:
1. ¿Qué pruebas se requieren para demostrar el cumplimiento de los requisitos de seguridad?
- Evidencia que describe un artefacto que incluye una firma PKI (certificación).
2. ¿Cómo se puede verificar esta evidencia para garantizar el cumplimiento?
- La firma de certificación PKI es válida.
- La identidad del certificado PKI coincide con los requisitos del usuario.
- El tema de la evidencia coincide con los requisitos del usuario.
- El formato y el origen coinciden con los requisitos del usuario.
De la teoría a la práctica
Profundicemos en la implementación de este modelo que actualmente está soportado por la herramienta Valint.
Veamos un ejemplo simple de una política que especifica cómo verificar las firmas y el origen de una imagen.
Específicamente, necesitamos verificar que la evidencia satisface los siguientes criterios:
- El tipo de evidencia es la certificación CycloneDX SBOM que describe una imagen.
- El artefacto está firmado por miempresa.com.
- La imagen se origina a partir de un flujo de trabajo Circle-CI activado por el mi_imagen_src repositorio
Política de plantilla
En el ejemplo anterior, la política era estática y solo buscaba una imagen específica llamada miempresa/mi_imagen. Sin embargo, a menudo es preferible tener políticas que admitan capacidades de plantilla/variable. Esto le permite definir requisitos que se pueden aplicar a múltiples procesos o artefactos similares en su canal de compilación de CI/CD.
Para crear una plantilla para la política, puede utilizar una variable en lugar de bloquear la política estáticamente en un producto. En el ejemplo anterior, puede cambiar el nombre_artefacto valor a `$MI_IMAGEN` en cambio, permitir a los evaluadores configurar una política para una multitud de imágenes que requieren las mismas regulaciones de cumplimiento.
Mirando hacia el futuro
At Escriba, nuestro objetivo final es mitigar los riesgos en la cadena de suministro a través de un modelo de cumplimiento verificable basado en evidencia. Uno de los primeros lugares para probar este modelo es en su canal de compilación de CI/CD. Creemos que este enfoque de verificación de evidencia es la clave para garantizar la transparencia y la rendición de cuentas en la cadena de suministro, con beneficios para todas las partes interesadas involucradas. Nuestro modelo resume muchas de las ideas emergentes en la comunidad de la cadena de suministro de software y define la relación entre muchas de ellas. Estamos comprometidos a innovar y mejorar la transparencia de la cadena de suministro de software. Si este modelo despertó tu interés, te animo a que consultes nuestro Documentación de la CLI de Valint donde ampliamos las capacidades y usos de la herramienta. No dudes en probarlo.
Este contenido es presentado por Scribe Security, un proveedor líder de soluciones de seguridad de la cadena de suministro de software de extremo a extremo, que ofrece seguridad de última generación para artefactos de código y procesos de desarrollo y entrega de código en todas las cadenas de suministro de software. Más información.
Artículos relacionados con
