Protección de la cadena de suministro de software con SLSA

SLSA

Todos sabemos que la cadena de suministro de software es vulnerable . Los ataques aumentaron un asombroso 650 % en 2021 en comparación con el año anterior, para un total de 12 000 incidentes maliciosos, según el informe Estado de la cadena de suministro de software de 2021 de Sonatype .

Y es probable que empeore: Gartner predice que «para 2025, el 45 % de las organizaciones habrá experimentado ataques en sus cadenas de suministro de software, un aumento del triple desde 2021».


Banner_frasco-suscripcion-800x250

Pero abordar este creciente desafío sigue siendo una importante necesidad insatisfecha en la seguridad de las aplicaciones .

En este contexto, Google propuso niveles de cadena de suministro para artefactos de software (SLSA, pronunciado «salsa») en junio. Inspirado en el proceso interno de » Autorización binaria para Borg » del proveedor, que ha sido obligatorio para las cargas de trabajo de producción en Google durante décadas, SLSA es un marco para garantizar la integridad de los artefactos de software para evitar ataques.

El proyecto se gestiona bajo los auspicios de OpenSSF y ha crecido a más de 30 colaboradores, de organizaciones como Chainguard, Citi, Datadog, Intel y VMware .

¿Por qué está amenazada la cadena de suministro de software?

Hay tres razones principales para el cambio de atacar los sistemas de producción a atacar la cadena de suministro, según Ronen Slavin , cofundador y director de tecnología de Cycode, una empresa que se centra en la seguridad de la cadena de suministro de software.

La primera tiene que ver con la visibilidad. En muchas organizaciones, los equipos de seguridad no son responsables de las herramientas que componen la canalización de CI/CD . “Los enfoques de desarrollo modernos han traído muchas herramientas, que son implementadas y ejecutadas por ingenieros sin la participación de la seguridad; esto crea una brecha de visibilidad”, dijo Slavin a The New Stack por correo electrónico.

“Además, los equipos de ingeniería tienen prioridades diferentes a las de los equipos de seguridad. No es sorprendente que los equipos de ingeniería configuren herramientas de productividad de ingeniería con énfasis en la agilidad del desarrollador y la velocidad de las funciones, mientras que la seguridad suele ser una idea de último momento”.

Una segunda razón del aumento de los ataques a la cadena de suministro tiene que ver con la superficie de ataque, con las propias herramientas convirtiéndose en vectores de ataque. “Estos ataques son más dañinos que las infracciones tradicionales”, nos dijo Slavin.

Expuso cuatro razones por las que la nueva ola de ataques es mucho más dañina:

  1. Tendencias como todo como código y GitOps hacen que sea mucho más fácil para los atacantes moverse lateralmente o comprometer todo el ciclo de vida de desarrollo de software (SDLC) una vez que se afianzan.
  2. Este tipo de ataque generalmente pasa por alto las medidas de seguridad estándar en las que confía la mayoría de las organizaciones, como firewalls, firewalls de aplicaciones web (WAF) , air gapping, división en subredes, VPN, etc.
  3. Los ataques a la cadena de suministro a menudo se propagan aguas abajo para violar a los clientes.
  4. Por lo general, es más difícil y requiere más tiempo recuperar el código después de sufrir ataques a la cadena de suministro porque el nivel de una brecha suele ser más profundo, más amplio y más sensible, por lo que la reconstrucción requiere un proceso más completo.

“Entonces, desde la perspectiva de un atacante, el ROI de tales ataques es mucho mayor”, concluyó Slavin.

Un tercer problema es la falta de herramientas; hay relativamente pocas herramientas que puedan ver las diferentes fases del ciclo de vida del desarrollo de software. “El SDLC está aislado desde el punto de vista de la seguridad, con poca o ninguna capacidad para conectar los puntos”, dijo Slavin.

¿Cómo funciona SLSA?

El marco SLSA opera según el principio de que, como establece su documentación oficial, «Puede tomar años alcanzar el estado de seguridad ideal, y los hitos intermedios son importantes».

Dado esto, define un enfoque graduado para adoptar la seguridad de la cadena de suministro para sus compilaciones . En resumen:

  • Nivel uno: el proceso de compilación debe estar totalmente automatizado/programado y generar procedencia: metadatos sobre cómo se construyó un artefacto, incluido el proceso de compilación, la fuente de nivel superior y las dependencias. Este nivel no evita la manipulación, pero ofrece un nivel básico de identificación del origen del código y puede ayudar en la gestión de vulnerabilidades.
  • Nivel dos: requiere el uso de control de versiones y un servicio de compilación alojado que genera una procedencia autenticada. En este nivel, la procedencia evita la manipulación en la medida en que se confíe en el servicio de compilación.
  • Nivel tres: las plataformas de origen y construcción cumplen con estándares específicos para garantizar la auditabilidad del origen y la integridad de la procedencia, respectivamente. En teoría, esto proporciona protecciones mucho más sólidas contra la manipulación que los niveles anteriores al prevenir clases específicas de amenazas, como la contaminación entre construcciones, pero requiere algún tipo de proceso de acreditación aún no definido para funcionar.
  • Nivel cuatro: requiere una revisión de dos personas de todos los cambios y un proceso de construcción hermético y reproducible. Las compilaciones herméticas garantizan que la lista de dependencias de la procedencia esté completa.

Este enfoque incremental es clave, según Joshua Lock , un ingeniero de software de código abierto del personal de VMware que está trabajando en SLSA.

“Especialmente para los proyectos de código abierto, todos podemos decir que tener el nivel cuatro de SLSA es lo ideal, pero también podemos reconocer que para la mayoría de los proyectos de código abierto, creados y mantenidos por una persona en su tiempo libre, eso simplemente no es posible. —dijo Lock—.

«Así que podemos elegir decir: ‘Está bien, me siento cómodo con el nivel dos o el nivel tres tal vez, y simplemente me detendré allí, y tal vez iré más allá si el proyecto realmente despega».

SLSA para ayudar a guiar la política de código

Del mismo modo, al conocer el nivel de SLSA, los desarrolladores y las organizaciones pueden razonar sobre un paquete de software o crear la postura de seguridad de una plataforma y tomar decisiones sobre en qué confiar.

“El objetivo inicial es llegar a un estado en el que una empresa pueda decir, ‘Oye, no voy a implementar ningún código en mi sistema de producción que no cumpla con el nivel tres de SLSA’, por ejemplo, y tener eso como un política estricta. O que sus proveedores deben cumplir con niveles más altos de SLSA antes de firmar un contrato” , dijo a The New Stack Kim Lewandowski , quien trabajó y lanzó SLSA cuando estaba en Google y desde entonces fundó Chainguard.

En sí mismo, esto es significativo, como nos dijo Lock: “Cuando miras los sistemas nativos de la nube y los cientos o miles de dependencias que están incorporando, poder imaginar un futuro en el que puedas decir: ‘Está bien, no’. No quiero que nada golpee mi clúster que no sea SLSA de nivel tres o superior, es realmente poderoso”.

Para decirlo de otra manera, «SLSA es realmente una articulación de muchas de las mejores prácticas existentes», según Lock.

“Dibujo la analogía de que muchos de los requisitos de SLSA son cosas que las distribuciones de Linux han estado haciendo durante mucho tiempo”, dijo. “Entonces, una distribución de Linux tomará una copia del código fuente que están construyendo; no confiarán en que la ubicación aguas arriba no cambie o no sea manipulada.

“Por lo general, tienen un proceso bastante riguroso para aceptar nuevos mantenedores de paquetes, por lo que existe la idea del ‘colaborador de confianza’. Usted escribe una especie de receta para empaquetar su software, y luego empuja ese código a alguna parte, y la maquinaria de distribución central construye el paquete, y pasa por varios niveles de prueba y garantía de calidad antes de que se introduzca en el flujo que el usuario de distribución promedio puede tirar. Esto se asigna a los requisitos de compilación de SLSA; definirse como código, usar entornos aislados, etc.

Metadatos verificables para verificar reclamos de seguridad

Sin embargo, un desafío es cómo saben los consumidores que pueden confiar en el nivel de seguridad declarado. SLSA tiene como objetivo resolver este enigma a través de la creación automática de metadatos verificables.

“Esa es una de las diferencias con SLSA, como yo lo veo, no es solo una lista de requisitos y mejores prácticas”, dijo Lewandowski. “En realidad, debe tener los datos, los datos verificables que está produciendo, para que un consumidor de un paquete pueda ver los datos reales que muestran que cumple con los diferentes requisitos de SLSA”.

“SLSA es realmente una articulación de muchas de las mejores prácticas existentes”.

—Joshua Lock, ingeniero de software de código abierto del personal, VMware

Slavin se hizo eco de esta idea: “El estándar se centra mucho en el proceso de construcción y su seguridad, lo cual es un gran paso adelante. Introduce la noción de procedencia, que es una forma de atestiguar el proceso de construcción y promueve la idea de construcciones reproducibles, que también es un paso muy importante hacia una canalización segura”.

Otro problema que aborda SLSA, dijo Lewandowski, es que “hay debilidades a lo largo de toda la cadena de suministro. Y hemos visto ataques en cada punto durante los últimos años”.

En vista de esto, el marco SLSA proporciona un modelo de amenaza para la cadena de suministro de entrega de software, que cubre tanto la fuente como la integridad de la compilación y muestra cómo SLSA podría ayudar.

Sin embargo, se debe enfatizar que SLSA es todavía un trabajo en progreso y hay una discusión activa sobre qué medidas deberían estar dentro del alcance. El modelo de amenazas destaca una serie de áreas que actualmente no están cubiertas por la especificación, incluidos riesgos como omisiones de revisión de código o administradores que cambian las configuraciones de seguridad para enviar código malicioso.

Además, como se señaló anteriormente, las herramientas para la seguridad de la cadena de suministro aún son bastante incipientes. Pero iniciativas como sigstore , herramientas de código abierto que tienen como objetivo hacer que la firma criptográfica de artefactos sea muy fácil y amigable para los desarrolladores, se muestran prometedoras, particularmente cuando se combinan con la especificación SLSA.

Para los lectores que deseen comenzar, el proyecto SLSA ha publicado una guía de » inicio » que puede ayudarlo a alcanzar el nivel uno. Chainguard también ha comenzado a publicar una serie de blogs ( aquí y aquí ) que brindan información adicional útil. Por separado, Cloud Native Computing Foundation mantiene un documento vivo mantenido por la comunidad: el Documento de seguridad de la cadena de suministro de software , que tiene como objetivo proporcionar a la comunidad «una serie de prácticas recomendadas, opciones de herramientas y consideraciones de diseño que pueden reducir la probabilidad y, en general, impacto de un ataque exitoso a la cadena de suministro”.

Banner_azules
Reciba las últimas noticias de la industria en su casilla:

Suscribirse ✉