Cet article a été écrit avec Viktor Kartashov et Daniel Nebenzahl.
Le test décisif de l'auditeur : pouvez-vous prouver vos constructions ?
« Pouvez-vous prouver, de manière définitive, que chaque image de conteneur que vous expédiez a été construite exactement comme vous le prétendez ? »
La plupart des auditeurs attendent une réponse rapide et fiable, et non des semaines de refactorisation YAML frénétique. Le cadre SLSA (Supply-chain Levels for Software Artifacts) fournit le modèle de cette preuve : une provenance structurée et inviolable.
Mais voici le hic : traditionnellement, l'intégration d'un générateur de provenance dans chaque flux de travail CI se transforme rapidement en un jeu de chat et de souris :
- Des dizaines de référentiels ? Cela signifie d’innombrables PR à examiner et à fusionner.
- Changements de pipeline ? Maintenance manuelle constante.
- Des constructions historiques ? Il n’existe aucun moyen simple de recréer des preuves pour les versions passées.
Scribe Security élimine cette friction avec SLSA à grande échelle. Propulsé par notre niveau supérieur Plateformes CLI, il collecte intelligemment vos journaux CI existants, détecte automatiquement chaque création d'image et émet une provenance complète in-toto (non signée pour SLSA niveau 1 ou signée pour SLSA niveau 2) - le tout à partir d'une seule commande qui ne nécessite aucune configuration préliminaire.
Plateformes CLI : le changement de paradigme sans contact chez Provenance
| Approche traditionnelle | Interface de ligne de commande (CLI) des plateformes Scribe |
| Intégrer une étape de générateur dans chaque tâche CI | Aucune modification du pipeline — analyse les journaux après la construction est terminée |
| Difficile de remblayer les anciennes constructions | Crée rétroactivement une provenance à partir d'exécutions de flux de travail passées |
| Effort linéaire par dépôt | Une commande à l'échelle à 10 → 1,000 XNUMX+ référentiels |
Comment la magie opère : automatiser la confiance
Scribe Platforms CLI exécute une danse sophistiquée en coulisses pour fournir une provenance SLSA automatisée, le tout sans interférer avec vos builds existants :
- Il récolte des bûches : Scribe se connecte à votre système CI/CD (actuellement GitHub Actions, avec le support GitLab et Jenkins à venir) pour récupérer les journaux de build.
- Il détecte chaque build : Sans aucune configuration spéciale dans vos pipelines, Scribe identifie intelligemment les commandes Docker, Podman ou Buildah pour identifier chaque création d'image.
- Il extrait les métadonnées clés : Les détails critiques tels que les balises d'image, les résumés cryptographiques, les identifiants d'exécution, les arguments de construction et les horodatages sont extraits directement de ces journaux.
- Il génère des SBOM liés : Pour une traçabilité complète, Scribe crée automatiquement les deux source Nomenclature des logiciels (SBOM) et image SBOM, en les reliant directement à la provenance de la construction.
- It Crafts SLSA Provenance : Grâce à ces données riches, Scribe construit ensuite une déclaration de provenance SLSA entièrement conforme pour chaque image.
- Il signe (en option) pour le niveau 2 : En ajoutant simplement un indicateur, Scribe s'intègre à votre capacité de signature (X509, Pub-Priv, Sigstore ou votre KMS préféré) pour signer cryptographiquement la provenance, l'élevant au niveau SLSA 2.
- Il valide et rapporte : Fondamentalement, Scribe exécute automatiquement des scripts prédéfinis. SLSA.l1 or SLSA.l2 initiatives fondées sur des preuves. Cela valide son intégrité et produit un rapport SARIF complet, également signé pour la conformité de niveau 2.
Tous les artefacts générés peuvent rester locaux ou être téléchargés en toute sécurité sur Scribe Hub pour un stockage à long terme et inviolable.
Au-delà des générations : prouver la conformité avec la politique en tant que code
Générer la provenance est fondamental, mais prouver sa conformité est ce qui satisfait véritablement les auditeurs. Dès que Scribe génère la provenance SLSA, il exécute automatiquement des actions en fonction de ces preuves.
Ces initiatives agissent comme des auditeurs automatisés, vérifiant des éléments tels que :
- La provenance est-elle bien formée et complète ?
- Tous les champs nécessaires sont-ils présents et exacts ?
- Les SBOM liés sont-ils valides et accessibles ?
- La provenance a-t-elle été signée cryptographiquement par les identités attendues ?
Le résultat ? Un rapport SARIF complet détaillant votre statut de conformité. Pour le niveau 2, ce rapport est également signé, fournissant une réponse claire, lisible par machine et vérifiable pour tout auditeur.
Un exemple rapide : obtenir la provenance SLSA avec Scribe-Security 🚀
L'interface de ligne de commande (CLI) des plateformes Scribe-Security simplifie la génération de la provenance SLSA pour vos builds, en proposant une commande unifiée pour obtenir une assurance de niveau 1 (non signée) et de niveau 2 (signée). La présence de l'argument –valint.sign constitue un élément différenciateur essentiel.
Pour obtenir la provenance SLSA de toutes les builds basées sur des balises dans votre référentiel scribe-security/valint sur GitHub, vous devez exécuter la commande suivante :
Frapper
Scribe entre alors en action : il analyse les flux de travail GitHub récents, détecte intelligemment vos builds d'images, collecte toutes les données nécessaires et écrit une provenance SLSA complète et complète avec les SBOM liés.
–valint.sign: Votre Switch pour SLSA Niveau 1 ou 2 🔑
Les –valint.sign le drapeau agit comme une simple bascule :
- Omettre –valint.sign pour SLSA Niveau 1 (non signé) : Scribe génère une provenance fondamentale et non signée pour une traçabilité de base.
- Inclure –valint.sign pour SLSA Niveau 2 (Signé) : Scribe signe de manière cryptographique les fichiers de provenance et le rapport de conformité SARIF, offrant ainsi un niveau d'assurance vérifiable plus élevé.
Cette commande unifiée, contrôlée par un seul indicateur, simplifie l'obtention d'une conformité SLSA robuste à grande échelle sans modifier vos pipelines CI/CD existants.
Génération de provenance SLSA open source
La génération de provenance SLSA ne se limite pas aux dépôts privés. De nombreux projets open source ont journaux CI/CD publics, permettant de générer la provenance de leurs builds. Bien que ces enregistrements de provenance puissent initialement contenir des informations moins complètes (telles que les secrets du référentiel et de l'organisation), des améliorations futures, potentiellement via Source SBOM, pourrait résoudre ce problème.
Par exemple, vous pouvez facilement générer une provenance SLSA de niveau 1 pour le go-gitea/gitea projet utilisant le plateformes découvrir commander:
Après avoir exécuté cette commande, vous verrez un journal indiquant la demande SLSA et un tableau résumant les builds d'images détectées et leur provenance associée :
Comme vous pouvez le constater, au moment de la rédaction de cet article, la dernière version de « gitea/gitea » trouvée était la version **v1.24.2**. Les deux images pour lesquelles la provenance SLSA et les preuves associées ont été publiées sont « gitea/gitea:1.24.2 » et « gitea/gitea:1.24.2-rootless ». À titre d'exemple, la provenance SLSA peut être référencée dans l'exemple suivant. lien,
Dans notre service, nous gérons le cycle de vie du cadre et des preuves pour fournir un aperçu clair de vos produits et actifs.
Ce contenu vous est proposé par Scribe Security, l'un des principaux fournisseurs de solutions de sécurité de bout en bout pour la chaîne d'approvisionnement logicielle, offrant une sécurité de pointe aux artefacts de code ainsi qu'aux processus de développement et de livraison de code tout au long des chaînes d'approvisionnement logicielles. En savoir plus.
articles similaires
