Presentamos SLSA, un marco integral para la integridad de la cadena de suministro


Se han producido ataques a la integridad de la cadena de suministro (modificaciones no autorizadas a paquetes de software). en aumento en los últimos dos años, y están demostrando ser vectores de ataque comunes y confiables que afectan a todos los consumidores de software. La cadena de suministro de desarrollo e implementación de software es bastante complicada, con numerosas amenazas a lo largo del flujo de trabajo de origen, compilación y publicación. Si bien existen soluciones puntuales para algunas vulnerabilidades específicas, no existe un marco integral de extremo a extremo que defina cómo mitigar las amenazas en la cadena de suministro de software y proporcione garantías de seguridad razonables. Existe una necesidad urgente de encontrar una solución frente a los reveladores ataques multimillonarios de los últimos meses (p. Ej. Vientos solares, Codecov), algunos de los cuales podrían haberse evitado o dificultado si los desarrolladores de software y los consumidores hubieran adoptado un marco de este tipo.

Nuestra solución propuesta es Niveles de cadena de suministro para artefactos de software (SLSA, pronunciado "salsa"), un marco de trabajo de un extremo a otro para garantizar la integridad de los artefactos de software a lo largo de la cadena de suministro de software. Está inspirado en el "Autorización binaria para Borg”Que ha estado en uso durante los últimos 8 años y es obligatorio para todas las cargas de trabajo de producción de Google. El objetivo de SLSA es mejorar el estado de la industria, particularmente el código abierto, para defenderse de las amenazas a la integridad más urgentes. Con SLSA, los consumidores pueden tomar decisiones informadas sobre la postura de seguridad del software que consumen.

Cómo ayuda SLSA

SLSA ayuda a proteger contra ataques comunes a la cadena de suministro. La siguiente imagen ilustra una cadena de suministro de software típica e incluye ejemplos de ataques que pueden ocurrir en cada eslabón de la cadena. Cada tipo de ataque ha ocurrido durante los últimos años y, desafortunadamente, está aumentando a medida que pasa el tiempo.

Amenaza

Ejemplo conocido

Cómo podría haber ayudado SLSA

A

Envíe el código incorrecto al repositorio de origen

El hipócrita de Linux se compromete: El investigador intentó introducir vulnerabilidades intencionalmente en el kernel de Linux a través de parches en la lista de correo.

La revisión por dos personas detectó la mayoría, pero no todas, las vulnerabilidades.

B

Plataforma de control de fuente de compromiso

PHP: El atacante comprometió el servidor git autohospedado de PHP e inyectó dos confirmaciones maliciosas.

Una plataforma de código fuente mejor protegida habría sido un objetivo mucho más difícil para los atacantes.

C

Construya con un proceso oficial pero a partir de un código que no coincide con el control de fuente

Webmin: El atacante modificó la infraestructura de compilación para usar archivos de origen que no coinciden con el control de origen.

Un servidor de compilación compatible con SLSA habría producido una procedencia que identificara las fuentes reales utilizadas, lo que permitiría a los consumidores detectar dicha manipulación.

D

Plataforma de construcción de compromiso

Vientos solares: El atacante comprometió la plataforma de compilación e instaló un implante que inyectaba comportamiento malicioso durante cada compilación.

Los niveles más altos de SLSA requieren controles de seguridad más estrictos para la plataforma de construcción, lo que hace que sea más difícil comprometerse y ganar persistencia.

mi

Utilice una mala dependencia (es decir, A-H, de forma recursiva)

flujo de eventos: El atacante agregó una dependencia inocua y luego la actualizó para agregar un comportamiento malicioso. La actualización no coincide con el código enviado a GitHub (es decir, el ataque F).

La aplicación de SLSA de forma recursiva a todas las dependencias habría evitado este vector en particular, porque la procedencia habría indicado que no se creó a partir de un constructor adecuado o que la fuente no vino de GitHub.

F

Cargar un artefacto que no fue creado por el sistema CI / CD

CodeCov: El atacante usó credenciales filtradas para cargar un artefacto malicioso en un depósito de GCS, desde el cual los usuarios descargan directamente.

La procedencia del artefacto en el depósito de GCS habría demostrado que el artefacto no se creó de la manera esperada a partir del repositorio de origen esperado.

GRAMO

Repositorio de paquetes de compromiso

Ataques a espejos de paquetes: El investigador ejecutó espejos para varios repositorios de paquetes populares, que podrían haberse utilizado para servir paquetes maliciosos.

De manera similar a lo anterior (F), la procedencia de los artefactos maliciosos habría demostrado que no se crearon como se esperaba o a partir del repositorio de origen esperado.

H

Engañar al consumidor para que use un paquete incorrecto

Browserify typosquatting: El atacante cargó un paquete malicioso con un nombre similar al original.

SLSA no aborda directamente esta amenaza, pero la vinculación de la procedencia con el control de la fuente puede habilitar y mejorar otras soluciones.


Que es SLSA

En su estado actual, SLSA es un conjunto de pautas de seguridad que se pueden adoptar gradualmente y que se establecen por consenso de la industria. En su forma final, SLSA se diferenciará de una lista de mejores prácticas en su aplicabilidad: apoyará la creación automática de metadatos auditables que se pueden introducir en motores de políticas para otorgar "certificación SLSA" a un paquete o plataforma de compilación en particular. SLSA está diseñado para ser incremental y procesable, y para brindar beneficios de seguridad en cada paso. Una vez que un artefacto califica al más alto nivel, los consumidores pueden tener la confianza de que no ha sido manipulado y se puede rastrear de manera segura hasta el origen, algo que es difícil, si no imposible, de hacer con la mayoría del software actual.

SLSA consta de cuatro niveles, y SLSA 4 representa el estado final ideal. Los niveles inferiores representan hitos incrementales con las correspondientes garantías de integridad incrementales. Los requisitos se definen actualmente de la siguiente manera.

SLSA 1 requiere que el proceso de construcción esté completamente programado / automatizado y genere procedencia. La procedencia son los metadatos sobre cómo se construyó un artefacto, incluido el proceso de compilación, la fuente de nivel superior y las dependencias. Conocer la procedencia permite a los consumidores de software tomar decisiones de seguridad basadas en riesgos. Aunque la procedencia en SLSA 1 no protege contra la manipulación, ofrece un nivel básico de identificación del código fuente y puede ayudar en la gestión de vulnerabilidades.

SLSA 2 requiere el uso de control de versiones y un servicio de compilación alojado que genera una procedencia autenticada. Estos requisitos adicionales dan al consumidor una mayor confianza en el origen del software. En este nivel, la procedencia evita la manipulación en la medida en que se confía en el servicio de compilación. SLSA 2 también proporciona una ruta de actualización sencilla a SLSA 3.

SLSA 3 requiere además que la fuente y las plataformas de construcción cumplan con estándares específicos para garantizar la auditabilidad de la fuente y la integridad de la procedencia, respectivamente. Visualizamos un proceso de acreditación mediante el cual los auditores certifican que las plataformas cumplen con los requisitos, en los que los consumidores pueden confiar. SLSA 3 proporciona protecciones mucho más fuertes contra la manipulación que los niveles anteriores al prevenir clases específicas de amenazas, como la contaminación cruzada.

SLSA 4 es actualmente el nivel más alto y requiere una revisión de dos personas de todos los cambios y un proceso de construcción hermético y reproducible. La revisión por dos personas es una de las mejores prácticas de la industria para detectar errores y disuadir el mal comportamiento. Las compilaciones herméticas garantizan que la lista de dependencias de la procedencia esté completa. Las compilaciones reproducibles, aunque no son estrictamente necesarias, brindan muchos beneficios de confiabilidad y auditabilidad. En general, SLSA 4 brinda al consumidor un alto grado de confianza en que el software no ha sido manipulado.

Se pueden encontrar más detalles sobre estos niveles propuestos en el Repositorio de GitHub, incluido el correspondiente Fuente y Construir / Procedencia requisitos. Estamos abiertos a comentarios y sugerencias para cambios en estos requisitos.

Prueba de concepto

Hoy, publicamos una prueba de concepto para el generador de procedencia SLSA 1 (repositorio, mercado). Esto permitirá que un usuario cree y cargue la procedencia junto con sus artefactos de compilación, logrando así el SLSA 1. Para usarlo, agregue el siguiente fragmento a su flujo de trabajo:

nombre: Generar procedencia

usos: slsamarco de referencia/githubcomportamientodemo @ v0.1

con:

camino_artefacto: <caminoaartefacto / directorio>

En el futuro, planeamos trabajar con plataformas populares de origen, compilación y empaquetado para que sea lo más fácil posible alcanzar niveles más altos de SLSA. Estos planes incluyen generar la procedencia automáticamente en los sistemas de compilación, propagar la procedencia de forma nativa en los repositorios de paquetes y agregar funciones de seguridad en las principales plataformas. Nuestro objetivo a largo plazo es elevar el nivel de seguridad en toda la industria para que la expectativa predeterminada sean estándares de seguridad SLSA de nivel superior, con un esfuerzo mínimo por parte de los productores de software.

Resumen

SLSA es un marco práctico para la integridad de la cadena de suministro de software de un extremo a otro, basado en un modelo que se ha demostrado que funciona a escala en una de las organizaciones de ingeniería de software más grandes del mundo. Lograr el nivel más alto de SLSA para la mayoría de los proyectos puede ser difícil, pero las mejoras incrementales reconocidas por niveles más bajos de SLSA ya contribuirán en gran medida a mejorar la seguridad del ecosistema de código abierto.

Esperamos trabajar con la comunidad para perfeccionar los niveles a medida que comenzamos a adoptar SLSA para nuestros propios proyectos de código abierto. Si es un mantenedor de proyectos y está interesado en intentar adoptar y proporcionar comentarios sobre SLSA, por favor alcanzar o únete a las discusiones que tienen lugar en el Grupo de trabajo de atestación de identidad digital de OpenSSF.

Revisar la Conocer, prevenir, arreglar publique para leer más sobre el enfoque general de Google para la seguridad de código abierto.



Enlace a la noticia original