Lo que debe hacer para alcanzar los niveles de SLSA: una guía muy práctica

Antecedentes

SLSA (Niveles de cadena de suministro para artefactos de software) es un marco de seguridad que tiene como objetivo evitar la manipulación, mejorar la integridad y proteger los paquetes y la infraestructura. El concepto central de SLSA es que sólo se puede confiar en un artefacto de software si cumple con tres requisitos:

1. El artefacto debe contar con un documento de Procedencia que describa su origen y proceso de construcción (L1).
2. El documento de procedencia debe ser confiable y verificado posteriormente (L2).
3. El sistema de construcción debe ser confiable (L3).

El marco SLSA define niveles, que representan qué tan segura es la cadena de suministro de software. Estos niveles corresponden al nivel de implementación de estos requisitos (indicados como L1-L3 arriba).

escribano valint slsa El comando se puede utilizar para producir documentos de procedencia. A continuación, describimos cómo alcanzar niveles de SLSA mediante el uso de esta herramienta.

Nota: Aquí nos referimos al marco SLSA V1.0.

SLSA L1

El requisitos para SLSA L1 incluye:

• Los productores de software siguen un proceso de construcción consistente.
• La plataforma de construcción genera automáticamente datos de procedencia que describen cómo se construyó el artefacto.
• Los productores de software distribuyen datos de procedencia a los consumidores.

Lista de verificación para lograr SLSA L1:

• Cree su software utilizando un sistema CI. Preferiblemente utilice un script de compilación que esté controlado por el código fuente.
• activar el valint slsa comando como parte de su script de compilación para crear un documento de procedencia. Note que el valint slsa  El comando permite agregar información adicional al documento de procedencia; puede adaptar el contenido del documento de procedencia a sus necesidades.

SLSA L2

El requisitos para SLSA L2 incluye:

• Los requisitos de SLSA L1.
• La compilación se ejecuta en una plataforma de compilación alojada que genera y firma la procedencia misma.
• La verificación posterior de la procedencia incluye la validación de la autenticidad de la procedencia.

Lista de verificación para lograr SLSA L2:

• La lista de verificación SLSA L1.
• Utilice un servicio de compilación alojado (en lugar de realizar la compilación en la máquina del desarrollador).
• Cree un documento de procedencia firmado (en lugar de uno sin firmar, que es suficiente para SLSA L1). Esto se puede lograr ejecutando valint slsa ... -o attest. escribano valente La herramienta tiene un amplio conjunto de capacidades de firma; para una empresa, recomendamos utilizar claves y certificados PKI X.509. 
• Verifique la autenticidad del documento de procedencia en sentido posterior utilizando el valint verifydominio. La verificación puede incluir firma e identidad de firma, así como otras reglas de verificación que aseguren el contenido del documento de procedencia SLSA. Algunos ejemplos se pueden encontrar en Scribe's catálogo de pólizas.

Nota: La verificación debe realizarla el consumidor del software creado; Para el cumplimiento interno, la verificación se puede realizar como parte de un proceso de prueba.

SLSA L3

Requisitos de SLSA L3

El requisitos para SLSA L3 incluye:

• Los requisitos de SLSA L2.
• La plataforma de compilación implementa controles estrictos para:
  • Evite que las ejecuciones se influyan entre sí, incluso dentro del mismo proyecto.
  • Evite que se pueda acceder a los secretos utilizados para firmar la procedencia desde los pasos de compilación definidos por el usuario.

Además, para confiar en la plataforma de construcción, es necesario verificar la plataforma de construcción. Se debe confiar en la plataforma de construcción en el sentido de que el documento de procedencia será infalsificable y la construcción será aislado. De dicha verificación se derivan los siguientes requisitos:

• Comprueba eso el uso de la plataforma no se rompe la inforjabilidad y el aislamiento • Requisitos.
  • La verificación del aislamiento, por ejemplo, se puede realizar evaluando el uso de la memoria caché en la canalización.
  • Para garantizar la infalsificación del documento de procedencia, recomendamos generarlo y firmarlo en un proceso de compilación dedicado.
• Verificar el confiabilidad de la plataforma de construcción.
  •  Para los CI SaaS, se debe realizar una verificación con el proveedor de la plataforma de compilación. En los casos en que el productor de software sea responsable de la implementación del sistema de compilación, se recomienda una combinación de autocertificación del proveedor y la realización de un análisis de los aspectos de la implementación.
  • Por ejemplo, al implementar un CI autohospedado, la certificación del proveedor debe declarar cómo se aíslan las compilaciones entre sí, y el análisis de la implementación debe verificar los permisos de acceso y la auditoría de registros del sistema de CI.

Estos requisitos son un desafío porque satisfacerlos depende de la plataforma de CI, no se puede automatizar completamente y requiere un análisis de seguridad profesional de los sistemas y canalizaciones de compilación. Es por eso que el marco SLSA sugiere específicamente que las organizaciones evolucionen gradualmente desde el cumplimiento de SLSA L2 al cumplimiento de SLSA L3.

Si leyó este artículo hasta aquí y decidió que SLSA L3 es lo correcto para usted, arremangarse: aquí está nuestra recomendación para una lista de verificación:

Lista de verificación para lograr SLSA L3:

• La lista de verificación SLSA L2.
• Evaluar el sistema de CI. El objetivo es responder las siguientes preguntas:
  • ¿Bajo qué condiciones puede una entidad no autorizada evadir el sistema de construcción?
  • ¿En qué condiciones las construcciones pueden afectarse entre sí?

Una vez respondido, gestione los riesgos restantes.

• Aislar la generación del documento de Procedencia:
  • Separe la creación del documento de procedencia en una canalización diferente, preferiblemente en un servicio de compilación independiente.
    • Exponer a esta canalización únicamente los secretos utilizados para firmar el documento de Procedencia.
    • Cree o verifique el contenido del documento de procedencia en esta canalización. En el caso de la verificación, verifique todos los campos posibles de un documento de procedencia generado en proceso con datos recopilados directamente de la plataforma de compilación o de otras fuentes confiables.
• Aísle y verifique el aislamiento de la canalización de compilación de otras ejecuciones de canalización:
  • Verificar el uso de cachés y volúmenes compartidos.
  • Verifique que los secretos compartidos con otras canalizaciones no permitan que las canalizaciones se afecten entre sí.
  • Verificar que las ejecuciones de canalización no puedan afectarse entre sí
    • Por ejemplo, evitar que las instalaciones realizadas a través de una tubería afecten a otros tramos de tubería. Esto se puede hacer utilizando ejecutores de compilación efímeros (como un contenedor que se crea para cada compilación) o verificando que los ejecutores de compilación comiencen cada vez desde un estado predeterminado.

Para lograr SLSA L3 con herramientas Scribe, recomendamos lo siguiente:

• Instrumente la canalización de compilación para generar todas las certificaciones que serán necesarias para completar el documento de procedencia. Por ejemplo, puede decidir que desea una lista de las dependencias instaladas durante la compilación. Esta lista puede ser generada por un valint bom dir:dominio. Además, cree una atestación de procedencia en proceso utilizando el valint slsa mando.
• Cree una canalización independiente de generación de procedencia confiable que realizará lo siguiente:
  • Genere un documento de procedencia confiable basado en el creado en el proceso de compilación;
    • Recopile datos del servicio de compilación y utilícelos para verificar y actualizar el documento de procedencia.
    • Verifique el contenido de las certificaciones creadas en la canalización de compilación. Por ejemplo, verifique el contenido del ejecutor de compilación comparando una atestación de SBOM de la canalización de compilación con una atestación de SBOM que se muestreó por separado.
    • Utilice las certificaciones recopiladas del proceso de compilación para actualizar el documento de procedencia.
    • La actualización del documento de procedencia se puede realizar utilizando el valint slsa mando.
  • Verifique que la compilación se aisló evaluando los datos recopilados del servicio de compilación. Por ejemplo: verificar el uso de cachés y secretos.

Para realizar dicha recopilación y evaluación de datos, Scribe proporciona herramientas que crean certificaciones de la ejecución de la compilación y realizan las verificaciones necesarias.

---

Está bien. Parece que ya está todo listo para comenzar. Por supuesto, si necesita ayuda, háganos saber. Estamos aquí para ayudar y nos encantaría asesorar o ayudar activamente.

Artículos relacionados con

SPDX vs. CycloneDX: formatos SBOM comparados

A pesar de la creciente adopción de la Lista de materiales de software (SBOM) para que sirva como herramienta de gestión de vulnerabilidades y ciberseguridad, muchas organizaciones todavía tienen dificultades para comprender los dos formatos SBOM más populares que se utilizan en la actualidad, SPDX y CycloneDX. En este artículo, compararemos estos dos formatos para ayudarlo a elegir el adecuado para […]

Cómo Scribe Security se alinea con la Guía para líderes de Gartner sobre seguridad de la cadena de suministro de software

El 20 de junio de 2024, Gartner publicó su influyente Guía del líder sobre seguridad de la cadena de suministro de software, en la que se destaca la creciente necesidad de defenderse de los ataques a la cadena de suministro de software. Con la creciente frecuencia y sofisticación de estos ataques, las organizaciones se enfrentan a riesgos importantes que deben gestionar de forma eficaz. Esta publicación interpreta los hallazgos críticos del informe de Gartner. Explica cómo Scribe […]

Comparación de ASPM y CSPM: comprensión de las diferencias y aplicaciones

Es de vital importancia proteger los entornos y aplicaciones de la nube dado que el mundo es ahora una aldea global. Dos soluciones que son fundamentales para estos fines en las organizaciones son Application Security Posture Management (ASPM) y Cloud Security Posture Management (CSPM). Cada uno realiza una función de seguridad, aunque cumplen esa función en diferentes entornos y […]