En el fascinante y complejo mundo del desarrollo de software, cada componente es una pieza de una máquina invisible, aparentemente hecha de palabras mágicas. Este proceso comienza con el código fuente, que no es más que archivos de texto alojados en un repositorio. Posteriormente, este código se transforma mediante un proceso único en lo que se conoce como un «artefacto de software». Estos artefactos pueden ser un archivo Javascript minimizado, una imagen de contenedor repleta de lógica empresarial o un binario compilado para una arquitectura de procesador específica.
Una vez creados, estos artefactos pueden pasar un largo período de tiempo inactivos en registros de paquetes o contenedores, como npm, RubyGems, PyPI, MavenCentral, GitHub Packages, Azure Container Registry, AWS ECR, entre otros. Pueden estar almacenados como binarios adjuntos a GitHub Releases o simplemente como un archivo ZIP en almacenamiento de blobs, esperando ser utilizados.
El verdadero desafío surge cuando es momento de utilizar estos artefactos. Alguien debe descomprimir el paquete, ejecutar el código, lanzar el contenedor, instalar el controlador, o actualizar el firmware. Este proceso, que puede implicar muchas horas de trabajo humano y unos costos considerables, también conlleva un riesgo sustancial, dado que nuestro mundo moderno depende profundamente del software.
Una de las principales preocupaciones de seguridad en la actualidad es asegurar que el artefacto que se ejecuta sea exactamente el que se construyó originalmente. Los detalles del trayecto del artefacto frecuentemente se pierden o se vuelven borrosos, lo que dificulta conectar el artefacto final con el código fuente y las instrucciones de construcción originales. Esta falta de visibilidad es una de las causas principales de muchos desafíos de seguridad.
Durante el ciclo de vida del desarrollo de software (SDLC), existen oportunidades para garantizar la seguridad del flujo de código que se convierte en artefactos, lo que reduce el riesgo de que actores maliciosos comprometan el software final. No obstante, algunos retos de ciberseguridad que parecen casi imposibles de resolver, aunque no es el caso actual.
Tomemos un ejemplo sencillo: si deseas asegurarte de que un archivo en tu directorio personal sea exactamente el mismo hoy y mañana, puedes generar un digest del archivo mediante un algoritmo hash seguro. Usando OpenSSL y el algoritmo SHA-256, puedes crear una huella digital única para ese archivo. Si algo cambia en el archivo, la huella digital también cambiará.
Pero, ¿qué sucede cuando queremos asegurar un artefacto? En este punto, necesitamos una firma de artefacto de software. El proceso implica tomar la cadena de digest, pasarla por un algoritmo criptográfico y producir una cadena que represente la «firma» de esa huella digital con una clave única. Para que otras personas puedan confirmar tu firma, se debe usar cifrado asimétrico: firmas el digest con tu clave privada y proporcionas la clave pública correspondiente.
La encriptación asimétrica es la base de casi toda la confianza en Internet. Desde interacciones seguras con bancos hasta la entrega segura de contenidos en GitHub, la encriptación asimétrica impulsa tecnologías como TLS y SSH, creando una base de confianza a través de firmas.
Los principales sistemas operativos como Windows, macOS, iOS y Android, requieren la presencia de una firma para garantizar un origen de confianza para los artefactos de software. Construir estos sistemas es increíblemente difícil e importante para el mundo moderno del software.
Si bien una firma es un buen comienzo al ofrecer información confiable sobre un artefacto de software, para mejorar significativamente la seguridad del SDLC, necesitamos ir más allá de las firmas y pensar en términos de atestaciones. Una atestación es una declaración verificable sobre un artefacto, creada por una entidad autenticada.
El tipo principal de atestación es sobre el origen y la creación del artefacto, afirmando los hechos y las instrucciones de construcción que llevaron a ese artefacto. Esto se llama una atestación de procedencia, y su especificación proviene del proyecto SLSA, que proporciona un marco común para razonar sobre la seguridad de la cadena de suministro de software.
GitHub, como la mayor plataforma global de desarrollo de software, ha estado involucrada en el pensamiento y desarrollo de soluciones para garantizar la seguridad del SDLC, incluyendo la emisión de certificados, asegurar estos certificados, permitir la firma segura de artefactos y verificar esas firmas de manera confiable.
Así es como surge Sigstore, un proyecto de código abierto que ofrece una autoridad de certificación X.509 y una autoridad de estampado de tiempo. Sigstore simplifica y hace accesibles las firmas de software, similar a cómo Let’s Encrypt simplifica los certificados TLS. GitHub ayuda a supervisar la gobernanza del proyecto Sigstore y participa activamente en sus operaciones y desarrollo.
Con Sigstore, es posible crear un rastro de auditoría que vincule los artefactos al CI, asegurando que los consumidores de software puedan confiar en el origen del código que ejecutan. GitHub está emocionado de compartir más sobre estas soluciones en el futuro cercano.
Aprovecha el poder de GitHub Advanced Security y mantente atento a futuras actualizaciones para proteger mejor tus proyectos de software.
