Au fur et à mesure que tout le monde prend conscience, protéger vos chaînes d'approvisionnement en logiciels devrait être un élément essentiel de la stratégie de cybersécurité de chaque organisation.
L’une des principales difficultés liées à la création d’une stratégie globale visant à atténuer les menaces liées à la chaîne d’approvisionnement logicielle réside dans la complexité et la diversité des chaînes d’approvisionnement. Chaque chaîne d'approvisionnement est unique et les éléments impliqués changent constamment, ce qui rend difficile la confiance dans votre propre chaîne d'approvisionnement, sans parler des logiciels qu'elle produit.
Dans cet article, nous décrirons une plate-forme de conformité continue qui permet aux consommateurs et aux producteurs de logiciels de démontrer de manière transparente leur confiance et leur conformité pour sécuriser SDLC, promouvoir les meilleures pratiques de sécurité, répondre aux exigences réglementaires et atténuer les risques. cyber-risques en utilisant aattestations.
Le modèle proposé se compose de blocs définis qui peuvent être facilement étendus et intégrés à votre pile, quelle que soit votre plate-forme préférée ou vos cas d'utilisation. Nous terminerons par la démonstration d'une politique de vérification de base utilisant Outil Valint de Scribe pour montrer que ce processus n'est pas aussi compliqué qu'on pourrait le craindre au premier abord.
Théorie du chaos de la chaîne d’approvisionnement
L’un des principaux défis liés à la sécurisation des chaînes d’approvisionnement réside dans la complexité des systèmes impliqués. Votre chaîne d'approvisionnement logicielle comprend tous les logiciels impliqués dans la création de votre produit final, soit dans le cadre de l'environnement, soit en tant que logiciel intégré à votre base de code. Vous pouvez dire par cette description que ces chaînes d'approvisionnement sont vastes et incluent tout depuis le moment où un développeur commence à écrire du code jusqu'à la compilation, les tests, l'intégration et jusqu'au point où le produit final est exécuté et intègre chaque élément de logiciel et bibliothèque utilisés en cours de route.
Définir le modèle de sécurité de tels systèmes nécessite de comprendre la vaste gamme de programmes langages, gestionnaires de packages, produits, piles technologiques, services CI, fournisseurs de cloud, importations de dépendances, machines virtuelles, systèmes d'exploitation et autres composants pouvant être inclus dans une chaîne d'approvisionnement donnée. Il est essentiel de prendre en compte le large éventail d'actifs qui pourraient être menacés au sein d'un tel système, notamment les applications, les jetons, les clés et autres formes d'autorisations d'accès.
Présentation du modèle de vérification des politiques
Le modèle proposé comprend plusieurs éléments de base qui fonctionnent ensemble pour garantir la sécurité et la conformité d'une chaîne d'approvisionnement.. Ces éléments de base sont nécessaires pour vérifier en permanence les aspects de sécurité des logiciels et la conformité à la réglementation de la chaîne d’approvisionnement logicielle.
- Preuve: Objets immuables destinés à être consommés automatiquement par les stratégies. Ces objets contiennent les métadonnées nécessaires pour permettre l'application des politiques et répondre aux exigences de conformité. Le contenu des preuves comprend des métadonnées sur les artefacts, les événements et les paramètres, mais peut également collecter des rapports, des configurations ou des analyses réels.
Preuve peut se présenter sous une forme signée ou non. Nous vous suggérons de suivre le in-toto spécification d'attestation en utilisant le signé attestation et non signé déclaration formats, respectivement.- Attestations (AKA preuve signée vérifiable) : Preuve vérifiable liée à un contexte environnemental, transmettant la confiance à l'aide d'une certaine forme de signatures PKI.
- Contexte environnemental: Les informations contextuelles relient le modèle.
Il répond à la question de savoir d’où proviennent les preuves et quelles informations elles contiennent. Il est important que le contexte soit lié à la preuve plutôt que d'en faire partie, car vous pouvez avoir plusieurs éléments de preuve liés au même contexte et ce modèle permet une recherche et une récupération de preuves plus faciles et plus efficaces.
En termes simples, un contexte environnemental est un système d'étiquetage dans lequel la plupart des étiquettes sont lues à partir de l'environnement, de la plateforme ou des artefacts. Les étiquettes fournissent un accès normalisé à de nombreux processus de votre processus de développement et de votre pipeline CI/CD. Aspects liés à l'origine des preuves tels que les référentiels Git, les balises et les commits, mais aussi les noms de workflow, les noms de tâches, le runID, etc. Le contexte environnemental peut également inclure des aspects du sujet, tels que les hachages d'artefacts, les noms et les balises.
Le contexte peut être considéré comme une extension du in-toto Spécification d'attestation, intégré à la charge utile signée. Grâce au système d’étiquetage, nous pouvons fournir à la phase d’évaluation des politiques un moyen d’interroger les preuves par étiquettes sous divers aspects. En outre, les données contextuelles peuvent être utilisées dans le cadre du processus d’évaluation des politiques, ajoutant ainsi une « connaissance de la situation » aux données probantes.
- Autres Conditions Un ensemble de modules de stratégie configurés par l'utilisateur qui définissent le rapport de conformité requis. Les politiques peuvent spécifier les normes de sécurité minimales ou les niveaux de conformité requis pour différents types de produits ou de systèmes inclus dans votre pipeline de build ou votre processus de développement. Plus important encore, les évaluations politiques qui en résultent créent des rapports de conformité qui sont attestations aussi. Cela nous permet non seulement de gérer les rapports de conformité (par exemple, en exposant votre statut de conformité aux parties prenantes), mais également d'utiliser le rapport de conformité pour des politiques plus complexes pouvant englober une portée plus large de réglementation de conformité pour une organisation. Les politiques peuvent être regroupées en modules de politique. Ce sont des plugins qui implémentent des ensembles de règles de politique partageant certaines caractéristiques (similaires aux modules logiciels). Ces plugins sont fournis par les fournisseurs de politiques (nous y reviendrons plus tard).
L'évaluation d'un module de stratégie fournit des résultats qui incluent des évaluations, des détails de conformité et des verdicts faisant référence à la réglementation de sécurité en question. En outre, les résultats incluent l'historique des preuves nécessaires pour revenir en arrière sur le module de preuves évalué pour sa conformité. - Magasins: Services fournissant des capacités d'hébergement, de téléchargement/téléchargement et d'interrogation de preuves (nous y reviendrons plus tard). Ils peuvent être utilisés sur des registres d'images (OCI comme stockage), des services dédiés (c'est-à-dire Scribe Service) ou simplement le système de fichiers local.
- Fournisseurs de politiques : Il s'agit d'entités (entreprises, organisations) chargées de signer et de fournir des modules de politique. En fournissant des politiques comme type d’attestation, les prestataires transmettent confiance et transparence à la politique elle-même. Par exemple, une attestation de bundle OPA peut permettre aux régulateurs de publier et de signer des bundles OPA officiels mettant en œuvre des modules de politique.
En utilisant ces éléments de base, notre modèle permet aux organisations de vérifier la sécurité et la conformité de leurs pipelines de construction et de leur cycle de vie de développement avec une relative facilité.
Comment ça marche
Le point de départ de ce flux de travail est un développeur ou un système, générant des preuves pour un produit ou un composant logiciel. Le contenu des preuves, ainsi que les informations contextuelles, les sujets et les signatures, sont collectés et téléchargés dans un magasin de preuves.
D'un autre côté, les rapports de conformité sont créés en évaluant les politiques adaptées aux besoins et exigences de l'organisation.
À l'aide d'informations contextuelles, les évaluations politiques peuvent interroger les preuves produites par votre chaîne d'approvisionnement et garantir qu'elles contiennent toutes les informations que la réglementation pourrait exiger..
Comme avantage supplémentaire, les politiques et les rapports de conformité sont eux-mêmes accessibles comme preuves, offrant transparence et confiance ainsi qu'un historique de toutes les preuves impliquées. Cela permet aux organisations de gérer les rapports de conformité mais également de les utiliser comme attestations de confiance pour transmettre la confiance aux utilisateurs de logiciels..
En utilisant ce flux, les organisations et les parties prenantes peuvent réduire les risques, assurer la transparence et assurer la conformité au sein de leur chaîne d'approvisionnement, réduisant ainsi l'impact du chaos et améliorant la sécurité et la confiance globales dans leurs produits.
Évaluation des politiques
La évaluation d'une politique se fait en vérifiant un ensemble de modules de politique, chacun respectant des réglementations et des besoins de conformité spécifiques.
Une évaluation politique pose à chaque module deux questions simples :
- Quelles preuves sont requises pour se conformer au module ?
- Quels sont les critères permettant de prouver la conformité ?
Par exemple, dans le cadre du Cadre SLSA (Supply Chain Levels for Software Artifacts), les modules de stratégie peuvent spécifier qu'une preuve de provenance SLSA signée et une analyse de la posture de sécurité pour le pipeline de build sont toutes deux requises pour se conformer aux exigences de sécurité. Les preuves fournies par ces modules seraient ensuite vérifiées pour garantir qu'elles répondent à toutes les exigences SLSA.
- Quelles preuves sont requises pour se conformer aux exigences SLSA ?
- Une attestation de provenance SLSA (preuve signée) de l’artefact construit.
- Analyse de la posture de sécurité du pipeline CI produisant l'artefact.
- Quels sont les critères de preuve prouvant la conformité aux exigences SLSA ?
- Les deux éléments de preuve doivent inclure des informations qui répondent à toutes les exigences de la SLSA.
Pour cet exemple, l'attestation de provenance SLSA doit décrire votre processus de création d'image dans son intégralité, tandis que l'attestation de sécurité doit vérifier que le SCM qui a stocké la source de l'image utilise des règles de protection de branche.
- Les deux éléments de preuve doivent inclure des informations qui répondent à toutes les exigences de la SLSA.
Un autre exemple de module de politique est le Vérifier le module Artefact, qui spécifie que certains artefacts doivent être signés par une source fiable. Utiliser des attestations (preuve signée et vérifiable) Signature PKI (Public Key Infrastructure), pour se conformer aux exigences d'une personne/entité spécifique qui doit signer les artefacts et attester du contexte d'où proviennent les artefacts.
La Vérifier le module Artefact répond aux questions suivantes :
1. Quelles preuves sont requises pour démontrer le respect des exigences de sécurité ?
- Preuve décrivant un artefact qui inclut une signature PKI (attestation).
2. Comment ces preuves peuvent-elles être vérifiées pour garantir la conformité ?
- La signature de l’attestation PKI est valide.
- L'identité du certificat PKI correspond aux exigences de l'utilisateur.
- L'objet de la preuve correspond aux exigences de l'utilisateur.
- Le format et l'origine correspondent aux exigences de l'utilisateur.
De la théorie à la pratique
Examinons la mise en œuvre de ce modèle actuellement pris en charge par l'outil Valint.
Examinons un exemple simple de stratégie qui spécifie comment vérifier les signatures et l'origine d'une image.
Plus précisément, nous devons vérifier que les preuves satisfont aux critères suivants :
- Le type de preuve est l’attestation CycloneDX SBOM décrivant une image.
- L'artefact est signé par monentreprise.com.
- L'image provient d'un workflow Circle-CI déclenché par le mon_image_src dépôt.
Politique de modèle
Dans l'exemple précédent, la stratégie était statique et vérifiait uniquement une image spécifique nommée monentreprise/mon_image. Cependant, il est souvent préférable d’avoir des politiques prenant en charge les capacités de modèles/variables. Cela vous permet de définir des exigences qui peuvent être appliquées à plusieurs processus ou artefacts similaires dans votre pipeline de génération CI/CD.
Pour modéliser la stratégie, vous pouvez utiliser une variable au lieu de verrouiller la stratégie de manière statique sur un produit. Dans l'exemple ci-dessus, vous pouvez modifier le nom_artefact valeur à `$MY_IMAGE` au lieu de cela, permettant aux évaluateurs de configurer une politique pour une multitude d'images nécessitant les mêmes règles de conformité.
Avoir hâte de
At Scribe, notre objectif ultime est d'atténuer les risques dans la chaîne d'approvisionnement grâce à un modèle de conformité vérifiable et fondé sur des preuves. L’un des premiers endroits pour essayer ce modèle est dans votre pipeline de build CI/CD. Nous pensons que cette approche de vérification des preuves est la clé pour garantir la transparence et la responsabilité dans la chaîne d'approvisionnement, avec des avantages pour toutes les parties prenantes impliquées. Notre modèle résume bon nombre des idées émergentes dans la communauté de la chaîne d’approvisionnement logicielle, définissant la relation entre bon nombre d’entre elles. Nous nous engageons à innover et à améliorer la transparence de la chaîne d’approvisionnement en logiciels. Si ce modèle a piqué votre intérêt, je vous encourage à consulter notre Documentation de la CLI Valint où nous développons les capacités et les utilisations de l'outil. N'hésitez pas à l'essayer.
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
