La integridad de las cadenas de suministro de software se ha convertido en un importante tema de conversación en los últimos años, y los ataques a las cadenas de suministro de software se han vuelto más frecuentes en los últimos dos años. Se ha vuelto imperativo que los desarrolladores elijan cuidadosamente software y productos externos para incluirlos en sus sistemas de software y al mismo tiempo implementen medidas para garantizar la integridad de sus artefactos de software.
El proceso de creación e implementación de software es bastante complicado y tiene muchos puntos potenciales de vulnerabilidad a lo largo de la cadena. En lugar de depender de soluciones específicas para cada vulnerabilidad, tiene más sentido que los desarrolladores adopten un marco de trabajo de extremo a extremo más completo que pueda ayudar a mitigar las amenazas durante la fase de desarrollo.
Uno de esos marcos es el Niveles de la cadena de suministro para artefactos de software (SLSA). Este marco es una lista de verificación completa de controles y estándares de seguridad que garantizan la integridad de los paquetes de software y la infraestructura.
El sistema SLSA recientemente introducida El marco de seguridad es producto de una colaboración entre AbiertoSSF, Google, y otras partes interesadas en la ciberseguridad. Sirve como un estándar industrial acordado que pueden adoptar los desarrolladores, las empresas y las empresas para ayudarlos a tomar decisiones informadas sobre la seguridad del software que están creando o consumiendo y proteger todo el ciclo de vida del desarrollo de software.
Cómo SLSA ayuda a defenderse contra los ataques a la cadena de suministro de software
Más que un conjunto de reglas, el marco de seguridad SLSA es un marco estándar que potencialmente puede fortalecer la integridad de los componentes de un artefacto de software. Esta directriz de extremo a extremo actúa como un conjunto de medidas defensivas que previenen gradualmente la manipulación o cualquier tipo de modificación no autorizada de los paquetes de software que componen un producto de software. La adopción del marco SLSA puede ayudar a proteger su software contra ataques comunes. ataques a la cadena de suministro tales como los siguientes:
Ataques maliciosos al repositorio de confirmación de PHP
En marzo de 2021, Nikita Popov anunció que actores maliciosos intentaron atacar el código fuente de PHP creando una puerta trasera que les permitiría obtener acceso no autorizado a la plataforma de código. De haber tenido éxito, el ataque habría sido devastador, ya que PHP impulsa alrededor del 80% de los sitios web en Internet. Afortunadamente, el ataque se detectó a tiempo, pero este incidente aún ilustra cómo los controles SLSA pueden ayudar a prevenir ataques como este en el futuro. Seguir los protocolos SLSA, como la revisión de dos personas y la autenticación de dos factores, habría protegido la plataforma del código fuente y la habría convertido en un objetivo mucho más difícil para los atacantes.
La infracción del compilador malicioso de Apple
En 2015, los desarrolladores de software que creaban aplicaciones para productos Apple descargaron una versión de Xcode (una herramienta de escritura de códigos para dispositivos Apple) desde una plataforma de alojamiento no verificada. La versión de Xcode conocida como XcodeGhost había sido infectada con un código malicioso que se transfirió de forma encubierta a las aplicaciones creadas con él. Creó una puerta trasera para varias aplicaciones que eludían el proceso de revisión del código de Apple y las aplicaciones ofrecidas en la tienda de aplicaciones. El marco SLSA contiene protocolos de seguridad relacionados con la compilación que habrían evitado un ataque como este o lo habrían hecho más difícil. Una de esas medidas es el requisito de construcción hermética que habría obligado a los desarrolladores a declarar todas sus fuentes, incluida la herramienta construida que utilizaron.
Artefactos maliciosos subidos
El 1 de abril de 2021, el equipo de Codecov descubrió ataques que afectaban a sus Bash Uploaders, que incluían Codecov GitHub Action, The Codecov CircleCI Orb y Codecov Bitrise Step. El atacante obtuvo acceso no autorizado extrayendo una clave HMAC que proporcionaba acceso a la cuenta del servicio Google Cloud Storage de una capa intermedia de una de las imágenes públicas de Docker autohospedado de Codecov. Esta clave les permitió modificar Bash Uploader para cargar códigos maliciosos directamente a los usuarios finales. El marco SLSA habría detectado esta acción mostrando cuándo los artefactos se construyen de una manera diferente a la esperada en su repositorio de origen.
Mala dependencia del flujo de eventos
En 2018, los piratas informáticos publicaron un paquete malicioso flatmap-stream en npm y luego se agregó como una dependencia al paquete event-stream ampliamente utilizado de la plataforma. Después de agregar la dependencia, los atacantes la actualizaron con un comportamiento malicioso. Dado que la actualización no coincidía con el código enviado a GitHub, el marco SLSA habría detectado el ataque y habría evitado el vector. El seguimiento de la procedencia del código malicioso habría revelado que no procedía de GitHub ni del creador adecuado. De cualquier manera, el ataque podría haberse evitado.
Los cuatro niveles de seguridad del marco de ciberseguridad SLSA
El marco SLSA es un protocolo incremental y procesable. Consta de cuatro niveles, donde el nivel 4 representa el estado final ideal de un sistema seguro. Los artefactos del más alto nivel cumplen todos los requisitos para ganar la confianza del consumidor de que no han sido manipulados de ninguna manera y que todos sus componentes pueden rastrearse hasta sus orígenes. Los artefactos en los niveles inferiores son aquellos que también han alcanzado hitos incrementales con garantías de integridad específicas según su rango.
Nivel 1: sentar las bases
Puede considerar el Nivel 1 del marco SLSA como una especie de base para que todo el marco cree software seguro. En esta etapa, los desarrolladores u organizaciones que adopten SLSA deben hacer dos cosas. Primero, deben automatizar completamente su proceso de construcción. Esto se puede hacer de diferentes maneras, pero la forma convencional de automatizar compilaciones es mediante el uso de un archivo MAKE. Las GitHub Actions también se pueden utilizar para lograr los mismos resultados.
La segunda parte para lograr el Nivel 1 de SLSA es generar documentación de procedencia completa. Se trata de metadatos que muestran cómo se creó un artefacto de software. Debe detallar todo el proceso de construcción, todas las dependencias y las fuentes de nivel superior utilizadas para crearlo.
Crear un script para el proceso de construcción y mostrar la procedencia de un artefacto de software de esta manera facilita que los consumidores tomen decisiones informadas sobre el uso de un producto de software. Aunque contar con la verificación SLSA 1 no significa que el software esté completamente protegido contra manipulaciones, facilita la identificación de los componentes del software. Esta es la primera etapa en la gestión de vulnerabilidades.
Nivel 2: asegúrese de que su proceso de construcción sea resistente a manipulaciones
El nivel 2 del marco SLSA es donde comienza a implementar medidas para garantizar que su proceso de construcción sea lo más resistente posible a la manipulación. Alcanzar el Nivel 2 del marco SLSA también le da al consumidor más confianza sobre el origen del software.
Nuevamente, esto se hace en dos pasos: el primero consiste en utilizar el control de versiones y el segundo implica utilizar un servicio de compilación alojado para autenticar la procedencia. Para el primer paso, se utiliza GitHub, GitLab o cualquier otro servicio similar para almacenar el código y registrar cualquier cambio realizado en él. El seguimiento de cualquier cambio de versión de esta manera facilita la comprensión de cualquier alteración realizada en el artefacto durante el proceso de construcción.
Aunque el Nivel 2 requiere documentación de procedencia al igual que el Nivel 1, la diferencia aquí es que el artefacto de software debe ser autenticado por un servicio de compilación alojado. El servicio alojado actúa como un tercero confiable que puede confirmar que el proceso de construcción detallado en el documento de procedencia inicial es exacto. GitHub Actions es un tipo de servicio de alojamiento que puede proporcionar procedencia autenticada.
Nivel 3: controles de seguridad de SLSA
El nivel 3 es donde comienza a implementar el control de seguridad específico como se destaca en el marco SLSA. Para alcanzar este nivel, las plataformas fuente y de compilación de sus artefactos de software deben cumplir estándares específicos que garanticen que la fuente sea auditable y que se pueda confiar en la procedencia del código. SLSA Nivel 3 proporciona una garantía mucho más sólida de que el artefacto está bien protegido contra manipulaciones y clases específicas de amenazas.
Algunos de los requisitos específicos del Nivel 3 incluyen:
- Historial y retención verificados del código fuente—Un historial verificado del código fuente garantiza que cualquier cambio realizado en el código fuente del software vaya acompañado de una identidad autenticada del autor, revisor o cargador que realizó el cambio con marcas de tiempo específicas del cambio. Este historial de cambios también debe almacenarse durante al menos 18 meses.
- Construcciones aisladas en entornos efímeros—Para cumplir con este requisito, las compilaciones de software deben implementarse en entornos efímeros donde sean completamente independientes de cualquier otra instancia de compilación. Para lograr esto, puede utilizar un servicio como GitHub Actions, que utiliza una máquina de compilación virtual para producir su compilación bajo demanda.
- Se construye como código—Estos criterios requieren que trate sus archivos de compilación como código. Esto significa que deben almacenarse en un sistema de control de versiones que permita recrear los procesos de compilación cuando sea necesario.
- Procedencia no falsificable—El propósito de este requisito es evitar que los usuarios alteren la documentación de procedencia generada por el servicio de construcción.
Nivel 4: confianza del consumidor
El nivel 4 del marco SLSA tiene como objetivo garantizar que el software no haya sido manipulado de ninguna manera. Sólo los artefactos de software que hayan cumplido los siguientes requisitos pueden alcanzar el Nivel 4 del marco:
Revisión por dos personas de todos los cambios.
Este criterio requiere que las organizaciones asignen dos revisores calificados para revisar minuciosamente cualquier cambio propuesto al código y los componentes del software. Este proceso de revisión de dos personas garantiza que sólo los desarrolladores autenticados y de confianza puedan realizar cambios en los artefactos de software.
Un proceso de construcción hermético y reproducible
Se dice que un proceso de construcción es hermético cuando todas las entradas se especifican desde el principio y fuera del proceso de construcción. Esta regla se aplica al código fuente, así como a todos los compiladores, bibliotecas y herramientas utilizadas en la compilación. Esto ayuda a garantizar la integridad de todas las importaciones de terceros. Los criterios de construcción reproducibles no son un requisito obligatorio, pero también se recomiendan. Los criterios requieren que el proceso de construcción produzca el mismo resultado independientemente de dónde o cuándo se ejecute.
Requisitos técnicos para cumplir con los niveles SLSA
El marco SLSA tiene requisitos técnicos específicos para los diferentes niveles. Estos requisitos se clasifican en cinco categorías principales: requisitos de origen, requisitos de proceso de construcción, requisitos comunes, requisitos de contenido de procedencia y requisitos de generación de procedencia. Cada una de estas categorías de requisitos se destaca a continuación.
Requisitos de origen
Esto se refiere a los requisitos destinados a garantizar la integridad de su código fuente. Seguir estos conjuntos de protocolos evita alteraciones y cambios maliciosos en su código. También garantiza que cualquier acción nefasta no pase desapercibida. Los requisitos de origen se establecen en la siguiente tabla.
| Requisitos de origen | Descripción | Nivel SLSA |
| Control de versiones | Se deben realizar un seguimiento de todos los cambios en el código fuente. | 2 |
| Historia verificada | Se debe registrar un historial completo que detalla “quién”, “qué” y “cuándo” de cada revisión de versión. | 3 |
| Retenido indefinidamente | Todos los cambios de versión y la información del historial deben almacenarse indefinidamente y no deben eliminarse. | 4 |
| Revisado por dos personas | Dos personas de confianza y altamente autenticadas deben autorizar cualquier cambio de versión. | 4 |
Requisitos de construcción
El marco SLSA destaca los requisitos de construcción destinados a mejorar la seguridad de la plataforma de construcción y mantener la integridad del proceso de construcción.
| Requisitos de construcción | Descripción | Nivel SLSA |
| Construcción con guión | Todos los pasos del proceso de construcción deben estar completamente automatizados. | 1 |
| Servicio de construcción | Todos los pasos del proceso de compilación deben ejecutarse en un servicio de compilación dedicado. | 2 |
| Entorno efímero y aislado | El proceso de compilación debe ejecutarse en un entorno efímero proporcionado específicamente para la compilación. Los pasos también deben ejecutarse en un entorno aislado y libre de otras instancias de compilación.
|
3 |
| Sin parámetros y hermético | El proceso de compilación debe depender completamente del script de compilación en lugar de de los parámetros del usuario. Todos los pasos de compilación transitiva deben ser herméticos, lo que significa que todas las fuentes y dependencias deben declararse completamente desde el principio y fuera del proceso de compilación. | 4 |
Requisitos de generación de procedencia
Estos requisitos están destinados a verificar el origen de todos los componentes de un activo de software. Los requisitos de generación de procedencia se destacan en la siguiente tabla.
| Requisitos de generación de procedencia | Descripción | Nivel SLSA |
| Disponibles | El consumidor debería tener acceso a la información de procedencia en un formato aceptable. | 1 |
| Verificable | El consumidor debería poder verificar la autenticidad de la información de procedencia proporcionada. | 1 |
| Generado por servicio | Toda la información de procedencia debe ser generada por el servicio de construcción.
|
2 |
| No falsificable | Los usuarios no pueden falsificar los datos de procedencia. | 3 |
| Dependencias completas | Los datos de procedencia deben incluir todas las dependencias utilizadas durante los pasos de construcción. | 4 |
Requisitos de contenido de procedencia
Los requisitos de contenido de procedencia verifican la identidad y el origen de todos los artefactos, dependencias y restricciones de compilación que se utilizaron en el proceso de compilación. Están resaltados en la siguiente tabla.
| Requisitos de contenido de procedencia | Descripción | Nivel SLSA |
| Identifica artefacto, constructor, origen y punto de entrada. | ● Identifica el artefacto de salida.
● Identifica la entidad de construcción. ● Identifica la fuente a través de una referencia inmutable. ● Identifica el comando que invocó el script de compilación. |
1 |
| Incluye todos los parámetros de construcción. | Se deben identificar todos los parámetros de construcción.
|
3 |
| Incluye dependencias transitivas e información reproducible. | ● Incluye todas las dependencias transitivas.
● Si la construcción es reproducible, se debe proporcionar toda la información necesaria para reproducirla.
|
4 |
| Incluye metadatos | Todos los metadatos deben incluirse para ayudar en las investigaciones. | 0 |
Requisitos comunes
Los requisitos comunes se aplican a los artefactos de software en el nivel 4 de SLSA. Se espera que cada artefacto confiable cumpla con estos requisitos. Incluyen requisitos de seguridad básicos y registros que detallan todo el acceso físico y remoto. Los requisitos comunes también estipulan una pequeña cantidad de administradores de plataforma que pueden anular las estipulaciones de la documentación de SLSA.