Ce que vous devez faire pour atteindre les niveaux SLSA – Un guide très pratique

Informations contextuelles

SLSA (Supply-chain Levels for Software Artifacts) est un cadre de sécurité visant à empêcher la falsification, à améliorer l'intégrité et à sécuriser les packages et l'infrastructure. Le concept de base de SLSA est qu’un artefact logiciel n’est fiable que s’il répond à trois exigences :

1. L'artefact doit avoir un document de provenance décrivant son origine et son processus de construction (L1).
2. Le document de provenance doit être fiable et vérifié en aval (L2).
3. Le système de construction doit être digne de confiance (L3).

Le cadre SLSA définit des niveaux qui représentent le degré de sécurité de la chaîne d'approvisionnement logicielle. Ces niveaux correspondent au niveau de mise en œuvre de ces exigences (noté L1-L3 ci-dessus).

Scribe valint slsa La commande peut être utilisée pour produire des documents de provenance. Nous décrivons ci-dessous comment atteindre les niveaux SLSA en utilisant cet outil.

Remarque : Nous faisons ici référence au framework SLSA V1.0.

SLSA L1

Votre exigences pour SLSA L1 comprennent :

• Les producteurs de logiciels suivent un processus de construction cohérent.
• La plateforme de construction génère automatiquement des données de provenance décrivant comment l'artefact a été construit.
• Les producteurs de logiciels distribuent les données de provenance aux consommateurs.

Liste de contrôle pour atteindre SLSA L1 :

• Créez votre logiciel à l'aide d'un système CI. Utilisez de préférence un script de build contrôlé par le code source.
• Activez la valint slsa commande dans le cadre de votre script de construction pour créer un document de provenance. Notez que le valint slsa  La commande permet d’ajouter des informations supplémentaires au document de provenance – vous pouvez adapter le contenu du document de provenance à vos besoins.

SLSA L2

Votre exigences pour SLSA L2 comprennent :

• Les exigences SLSA L1.
• La construction s'exécute sur une plate-forme de construction hébergée qui génère et signe elle-même la provenance.
• La vérification en aval de la provenance comprend la validation de l'authenticité de la provenance.

Liste de contrôle pour atteindre SLSA L2 :

• La liste de contrôle SLSA L1.
• Utilisez un service de build hébergé (au lieu d'effectuer la build sur la machine du développeur).
• Créez un document de provenance signé (au lieu d'un document non signé, ce qui est suffisant pour SLSA L1). Cela peut être réalisé en exécutant valint slsa ... -o attest. Scribe vaillant l'outil dispose d'un large éventail de capacités de signature ; pour une entreprise, nous recommandons d’utiliser des clés et certificats PKI X.509. 
• Vérifier l'authenticité du document de Provenance en aval à l'aide du valint verifycommande. La vérification peut inclure la signature et l'identité du signataire, ainsi que d'autres règles de vérification qui garantissent le contenu du document SLSA Provenance. Quelques exemples peuvent être trouvés dans Scribe's catalogue de politiques.

Remarque : La vérification doit être effectuée par le consommateur du logiciel construit ; pour la conformité interne, la vérification peut être effectuée dans le cadre d’un pipeline de tests.

SLSA L3

Exigences SLSA L3

Votre exigences pour SLSA L3 comprennent :

• Les exigences SLSA L2.
• La plateforme de build met en œuvre des contrôles stricts pour :
  • Empêchez les exécutions de s’influencer les unes les autres, même au sein du même projet.
  • Empêchez les secrets utilisés pour signer la provenance d'être accessibles à partir des étapes de construction définies par l'utilisateur.

De plus, pour faire confiance à la plateforme de build, il faut vérifier la plateforme de construction. La plateforme de construction doit être fiable dans le sens où le document de provenance sera infalsifiable et la construction sera isolé. Une telle vérification découle des exigences suivantes :

• Vérifier que l'utilisation de la plateforme ne casse pas l'infalsifiable et l'isolement exigences.
  • La vérification de l'isolation, par exemple, peut être effectuée en évaluant l'utilisation du cache dans le pipeline.
  • Pour garantir l'infalsibilité du document de provenance, nous vous recommandons de le générer et de le signer dans un pipeline de build dédié.
• Vérifiez le fiabilité de la plateforme de construction.
  •  Pour les CI SaaS, une vérification doit être effectuée auprès du fournisseur de la plateforme de build. Dans les cas où le producteur du logiciel est responsable du déploiement du système de build, une combinaison d’auto-attestation du fournisseur et d’analyse des aspects du déploiement est recommandée.
  • Par exemple, lors du déploiement d'un CI auto-hébergé, l'attestation du fournisseur doit déclarer comment les builds sont isolées les unes des autres, et l'analyse du déploiement doit vérifier les autorisations d'accès et l'audit des journaux du système CI.

Ces exigences sont difficiles car leur satisfaction dépend de la plate-forme CI, ne peut pas être entièrement automatisée et nécessite une analyse professionnelle de la sécurité des systèmes de construction et des pipelines. C'est pourquoi le cadre SLSA suggère spécifiquement que les organisations évoluent progressivement de la conformité SLSA L2 à la conformité SLSA L3.

Si vous avez parcouru cet article jusqu'ici et décidé que SLSA L3 est la bonne chose pour vous, retroussez vos manches – voici notre recommandation pour une liste de contrôle :

Liste de contrôle pour atteindre SLSA L3 :

• La liste de contrôle SLSA L2.
• Évaluez le système CI. L’objectif est de répondre aux questions suivantes :
  • Dans quelles conditions une entité non autorisée peut-elle échapper au système de construction ?
  • Dans quelles conditions les constructions peuvent-elles s’influencer mutuellement ?

Une fois la réponse obtenue, gérez les risques restants.

• Isoler la génération du document Provenance :
  • Séparez la création du document de provenance dans un pipeline différent, de préférence sur un service de build distinct.
    • Exposez à ce pipeline uniquement les secrets utilisés pour signer le document de provenance.
    • Créez ou vérifiez le contenu du document de provenance sur ce pipeline. En cas de vérification, vérifiez tous les champs possibles d'un document de provenance généré dans le pipeline avec les données collectées directement à partir de la plateforme de génération ou d'autres sources fiables.
• Isolez et vérifiez l'isolation du pipeline de build des autres exécutions de pipeline :
  • Vérifiez l'utilisation des caches et des volumes partagés.
  • Vérifiez que les secrets partagés avec d'autres pipelines ne peuvent pas permettre aux pipelines de s'influencer mutuellement.
  • Vérifiez que les exécutions de pipeline ne peuvent pas s'influencer mutuellement
    • Par exemple, évitez que les installations réalisées via un pipeline n’affectent les autres tronçons de pipeline. Cela peut être fait en utilisant des build-runners éphémères (tels qu'un conteneur créé pour chaque build) ou en vérifiant que les build-runners démarrent à chaque fois à partir d'un état prédéterminé.

Pour atteindre SLSA L3 avec les outils Scribe, nous recommandons ce qui suit :

• Instrumentez le pipeline de construction pour générer toutes les attestations qui seront nécessaires pour remplir le document de provenance. Par exemple, vous pouvez décider de vouloir une liste des dépendances installées lors de la construction. Cette liste peut être générée par un valint bom dir:commande. De plus, créez une attestation de provenance dans le pipeline à l'aide du valint slsa commander.
• Créez un pipeline distinct de génération de provenance approuvée qui effectuera les tâches suivantes :
  • Générer un document de provenance fiable basé sur celui créé dans le pipeline de build ;
    • Collectez les données du service de build et utilisez-les pour vérifier et mettre à jour le document de provenance.
    • Vérifiez le contenu des attestations créées dans le pipeline de build. Par exemple, vérifiez le contenu du build-runner en comparant une attestation SBOM du pipeline de build avec une attestation SBOM échantillonnée séparément.
    • Utilisez les attestations collectées à partir du pipeline de build pour mettre à jour le document de provenance.
    • La mise à jour du document de provenance peut être effectuée à l'aide du valint slsa commander.
  • Vérifiez que la build a été isolée en évaluant les données collectées à partir du service de build. Par exemple, vérifiez l'utilisation des caches et des secrets.

Afin d'effectuer une telle collecte et évaluation de données, Scribe fournit des outils qui créent des attestations de l'exécution de la build et effectuent les vérifications nécessaires.

---

D'accord. Il semble que vous soyez prêt à partir. Bien sûr, si vous avez besoin d'aide, nous l'indiquer. Nous sommes là pour vous aider et serions ravis de vous conseiller ou de vous aider activement.

articles similaires

ML-Quoi ? Comprendre le concept et les utilisations de ML-Bom

L'industrie n'a pas encore pleinement compris l'idée d'un SBOM, et nous avons déjà commencé à entendre un nouveau terme – ML-BOM – Machine Learning Bill of Material. Avant que la panique ne s'installe, comprenons pourquoi une telle nomenclature doit être produite, les défis liés à la génération d'une ML-BOM et à quoi une telle ML-BOM peut ressembler. […]

Dans quelle mesure êtes-vous sûr de ce qui se passe réellement dans votre pipeline CI/CD ? Les éléments que vous devez sécuriser et comment

Les pipelines CI/CD sont notoirement opaques quant à ce qui se passe exactement à l’intérieur. Même si c'est vous qui avez écrit le fichier de configuration YAML (la liste d'instructions du pipeline), comment pouvez-vous être sûr que tout se déroule exactement comme décrit ? Pire encore, la plupart des pipelines sont complètement éphémères, donc même si quelque chose de grave se produit, il n'y a pas de […]

Naviguer dans les directives SBOM de la NSA : étapes essentielles pour une sécurité efficace de la chaîne d'approvisionnement logicielle

Dans le paysage numérique actuel, la sécurité des logiciels est primordiale. La National Security Agency (NSA), en collaboration avec la Cybersecurity and Infrastructure Security Agency (CISA), a établi des lignes directrices complètes pour la gestion des nomenclatures logicielles (SBOM). Ces lignes directrices sont cruciales pour les organisations qui souhaitent renforcer leur posture de cybersécurité et atténuer les risques dans leur chaîne d’approvisionnement logicielle. Pourquoi […]