Qu’est-ce que la sécurité de la chaîne d’approvisionnement logicielle ?

La chaîne d'approvisionnement logicielle englobe tout ce qui influence ou joue un rôle dans un produit ou une application tout au long de son cycle de vie de développement logiciel (SDLC).

Ces dernières années, les attaques contre la chaîne d’approvisionnement logicielle sont devenues plus répandues et plus sophistiquées. Dans leur rapport 2022, Gartner États: "Anticipez l'expansion continue de la surface d'attaque de l'entreprise et augmentez les investissements dans les processus et les outils de détection et de correction des menaces d'identité et d'intégrité de la chaîne d'approvisionnement numérique."

Il est plus important que jamais de sécuriser tous les composants, activités et pratiques SDLC impliqués dans la création et le déploiement de logiciels. Les équipes de développement et les éditeurs de logiciels doivent s'assurer qu'ils n'utilisent que des composants de code exempts de vulnérabilités connues et trouver des moyens de valider l'intégrité de leur build, en vérifiant toute falsification non autorisée.

Définition de la sécurité de la chaîne d’approvisionnement logicielle

La chaîne d'approvisionnement logicielle fait référence à tout ce qui est impliqué dans le développement d'une application tout au long du cycle de vie du développement logiciel (SDLC). La création et le déploiement de logiciels nécessitent de sécuriser les activités, les processus et les composants de sa chaîne d'approvisionnement. Il existe de nombreux facteurs à prendre en compte à cet égard, notamment le code personnalisé (composants internes), les dépendances et bibliothèques open source (composants tiers), les outils et l'infrastructure DevOps qui composent le processus CI/CD, et enfin les développeurs et DevOps. équipes.

Il est de la responsabilité des organisations d'effectuer ces activités de sécurité et de fournir la preuve de leurs efforts de sécurité aux consommateurs.

 

 

Attaques contre les chaînes d’approvisionnement logicielles : pourquoi sont-elles si fréquentes ?

Les pipelines logiciels modernes sont des environnements automatisés qui s'appuient sur une variété d'outils pour une intégration et une livraison continues. Un projet logiciel peut finir par inclure des milliers de dépendances open source.

Des acteurs malveillants peuvent faire passer des bibliothèques malveillantes pour légitimes en exploitant des « failles logiques » dans les gestionnaires de paquets open source. Par exemple, des packages contenant des logiciels malveillants peuvent être attribués à des responsables de confiance à leur insu. Une telle confiance mal placée peut introduire des vulnérabilités problématiques et cachées dans votre code. Ces vulnérabilités peuvent fournir aux attaquants un accès à des données sensibles ou leur permettre d'implanter des logiciels malveillants et des systèmes de contrôle tout au long de la chaîne d'approvisionnement.

L'environnement de développement moderne possède ses propres vulnérabilités, et diverses attaques de la chaîne d'approvisionnement logicielle ont ciblé le pipeline CI/CD afin d'insérer du code malveillant à un moment donné du processus de développement. Ici aussi, une hypothèse de confiance zéro est l'approche adéquate pour gagner la confiance dans le produit logiciel final : vérifier, vérifier et valider chaque étape de la chaîne de développement interne.
Les pipelines CI/CD actuels manquent de visibilité et de contrôles pour protéger adéquatement le processus de développement logiciel. Ils ont également du mal à détecter la falsification du code, ce qui rend ce vecteur d’attaque encore plus attractif.

Le SSDF (NIST 800-218) a été finalisé et est en vigueur

Le cadre SSDF (NIST 800-218) exige que les fournisseurs mettent en œuvre des pratiques de sécurité couvrant le cycle de vie du développement logiciel (SDLC). Il promeut la transparence et les mesures inviolables dans le but de réduire les vulnérabilités de sécurité et les interférences malveillantes.

Plus précisément, il contient des lignes directrices pour une approche fondée sur des preuves visant à protéger le logiciel lui-même contre toute falsification.

Le SSDF comprend quatre parties principales :

01 /
Préparer l'organisation (PO) :

Assurez-vous que les personnes sont préparées et que les processus et la technologie sont en place pour effectuer un développement logiciel sécurisé au niveau de l'organisation et, dans certains cas, pour des groupes ou des projets de développement individuels.

02 /
Protégez le logiciel (PS) :

Protégez tous les composants logiciels de tout accès non autorisé ou falsification.

03 /
Produire des logiciels bien sécurisés (PW) :

Produisez des logiciels bien sécurisés avec des vulnérabilités de sécurité minimales dans leurs versions.

04 /
Répondre aux vulnérabilités (RV) :

Identifiez les vulnérabilités résiduelles dans les versions logicielles, réagissez de manière appropriée pour remédier à ces vulnérabilités et empêchez que des vulnérabilités similaires ne se reproduisent à l’avenir.

Vous ne devez pas considérer le SSDF comme une liste de contrôle mais plutôt comme un guide pour planifier et mettre en œuvre une approche basée sur les risques et sur des preuves pour développer des logiciels sécurisés.
Les entreprises doivent prendre des mesures pour améliorer leur posture de sécurité afin de faciliter la conformité aux changements réglementaires émergents.

SLSA est un cadre que vous devez respecter

Un cadre créé par Google, appelé SLSA (Supply-chain Levels for Software Artifacts), fournit des lignes directrices sur la manière d'atteindre quatre niveaux de protection de la chaîne d'approvisionnement logicielle. Le cadre se concentre sur l'intégrité de la construction des artefacts dans le but d'empêcher toute falsification et de sécuriser les artefacts.

SLSA fonctionne de cette manière : vous implémentez des listes de contrôle de contrôles de sécurité que vous devez implémenter dans votre pipeline, et ces contrôles se trouvent dans des sous-domaines tels que les systèmes de contrôle de code source, les systèmes de build et les dépendances que vous intégrez à vos projets logiciels.

SLSA définit quatre niveaux de conformité avec pour objectif d'atteindre le niveau 4, qui aurait la valeur de sécurité la plus élevée, mais aurait une liste d'exigences plus longue.

Le cadre SLSA est basé sur le concept de provenance. Un document qui représente une « chaîne de preuves » indiquant l'origine et le processus de construction des artefacts. À mesure que vous montez dans les niveaux SLSA, vous devez mieux protéger les preuves elles-mêmes.

Vous devez considérer SLSA comme une norme industrielle, un niveau de protection et de conformité reconnaissable et convenu auquel vous devez adhérer.

Comment sécuriser votre supply chain logicielle ?

Les différents frameworks que nous avons évoqués définissent les principes de sécurisation de la supply chain logicielle et nécessitent votre attention.

Nous tenons cependant à souligner trois classes principales de contrôles de sécurité :

1. Sécurisez la configuration de votre cycle de vie de développement logiciel

Les informations d'identification compromises, le contrôle insuffisant des autorisations et les systèmes de build vulnérables créent des surfaces d'attaque qui affectent le producteur de logiciels. Les attaquants exploitant ces vulnérabilités peuvent voler des secrets non sécurisés ou falsifier des artefacts logiciels. Une gamme de solutions commerciales et open source de cette classe peut fournir des contrôles pour cartographier les lacunes dans la posture de sécurité et y remédier.

2. Évitez de vous fier à des dépendances vulnérables ou malveillantes

Invariablement, de nouvelles vulnérabilités continueront d’être découvertes dans les logiciels open source et commerciaux. Les producteurs de logiciels doivent atténuer ce risque en mettant à niveau les composants open source vulnérables, en recherchant les vulnérabilités auto-infligées dans leur code propriétaire et en informant les utilisateurs de logiciels sur la nomenclature logicielle (SBOM) et ses implications associées. Ces consommateurs peuvent, à leur tour, agir en conséquence.

Les comptes de projets open source piratés et les packages malveillants se faisant passer pour légitimes présentent des risques supplémentaires, affectant principalement le vol de secrets dans les pipelines. La communauté open source et certains fournisseurs commerciaux s'efforcent de résoudre ce problème en améliorant la réputation et la détection des comportements malveillants.

3. Valider l'intégrité et la construction sécurisée des artefacts logiciels

La cybersécurité nécessite une défense en profondeur. Les attaques peuvent passer entre les mailles du filet lorsque l’on utilise l’approche traditionnelle de protection de la surface d’attaque, de la détection et de la réputation. De plus, de nos jours, les consommateurs de logiciels en aval ont peu d’influence sur ces contrôles. Tout au plus, ils peuvent s'appuyer sur des audits de sécurité ponctuels, tels que l'analyse du code qui fournit un instantané des vulnérabilités, des fournisseurs qui ne créent pas une réelle confiance dans la sécurité et la protection de l'artefact logiciel pendant le cycle de développement.

Une nouvelle classe émergente de contrôles est désormais disponible et atteste en permanence de l'intégrité et du processus de développement sécurisé de chaque artefact logiciel. Ces attestations ne sont pas réputées et peuvent être partagées entre les producteurs et les consommateurs en aval à la recherche d'une validation. La non-répudiation est obtenue par des méthodes cryptographiques et, par conséquent, augmente considérablement le prix à payer pour tout attaquant infiltrant la chaîne d'approvisionnement.

Cette approche est considérée comme essentielle par les experts dans le domaine de la sécurité de la chaîne d’approvisionnement logicielle. Cependant, même s'il existe certains éléments de base open source pour prendre en charge cette classe de contrôles, seuls quelques fournisseurs peuvent proposer une solution intégrée.

Une solution logicielle complète de chaîne d’approvisionnement doit inclure :

La collecte de preuves et leur signature en tant qu'attestations des processus de développement et de construction de logiciels. Généralement, ces preuves sont des hachages de fichiers avec des métadonnées qui sont comparées entre les étapes pertinentes du processus, des événements concernant les étapes liées à la sécurité telles que les identités des auteurs de code, les révisions de code, les tests de sécurité automatiques, etc. Il est également nécessaire de fournir une attestation de l'état de sécurité du processus de création du producteur du logiciel au moment de la création de l'artefact logiciel.

Un magasin d'attestations sécurisé qui permet une visibilité et prend en charge des analyses telles que la validation de l'intégrité du code.

Un moteur de politique qui mesure ces attestations par rapport à une politique définie par l'organisation ou basée sur des normes pour la validation et la démonstration de la conformité.

Un centre de partage d'informations liées à la confiance entre les producteurs ou les consommateurs de logiciels ; cela peut être inter ou intra-entreprise).

En savoir plus

La validation de l'intégrité des logiciels est un défi

Théoriquement, vérifier l’intégrité du code devrait être facile. Comparez simplement les fichiers, n'est-ce pas ? En réalité, il y a beaucoup de choses à considérer. Pour commencer, chaque langage compile les fichiers différemment. De plus, les fichiers sont utilisés très différemment selon leur finalité. Certains sont destinés à changer, tandis que d'autres sont supprimés et d'autres encore sont créés lors du processus de compilation.

Ajoutez à cela le fait que les entreprises ne veulent pas se transmettre leur code propriétaire.

Assurance du code tout au long du SDLC

Scribe s'efforce de sécuriser l'intégralité de votre SDLC en permanence. Grâce aux preuves collectées à différentes étapes du processus de développement et de construction, Scribe utilise la signature numérique pour créer des attestations infalsifiables.

Une fois signé, chaque élément de preuve peut être vérifié ultérieurement pour garantir que tous les processus se sont déroulés comme prévu et qu'aucune modification imprévue n'a eu lieu.

Suivant les meilleures pratiques énoncées dans le SSDF, Scribe vous permet d'appliquer des politiques de bon sens pour accroître votre confiance tout au long du processus de développement. Des politiques telles que l'exigence de validations signées, 2FA pour les développeurs, la révision du code par 2 personnes, etc., contribuent à générer la confiance que chaque élément logiciel a été produit conformément à la posture de sécurité correcte.

La collecte de toutes ces preuves en un seul endroit, accompagnée d'un rapport sur l'intégrité du code et d'un résumé de toutes les politiques et attestations, permet une plus grande visibilité et une plus grande confiance dans le processus de développement et les artefacts logiciels produits à la fin et est alignée sur les directives SSDF en vigueur. à la base de la nouvelle réglementation cyber.

Permettre à certains abonnés de visualiser la conformité du produit aux exigences de la politique et les résultats d'intégrité offre aux utilisateurs une plus grande visibilité et une plus grande confiance dans vos pipelines de développement et votre produit logiciel final.

Le résultat final n'est pas seulement la détection de la falsification du code ou du pipeline, mais également la capacité d'attester des tests et des procédures de sécurité qui ont eu lieu lors de la conception et de la construction du logiciel, ainsi que de l'intégrité du code source et des packages open source. utilisé pour sa construction.

En savoir plus

Explication de la sécurité de la chaîne d'approvisionnement logicielle

Qu'est-ce qui se cache dans votre code ?

Comment améliorer la confiance dans la chaîne d’approvisionnement logicielle ?

Quelles sont les implications de la version finale SSDF (NIST 800-218) ?

Qu’en est-il de l’assurance continue et de la sécurité de la chaîne d’approvisionnement logicielle ?

Pourquoi l'assurance continue est-elle une pratique intégrale pour la sécurité de la chaîne d'approvisionnement logicielle ?

Comment mettre en œuvre une évaluation automatisée de la conformité SLSA ?

Comment SBOM peut-il améliorer la sécurité de la chaîne d’approvisionnement logicielle ?

Comment sécuriser vos logiciels avec les SBOM ?

Automatisation de l'évaluation de la conformité SLSA

La sécurité des pipelines dynamiques doit être mesurée en permanence. SLSA (Supply-chain Levels for Software Artifacts) définit quatre niveaux de protection de la chaîne d'approvisionnement logicielle ainsi que des lignes directrices sur la manière de les atteindre.

Une évaluation de conformité SLSA peut être automatisée pour répondre à leurs exigences. Mais comment une organisation doit-elle procéder pour en acquérir un ? Y a-t-il des bonnes pratiques spécifiques que vous devriez suivre ?

Regardez cette vidéo dans laquelle nous partageons les meilleures pratiques pour mettre en œuvre l'automatisation, à l'aide d'outils open source tels que Sigstore et OPA dans des scénarios réels. Les meilleures pratiques conceptuelles et techniques mettent en lumière les détails et les défis du monde réel liés à l'évaluation et à l'automatisation de la conformité SLSA.

Avant d'utiliser Scribe Après avoir utilisé Scribe
Trust Hub – Partage d’informations

  • Un SBOM généré est enregistré localement par pipeline unique, sans possibilité de les gérer ou de les partager avec les parties prenantes de l'organisation ou en externe.

  • Partager et gérer les SBOM, à la fois en interne au sein de l'organisation avec d'autres parties prenantes et en externe avec les clients ou les utilisateurs
  • SBOM intelligent avec des informations exploitables
  • Les informations SBOM peuvent être utilisées comme une « porte d'accès » sur le pipeline ou le produit, utilisée pour déterminer si l'image résultante correspond à ce qui était attendu.
  • La synchronisation entre différentes équipes et organisations est désormais possible
SDLC sécurisé – Politique et conformité

  • Aucun moyen automatique ou résilient de garantir que les politiques SDLC sécurisées ont été respectées comme requis.

  • Une méthode fiable et fondée sur des preuves qui garantit que les politiques SDLC sécurisées ont été appliquées conformément aux réglementations et cadres de sécurité de la chaîne d'approvisionnement logicielle les plus récents (SLSA 3, SSDF)
Intégrité et détection d'altération

  • Uniquement ce que vous pouvez glaner à partir des journaux et des API
  • Non signé jusqu'à la toute fin du processus – juste avant la livraison (concerne uniquement le « décalage final » MITM)

  • L'assurance continue du code en utilisant le hachage et la signature continus du code à chaque étape du processus de développement permet de valider que l'artefact final est ce qu'il était censé être et qu'aucun code malveillant n'a été inséré par un acteur malveillant pendant les processus de développement et de livraison.
Visibilité

  • Tout ce que vous pouvez glaner à partir des journaux et des API
  • Enregistré localement et non signé, ce qui entraîne la possibilité que des acteurs malveillants l'aient falsifié

  • Attestations signées enregistrées dans un stockage de preuves séparé, sécurisé et inviolable
Dispositif de sécurité

  • Vérification des erreurs de configuration des outils CI/CD
  • À la recherche de secrets divulgués
  • Vérification des vulnérabilités connues (CVE)

  • Vérification des lacunes SDLC dans votre chaîne d'outils CI/CD.
  • Vérification des vulnérabilités connues (CVE) et de la réputation des dépôts OSS
  • Enregistrer des attestations infalsifiables attestant que les mesures de sécurité requises ont été prises à temps à chaque étape du processus, conformément à la politique SDLC de l'organisation.

Scribe Security - une nouvelle norme de sécurité de la chaîne d'approvisionnement logicielle

L'assurance continue du code comprend des processus et des outils qui :

Suivez chaque détail et événement du processus de développement logiciel, ainsi que l'intégrité des composants et artefacts logiciels.

Vérifiez qu'aucune falsification n'a eu lieu dans aucune des parties du processus de développement logiciel.

Vérifier l'intégrité des outils CI/CD utilisés pour construire le code

Confirmer l'intégrité du processus de développement - en s'assurant que les étapes liées à la sécurité ont été menées conformément à la politique de l'organisation et n'ont pas été contournées

En collectant et en signant des preuves de tout ce qui arrive au code, à chaque étape du cycle de vie de développement, vous compliquez la tâche des attaquants qui souhaitent falsifier les fichiers, les outils ou le comportement attendu de votre pipeline CI/CD.

En savoir plus.

Comment AIDER?

Notre plateforme unique garantit la sécurité des artefacts de code depuis Git jusqu'à la production tout au long du cycle de vie du développement logiciel, en utilisant les principaux concepts et frameworks de sécurité.

Nos clients, responsables de la sécurisation des versions de logiciels et des logiciels utilisés, comptent sur Scribe pour garantir que leurs logiciels sont sécurisés et dignes de confiance.

Contactez-Nous

Restez au courant

Assurance continue et sécurité de la chaîne d'approvisionnement logicielle | Sécurité des scribes Cyber ​​Risque
Assurance continue : une pratique intégrale pour la sécurité de la chaîne d'approvisionnement logicielle
En savoir plus.
VERSION FINALE SSDF Cyber ​​Risque
Version finale SSDF (NIST 800-218) – différences par rapport au projet et leurs implications pour vous
En savoir plus.
Image de l'article IconBurst Cyber ​​Risque
IconBust, une nouvelle attaque NPM
En savoir plus.

Les attaques contre la chaîne d’approvisionnement logicielle sont devenues plus répandues et plus sophistiquées ces dernières années. Selon un Rapport Gartner, le nombre d’attaques contre la chaîne d’approvisionnement logicielle devrait tripler d’ici 2025, touchant près de la moitié des organisations dans le monde. En raison de cette menace croissante, la sécurisation de tous les composants, activités et pratiques SDLC est plus importante que jamais.

Même s'il est difficile de prévenir attaques de la chaîne d'approvisionnement logicielle, voici quelques mesures que vous pouvez prendre pour atténuer leur impact ou réduire leurs risques : auditez votre infrastructure, tenez un inventaire à jour de tous vos actifs logiciels, évaluez les fournisseurs et appliquez une approche de confiance zéro, utilisez des outils de sécurité, sécurisez votre points de terminaison, etc.

Même s'il n'y a aucune garantie dans la vie, encore moins en matière de sécurité, il existe Meilleures pratiques en matière de sécurité de la chaîne d'approvisionnement logicielle en place, que les développeurs et les organisations de produits doivent suivre pour sécuriser leur chaîne d'approvisionnement logicielle. Au cours des différentes étapes du cycle de vie de votre logiciel, vous pouvez utiliser ces directives pour décrire, évaluer et mesurer les pratiques de sécurité au sein de votre organisation. Les meilleures pratiques entrent en jeu à chaque phase de la chaîne d'approvisionnement logicielle, y compris l'acquisition, le développement et le déploiement.

Une augmentation du nombre de risques liés à la chaîne d'approvisionnement en logiciels et une série de violations très médiatisées qui en ont résulté montrent à quel point le problème de vulnérabilité est grave. Il existe plusieurs menaces pour la chaîne d'approvisionnement en logiciels qui peuvent être posées par des logiciels tiers. Il est possible pour les attaquants d’exploiter les vulnérabilités des systèmes qui dépendent de logiciels tiers de diverses manières. Parmi ces méthodes d'attaque figurent l'introduction de code malveillant dans les logiciels, provoquant une confusion en matière de dépendances et le typosquatting.

Les attaques contre la chaîne d'approvisionnement se cachent généralement derrière des processus légitimes pour obtenir un accès illimité à l'écosystème logiciel d'une organisation. Dans la plupart des cas, les attaquants commencent par violer les défenses de sécurité d'un éditeur ou d'un fournisseur de logiciels. Une fois que le malware de la chaîne d’approvisionnement a été injecté, il doit s’attacher à un processus légitime signé numériquement. Les mises à jour logicielles sont souvent utilisées par les attaquants pour propager des logiciels malveillants tout au long de la chaîne d'approvisionnement logicielle. Certains des communs types d'attaques de la chaîne d'approvisionnement logicielle incluent : les outils de création de logiciels compromis, les certificats de signature de code volés ou les applications malveillantes signées à l'aide d'une identité volée et le code compromis dans les composants matériels ou micrologiciels.

Un SBOM (Nomenclature du logiciel), est un ensemble d'informations sur les nombreux composants qui composent un produit logiciel ou une application. Elle contient généralement des informations sur les licences, les numéros de version, les détails des composants, les fournisseurs, etc. Une liste aussi détaillée et formelle réduit les risques pour le fabricant et l'utilisateur en permettant aux autres de comprendre le contenu de leur logiciel et d'agir en conséquence.

Les SBOM permettent une visibilité des composants du produit, facilitent l'analyse des vulnérabilités, exploitent la gouvernance des licences et peuvent être utilisés pour analyser les menaces pesant sur l'intégrité.

L'assurance continue vise à dissiper l'angle mort de la chaîne d'approvisionnement logicielle. Cela implique de collecter des preuves signées sur chaque événement du cycle de vie de développement susceptible d'affecter la sécurité du produit logiciel final, y compris la construction et le déploiement du produit. Aujourd'hui, les entreprises utilisent divers outils de sécurité pour rendre leurs produits logiciels plus sécurisés. Cependant, ils établissent rarement une politique d’utilisation cohérente de ces outils.

Assurance continue garantit que les produits logiciels n'ont pas été altérés pendant le développement et que les tests liés à la sécurité ont été effectués.

Des modifications mineures du code peuvent passer inaperçues pendant longtemps. Les équipes de développement font confiance au propriétaire du code si le produit modifié est correctement signé. En conséquence, des packages contenant des logiciels malveillants peuvent être créés et attribués à des responsables populaires et fiables à leur insu. Un cas de confiance mal placée pourrait signifier une vulnérabilité problématique ou carrément code malveillant caché dans votre code.

Il est également courant que les développeurs copient et collent du code à partir de bibliothèques existantes ou de StackOverflow pour l'utiliser dans leur propre code ou pour le télécharger vers de nouvelles bibliothèques. Cela augmente les chances de copier également du code non sécurisé et vulnérable qui est désormais essentiellement impossible à suivre. 

La version finale de NIST SSDF 1.1 (Secure Software Development Framework) a été publié le 22 mars. En septembre 2021, une version préliminaire du cadre a été publiée. De nombreuses différences sont centrées sur les différents exemples fournis plutôt que sur les pratiques et les tâches de haut niveau.

Au moment de décider quelles pratiques mettre en œuvre, le NIST recommande d’équilibrer le risque par rapport au coût, à la faisabilité et à l’applicabilité. Pour garantir la sécurité des logiciels, l’automatisation d’autant de contrôles et de processus que possible est une fonctionnalité clé à considérer.

Bâtir la confiance dans votre logiciel est une tâche importante, surtout compte tenu des nouvelles normes et bonnes pratiques, telles que SSDF et SLSA. Bientôt, les vendeurs qui ne peuvent pas prouver cette confiance ne pourront plus vendre leurs produits au gouvernement fédéral américain.

Pour instaurer la confiance, vous devrez conserver et partager avec les parties prenantes le SBOM de vos produits ainsi que les preuves de leur développement et de leur construction sécurisés.

Plateforme de scribe, une véritable solution logicielle de sécurité de la chaîne d'approvisionnement de bout en bout, vous offre cette fonctionnalité. Il applique une assurance continue du code tout au long du SDLC dans une approche de confiance zéro et génère automatiquement des SBOMS partageables afin que vous puissiez obtenir des informations sur les vulnérabilités et la falsification du code.

Les pipelines dynamiques doivent être surveillés en permanence pour des raisons de sécurité. Dans Cadre de cybersécurité SLSA (Supply Chain Levels for Software Artifacts), quatre niveaux de protection pour les chaînes d’approvisionnement logicielles sont définis, ainsi que des lignes directrices sur la manière d’atteindre chaque niveau.

Vous devez suivre les meilleures pratiques pour mettre en œuvre l'automatisation, en utilisant des outils open source tels que Sigstore et OPA, pour n'en nommer que quelques-uns.