Gestion de la chaîne d’approvisionnement sécurisée Adoptium®

Toutes les étapes de production d’Eclipse Temurin sont définies par des pipelines Jenkins sous contrôle de version qui appellent des scripts de build stockés dans le dépôt adoptium/temurin-build. Les pipelines et les scripts de build sont accessibles à tous pour consultation et vérification, et les exécutions du système Jenkins sont ouvertes à l’examen. La documentation pour l’utilisation des scripts de build est disponible dans le fichier readme du dépôt de build.

Adoptium fournit des attestations SBOM pour la provenance des builds Eclipse Temurin. Le SBOM est au format OWASP CycloneDX et disponible aux côtés de chacun de nos artefacts de version Temurin.

Le SBOM inclut les informations nécessaires pour recréer le build si nécessaire, notamment les étiquettes de dépôt source utilisées par le processus de build, l’ensemble complet des paramètres utilisés, la sortie des étapes de configuration, et diverses autres informations. Nous faisons évoluer continuellement les détails spécifiques inclus dans le SBOM.

Adoptium met en miroir le code source de l’implémentation de référence Java SE OpenJDK dans notre dépôt Github local (ex. adoptium/jdk17u). Chaque modification apportée au source que nous compilons et aux scripts que nous utilisons est suivie par le système de contrôle de version de Github. Cela garantit un enregistrement de l’historique des modifications apportées à chaque révision. Chaque modification contient l’identité de l’importateur et des réviseurs, les horodatages des révisions et des soumissions, la description/justification de la modification, le contenu de la modification et les révisions parentes. Tous les contributeurs et réviseurs sont soumis à une authentification renforcée, et tous les contributeurs doivent signer et respecter l' accord de contribution Eclipse.

Chaque révision immuable du code sous notre contrôle dispose d’une référence unique à durée de vie indéfinie via Github (URL du dépôt + branche/étiquette/référence + ID de commit). Eclipse Temurin est construit à partir de révisions étiquetées de notre miroir, et nous mettons à disposition des archives sources pour chaque version.

Toutes les étapes de build d’Adoptium s’exécutent sur notre propre service de build Jenkins géré et le service de signature de code de l’Eclipse Foundation. Ces services effectuent les builds, génèrent les SBOM et construisent les installateurs le cas échéant. Les résultats des builds sont téléchargés vers les dépôts de versions GitHub par le système Jenkins CI. Aucune partie du processus ne s’exécute sur le poste de travail d’un développeur.

L’accès aux services de build est soigneusement géré par le projet. Le système de build est aussi ouvert que possible pour permettre l’examen par la communauté sans compromettre la sécurité.

TODO: L’authenticité et l’intégrité de la provenance peuvent être vérifiées par le consommateur. Cela DEVRAIT se faire par le biais d’une signature numérique d’une clé privée accessible uniquement au service générant la provenance.

Toutes les données de provenance d’Adoptium sont générées directement par les systèmes de build et de test continus du projet. Les utilisateurs du service ne peuvent pas injecter ni modifier le contenu de la provenance. Les signatures de code GNU Privacy Guard (GPG) d’Eclipse Temurin sont générées par le service de signature de code Eclipse ; les autres données de provenance, notamment la nomenclature logicielle, les hachages cryptographiques, les métadonnées de build, etc., sont directement émises par le système de build du projet.

Toutes les révisions du code source et leur historique des modifications sont conservés indéfiniment et ne peuvent être supprimés, sauf dans le cadre d’une politique d’oblitération établie et transparente, telle qu’une exigence légale ou une politique de l’Eclipse Foundation. Ce niveau de contrôle superutilisateur pour modifier ou supprimer l’historique est maintenu directement et exclusivement par l’Eclipse Foundation au nom du projet.

Puisque nous stockons tout notre code dans GitHub, il n’est pas possible pour des personnes de supprimer ou de modifier l’historique, même avec approbation multi-parties, sauf par des administrateurs de la plateforme Eclipse Foundation de confiance avec approbation à deux parties suivant la politique d’oblitération de la fondation. Les questions relatives à cette politique doivent être adressées à l’Eclipse Foundation.

La définition et la configuration de build d’Adoptium exécutées par le service de build sont vérifiablement dérivées de définitions de fichiers texte stockées dans notre système de contrôle de version.

Les builds en environnement éphémère, tels qu’un conteneur ou une VM, provisionnés uniquement pour ce build et non réutilisés depuis un build précédent, sont en place pour les builds Linux x86, ARM32 et aarch64. D’autres plateformes sont encore en cours de traitement au sein du projet.

Le service de build Adoptium s’assure que chaque étape de build s’exécute dans un environnement isolé, à l’abri de l’influence d’autres instances de build, qu’elles soient antérieures ou concurrentes.

Il n’est pas possible pour un build d’accéder à des secrets du service de build, tels que la clé de signature de provenance, car ceux-ci sont stockés en dehors du système de build et accessibles par un appel distant à un système séparé. Il n’est pas possible que deux builds qui se chevauchent dans le temps s’influencent mutuellement. Chaque étape de build s’exécute dans un environnement machine isolé orchestré par le système Jenkins CI, et les étapes de chaque build sont assemblées par le biais de pipelines gérés. Les caches de build, lorsqu’ils sont utilisés, sont purement adressables par contenu pour éviter toute falsification.

Nous continuons à travailler pour s’assurer qu’il n’est pas possible pour un build de persister ou d’influencer l’environnement de build d’un build ultérieur. Chaque partie de l’environnement est spécifiée dans les scripts de build. Cela sera garanti en exécutant les builds sur des machines éphémères partout et en vérifiant que les résultats sont identiques.

Les informations de provenance du SBOM ne peuvent pas être falsifiées par les utilisateurs du service car elles sont générées par machine par le processus de build et signées cryptographiquement par le service de signature de code de l’Eclipse Foundation pour empêcher toute falsification. Le service de signature de code n’est pas accessible aux contributeurs habituels du projet ni aux utilisateurs Jenkins.