¿De dónde (realmente) proviene tu software?

GitHub está trabajando con la comunidad de OSS para incorporar nuevas capacidades de seguridad en la cadena de suministro a la plataforma.

Autor: Trevor Rosen

El software es algo curioso y profundo: cada pieza de él es una máquina invisible, aparentemente hecha de palabras mágicas, diseñada para ejecutarse en la máquina universal definitiva. No está vivo, pero tiene un ciclo de vida. Comienza como código fuente, solo archivos de texto, alojados en algún repositorio, y luego (a través de un proceso único) ese código fuente se convierte en otra cosa. Un fragmento de Javascript minificado entregado a un servidor web, una imagen de contenedor llena de código de framework y lógica empresarial, o un binario crudo compilado para una arquitectura de procesador específica. Esa última etapa de metamorfosis, eso en lo que se convierte el código fuente, es lo que generalmente llamamos un "artefacto de software", y después de su creación, los artefactos suelen pasar mucho tiempo en reposo, esperando ser utilizados. Lo hacen en registros de paquetes (como npm, RubyGems, PyPI, MavenCentral, etc.) o en registros de contenedores (como GitHub Packages, Azure Container Registry, AWS ECR, etc.), como binarios adjuntos a GitHub Releases, o simplemente un archivo ZIP en algún almacenamiento en la nube.

Eventualmente, alguien decide usar ese artefacto. Descomprimen el paquete, ejecutan el código, lanzan el contenedor, instalan el controlador, actualizan el firmware: no importa la modalidad, de repente lo que se construyó está en ejecución. Esta es la culminación de un ciclo de producción que puede llevar muchas horas de trabajo humano, costar mucho dinero, y (dado que el mundo moderno depende del software) puede ser un proceso de altísimo riesgo.

Y sin embargo, en muchos casos, no tenemos una garantía sólida de que el artefacto que ejecutamos sea definitivamente lo que construimos. Los detalles del viaje de ese artefacto se pierden o, en el mejor de los casos, son difusos; es difícil conectar el artefacto con el código fuente y las instrucciones de compilación de las que provino. Esta falta de visibilidad en el ciclo de vida del artefacto es la fuente de muchos de los desafíos de seguridad más importantes de hoy en día. A lo largo del SDLC (ciclo de vida de desarrollo de software), hay oportunidades para asegurar el flujo de código transformándose en artefactos, lo que ayuda a reducir el riesgo de que actores malintencionados alteren el software finalizado y causen estragos.

Algunos desafíos en ciberseguridad pueden parecer casi imposibles de abordar con éxito, pero este no es uno de ellos. Vamos a profundizar con algo de contexto.

Digests y firmas

Supongamos que tienes un archivo en tu directorio personal y quieres asegurarte de que sea exactamente el mismo mañana que hoy. ¿Qué haces? Una buena manera de empezar es generar un digest del archivo pasándolo por un algoritmo de hash seguro. Aquí te mostramos cómo hacerlo con OpenSSL, utilizando el algoritmo SHA-256:

Ahora tienes un digest (también llamado hash), una cadena de 64 caracteres de letras y números que representa una huella digital única de ese archivo. Cambia literalmente cualquier cosa en ese archivo, vuelve a ejecutar la función de hash y obtendrás una cadena diferente. Puedes anotar el digest en algún lugar y regresar mañana para probar el mismo proceso de nuevo. Si no obtienes la misma cadena de digest ambas veces, algo en el archivo ha cambiado.

Hasta ahora, todo bien: podemos determinar si algo ha sido manipulado. Pero, ¿y si queremos hacer una declaración sobre el artefacto? ¿Qué pasa si queremos decir “Hoy vi este artefacto, y yo (un sistema o una persona) garantizo que esta cosa en particular es definitivamente lo que vi”? En ese punto, lo que necesitas es una firma de artefacto de software; quieres tomar tu cadena de digest y pasarla por un algoritmo criptográfico para producir otra cadena que represente el acto de “firmar” esa huella digital con una clave única. Si posteriormente deseas que alguien más pueda confirmar tu firma, querrás usar cifrado asimétrico: firma el digest con tu clave privada y proporciona la clave pública correspondiente para que cualquiera en el mundo que obtenga tu archivo pueda verificarlo.

Probablemente ya sepas que el cifrado asimétrico es la base de casi toda la confianza en internet. Es la forma en que puedes interactuar de manera segura con tu banco y cómo GitHub puede entregar de manera segura los contenidos de tu repositorio. Utilizamos cifrado asimétrico para tecnologías como TLS y SSH, creando canales de comunicación confiables, pero también lo usamos para establecer confianza en el software a través de firmas.

Los sistemas operativos como Windows, macOS, iOS, Android, etc. tienen mecanismos para asegurar un origen confiable para los artefactos de software ejecutables, exigiendo la presencia de una firma. Estos sistemas son componentes increíblemente importantes del mundo moderno del software, y crearlos es extremadamente complejo.

No solo firmes, da fe

Al pensar en cómo exponer información más confiable sobre un artefacto de software, una firma es un buen comienzo. Dice “algún sistema confiable definitivamente vio esta cosa”. Pero si realmente quieres ofrecer un salto evolutivo en la seguridad del SDLC en su conjunto, debes ir más allá de las simples firmas y pensar en términos de atestaciones.

Una atestación es una declaración de hechos, una afirmación hecha sobre un artefacto o artefactos y creada por alguna entidad que puede ser autenticada. Se puede autenticar porque la declaración está firmada y la clave que realizó la firma es confiable.

El tipo de atestación más importante y fundamental es aquella que afirma hechos sobre el origen y la creación del artefacto: el código fuente del que proviene y las instrucciones de compilación que transmutaron ese código en un artefacto. A esto lo llamamos una atestación de procedencia.

La especificación de atestación de procedencia que hemos elegido proviene del proyecto SLSA. SLSA es una excelente forma de pensar en la seguridad de la cadena de suministro de software porque proporciona a los productores y consumidores de software un marco común para razonar sobre garantías de seguridad y límites de manera independiente a los sistemas y tecnologías específicos. SLSA ofrece un esquema estandarizado para producir atestaciones de procedencia para artefactos de software, basado en el trabajo realizado por el proyecto in-toto. In-toto es un proyecto graduado por la CNCF que existe, entre otras cosas, para proporcionar una colección de esquemas de metadatos estandarizados sobre información relevante de tu cadena de suministro y proceso de compilación.

¿Qué se necesita para construir algo como esto?

Siendo la plataforma de desarrollo de software más grande del mundo que alberga mucho código y pipelines de construcción, hemos pensado mucho en esto. Hay una serie de piezas móviles que se necesitarían para construir un servicio de atestación.

• Hacerlo implicaría tener una manera de:

• Emitir certificados (esencialmente claves públicas vinculadas a alguna identidad autenticada).

• Asegurarse de que esos certificados no puedan ser mal utilizados.

• Habilitar la firma segura de artefactos en un contexto bien conocido.

• Verificar esas firmas de una manera en la que el usuario final pueda confiar.

Esto significa configurar una Autoridad Certificadora (CA) y tener algún tipo de aplicación cliente que puedas usar para autenticar las firmas asociadas con los certificados emitidos por esa autoridad. Para evitar el mal uso de los certificados, necesitas o 1) mantener Listas de Revocación de Certificados o 2) asegurarte de que el certificado de firma sea de corta duración, lo que significa tener una firma adicional de alguna autoridad de sellado de tiempo (que puede dar un sello autoritativo de que un certificado solo se usó para producir una firma durante el período en que era válido).

Aquí es donde entra Sigstore. Es un proyecto de código abierto que ofrece tanto una CA X.509 como una autoridad de sellado de tiempo basada en el RFC 3161. También te permite hacer identidad con tokens OIDC, que muchos sistemas de CI ya producen y asocian con sus cargas de trabajo.

Sigstore hace por las firmas de software lo que Let's Encrypt hizo por los certificados TLS: hacerlos simples, transparentes y fáciles de adoptar. GitHub ayuda a supervisar la gobernanza del proyecto Sigstore a través de nuestro puesto en el Comité de Dirección Técnica, somos mantenedores de las aplicaciones de servidor y múltiples bibliotecas cliente, y (junto con personas de Chainguard, Google, RedHat y Stacklok) formamos el equipo de operaciones de la instancia pública de Sigstore, que existe para apoyar las atestaciones públicas para proyectos de software de código abierto (OSS).

Sigstore requiere una raíz de confianza segura que cumpla con el estándar establecido por The Update Framework (TUF). Esto permite que los clientes se mantengan al día con las rotaciones en las claves subyacentes de la CA sin necesidad de actualizar su código. TUF existe para mitigar una gran cantidad de vectores de ataque que pueden surgir al trabajar para actualizar el código en situ. Es utilizado por muchos proyectos para actualizar cosas como agentes de telemetría de larga duración en funcionamiento, entregar actualizaciones de firmware seguras, etc.

Con Sigstore en su lugar, es posible crear un rastro documental a prueba de manipulaciones que vincule artefactos de vuelta a CI. Esto es realmente importante porque firmar software y capturar detalles de la procedencia de una manera que no pueda ser falsificada significa que los consumidores de software tienen los medios para hacer cumplir sus propias reglas sobre el origen del código que están ejecutando, y estamos emocionados de compartir más con ustedes en los próximos días. ¡Mantente atento!