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

Arrière-plan

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

SPDX vs CycloneDX : comparaison des formats SBOM

Malgré l'adoption croissante de la nomenclature logicielle (SBOM) comme outil de gestion des vulnérabilités et de cybersécurité, de nombreuses organisations ont encore du mal à comprendre les deux formats SBOM les plus populaires utilisés aujourd'hui, SPDX et CycloneDX. Dans cet article, nous comparerons ces deux formats pour vous aider à choisir le bon pour […]

Comment Scribe Security s'aligne sur le Guide du leader de Gartner sur la sécurité de la chaîne d'approvisionnement logicielle

Le 20 juin 2024, Gartner a publié son influent Guide du leader sur la sécurité de la chaîne d'approvisionnement logicielle, soulignant le besoin croissant de se défendre contre les attaques de la chaîne d'approvisionnement logicielle. Avec la fréquence et la sophistication croissantes de ces attaques, les organisations sont confrontées à des risques importants qu'elles doivent gérer efficacement. Cet article interprète les conclusions essentielles du rapport de Gartner. Il explique comment Scribe […]

Comparaison de l'ASPM et du CSPM : comprendre les différences et les applications

Il est d’une importance cruciale de sécuriser les environnements et les applications cloud étant donné que le monde est désormais un village planétaire. Deux solutions essentielles à ces fins dans les organisations sont Application Security Posture Management (ASPM) et Cloud Security Posture Management (CSPM). Chacun remplit une fonction de sécurité, bien qu'ils remplissent cette fonction dans des contextes différents et […]