Utiliser Valint pour appliquer des politiques à votre SDLC

Valint est le principal outil Scribe pour créer, gérer, signer et vérifier des preuves. Dans un post précédent, nous avons abordé la théorie de l'utilisation des preuves de signature et de vérification comme outil principal pour valider la sécurité de votre pipeline CI/CD. Pour rappel, le modèle proposé par Scribe comprend plusieurs blocs de construction qui peuvent être mélangés et empilés de la manière qui convient à vos besoins. Les éléments de base comprennent les preuves recueillies (SBOM, SLSA provenance, tous résultats de tests tiers que vous souhaitez inclure), le contexte environnemental des preuves collectées (qui les a créées, où, quand, etc.) et la politique que vous souhaitez appliquer à ces preuves.

Étant donné que les politiques que vous souhaitez appliquer à vos preuves sont un facteur clé dans ce modèle, nous avons pensé consacrer un article de blog pour explorer plus en détail le potentiel du moteur politique que nous proposons.

Dans cet article, nous passerons en revue la politique la plus élémentaire que nous avons conçue (signer et vérifier les informations). Nous verrons à quoi ressemble le modèle d'une stratégie plus complexe et donnerons quelques exemples standards de stratégies, comme comment vérifier qu'un utilisateur spécifique est celui qui a créé la dernière branche « principale », ou comment vérifier que votre pipeline s'exécute. comprend un test d'outil tiers qui doit être inclus.

Commencez ici : signer et vérifier les preuves

Valent est un outil très polyvalent mais pour garder cet article simple, nous utiliserons principalement l'interface CLI de Valint comme exemple.

La première étape serait de télécharger Valint :

curl -sSfL https://get.scribesecurity.com/install.sh | sh -s -- -t valint

La commande pour créer un SBOM à partir d'un référentiel ou d'une image est 'bom'. Ainsi, par exemple, si vous souhaitez bom l'image de busybox:latest la commande ressemblera à ceci :

$HOME/.scribe/bin/valint bom busybox:latest -o attest -f

Notez que attest est un alias pour attest-cyclonedx-json.

Par défaut, Valint utilise magasin de signatures flux interactif comme moteur derrière le mécanisme de signature intégré dans la bibliothèque Cocosign de Scribe. Cette bibliothèque traite des signatures numériques pour la signature et la vérification. Une fois que vous aurez appliqué la commande, vous devrez d'abord approuver votre souhait de signer la preuve avec une option Y/[N] :

Vous pouvez également utiliser une PKI standard pour la signature (nous prenons en charge les certificats x509). Il existe plusieurs options pour stocker la clé de signature – par exemple KMS, magasin secret GitHub, et vous pouvez facilement configurer Valint pour utiliser le mécanisme de signature de votre choix.

En supposant que vous approuvez la signature, vous serez dirigé vers Sigstore dans votre navigateur où vous devrez vous connecter en utilisant soit votre compte GitHub, votre compte Google ou votre compte Microsoft :

Une fois connecté, vous verrez que la connexion a réussi :

à ce stade, vous pouvez fermer le navigateur et revenir à votre shell où vous pouvez voir que la preuve a été créée avec succès.

L'attestation est écrite par défaut dans le cache local dont l'emplacement est fourni par le --output-directory flag dans le fichier de configuration flag. Vous pouvez également utiliser le -fichier de sortie flag pour fournir un chemin personnalisé pour l’attestation.

Maintenant que nous avons créé une attestation signée, essayons de vérifier qu'elle existe et qu'elle est signée. La commande pour vérifier les preuves est verify. La façon de l'utiliser est presque identique à celle du bom commande sauf que nous utiliserons le drapeau -iqui est l'abréviation de --input-format et la valeur par défaut est, comme dans bom, attest-cyclonedx-json. La commande verify recherchera d'abord les preuves dont elle a besoin dans l'emplacement par défaut utilisé par Valint. Vous pouvez spécifier un emplacement différent si vous souhaitez à la fois enregistrer les preuves et les rechercher ultérieurement.

Donc, si l'on veut vérifier le busybox:latest attestation d'image que nous avons générée et signée dans l'exemple précédent, la commande ressemblera à ceci :

$HOME/.scribe/bin/valint verify busybox:latest -i attest

En supposant que vous ayez tout fait correctement, le résultat devrait ressembler à ceci :

Vous pouvez voir la liste des e-mails qui incluent l'e-mail du signataire sur l'attestation d'origine et vous pouvez également voir le type d'attestation qui a été vérifiée, dans ce cas, cyclonedx-json. 

Cela semble assez simple, n'est-ce pas ? Montons d'un cran.

Modèles de politique

A politique se compose d'un ensemble de modules. La politique est vérifiée si tous les modules qu'elle comprend sont évalués et vérifiés. Un module est vérifié si TOUTE preuve conforme à la configuration et aux paramètres du module est trouvée.  

Les politiques sont configurées dans le cadre du fichier de configuration de Valint, sous la section politiques. Ceci est un exemple d'une partie d'un fichier de configuration Valint, la partie contenant les politiques potentielles. 

N'oubliez pas que vous n'êtes pas obligé d'inclure un fichier de configuration dans votre projet – Valint peut très bien fonctionner avec uniquement les options par défaut activées. De plus, puisque tout ce qui se trouve dans ce fichier est facultatif, il est parfaitement valable d'avoir un tel fichier qui inclut UNIQUEMENT vos politiques. 

Le fichier de configuration, nommé par défaut .valint.yaml, doit être inclus à la racine de votre référentiel. En fonction des stratégies que vous incluez dans ce fichier, lorsque vous exécutez la commande valint verify il exécutera toutes les politiques et modules activés. Étant donné que la politique de base « vérifier » est la politique par défaut, vous n'avez rien à configurer pour le verify commande pour fonctionner correctement même sans fichier .valint.yaml.

Quelle que soit la stratégie que vous ajoutez au fichier de configuration, elle dépend de la nécessité de rechercher des preuves. Par défaut, lorsque vous exécutez la commande « bom » dans votre pipeline, les preuves obtenues seront téléchargées dans le magasin de preuves Scribe. De même, lorsque vous exécutez la commande « vérifier », elle recherchera les preuves dans le magasin de preuves Scribe. Vous pouvez modifier cette valeur par défaut et utiliser un OCI ou un cache comme magasin de preuves, mais pour cet article, nous supposerons que la valeur par défaut est utilisée et que toutes les preuves sont téléchargées et extraites du magasin de preuves Scribe.

Ainsi, sur la base de cet exemple, examinons les composants d'une politique. Le politique prend en charge les champs suivants :

• prénom, le nom de la stratégie (obligatoire).
• permettre, activez le module (la valeur par défaut est false).
• modules, liste des configurations du module de stratégie.  

 

Votre module les sections prennent en charge les champs suivants :

• prénom, le nom du module de stratégie (obligatoire).
• permettre, activez le module (la valeur par défaut est false).
• type, type de module, supportant actuellement vérifier-artefact et propriétaire de git.
• rencontre, faire correspondre les preuves avec un contexte spécifique.
• contribution, configuration spécifique au module.

Une stratégie peut avoir plusieurs modules et tous les modules activés seront exécutés une fois que vous aurez exécuté la commande « vérifier ». 

Puisque je sais qu’une liste sèche de champs n’est pas très informative, passons directement à la section suivante, des exemples de politiques.

Exemples de politiques

Politique de vérification des images

Commençons par la politique la plus simple, celle qui exprime le flux de vérification de signature Valint. 

attester : cocosign : politiques : - nom : verify_policy activer : vrai modules : - nom : signé_sbom type : vérifier-artefact activer : vrai entrée : signé : vrai format : attest-cyclonedx-json identité : e-mails : - barak@scribesecurity.com

Encore une fois, cette politique doit être incluse dans le fichier .valint.yaml à la racine de votre référentiel. Pour que cela fonctionne, vous devrez avoir créé au préalable un SBOM signé en exécutant le valint bom commande. Une fois que vous êtes prêt à le vérifier, vous devrez exécuter le valint verify commander.

En regardant cet exemple, nous pouvons voir que la stratégie est activée et qu'elle possède un module activé de type ‘verify-artifact‘. Le module vérifie que l'entrée est signée, est au format ‘attest-cyclonedx-json’, et qu'il a été signé par l'identité représentée par l'email ‘barak@scribesecurity.com’.

Pour exécuter cette stratégie, nous devrons exécuter le verifycommande dans notre pipeline comme ceci :

valint verify busybox:latest

Depuis l' verify la commande est maintenant basée sur la politique que nous avons fournie, elle recherchera un busybox:latest élément de preuve dans votre magasin de preuves Scribe. Il recherchera un SBOM signé au format `cyclonedx-json` et il vérifierait que l'identité qui a signé le SBOM utilise l'email prescrit dans la politique `barak@scribesecurity.com`.

Vous pourriez dire qu’il pourrait y avoir plusieurs images comme celle-là dans cet entrepôt de preuves et vous auriez raison. C'est là que le contexte entre en jeu. Par défaut, verify La commande recherchera la correspondance la plus proche disponible. Vous pouvez cependant spécifier que la commande devra correspondre au contexte de l'ID d'exécution du pipeline ou au système de build dans lequel l'artefact a été créé. Pour ce faire, vous devrez utiliser le champ match: avec le type de contexte approprié. Par exemple:

            correspondance : type_contexte : github git_url : github.com/my_org/myimage.git branche : principale

Dans ce cas, les preuves devaient avoir été générées par Github, par le référentiel nommé par le git_url et par main branche de ce référentiel. Il est important d'utiliser le bon contexte lorsque cela est nécessaire pour vous assurer que vos politiques vérifient exactement ce que vous souhaitez qu'elles vérifient. 

Politique de vérification binaire

Examinons un autre exemple. Cette politique vise à vérifier qu'un fichier exe que nous vérifions provient d'un référentiel spécifique et a été signé par l'une des nombreuses personnes connues. 

attester : cocosign : politiques : - nom : verify_policy activer : vrai modules : - nom : module_binaire type : vérifier-artefact activer : vrai entrée : signé : vrai format : attest-cyclonedx-json identité : e-mails : - barak@scribesecurity.com - mikey@scribesecurity.com - adam@scribesecurity.com correspondance : target_type : fichier context_type : azure git_url : https://dev.azure.com/mycompany/somerepo # URL Git de l'environnement. nom_entrée : mon_binaire.exe

En regardant cet exemple, nous pouvons voir que la stratégie est activée et qu'elle possède un module activé de type ‘verify-artifact‘ Le module vérifie que l'entrée est signée, qu'elle est au format ‘attest-cyclonedx-json’, et qu'il a été signé par 1 des 3 e-mails autorisés répertoriés dans le module. De plus, il vérifie que le verify la commande reçoit une entrée pour vérifier que l'entrée est nommée ‘my_binary.exe’, que l'entrée est un fichier créé dans Azure et qu'elle provient d'une URL git spécifique : https://dev.azure.com/mycompany/somerepo.

Comme vous pouvez le constater, cet exemple comporte beaucoup plus d'exigences pour que la stratégie soit vérifiée.

Pour exécuter cette stratégie, nous devrons exécuter le verify commande dans notre pipeline comme ceci :

valint verify file:my_binary.exe

Pour vous assurer que votre magasin de preuves Scribe dispose d'une version signée de ce binaire, vous devez d'abord créer les preuves comme ceci :

valint bom file:my_binary.exe -o attest

Politique de vérification des preuves par des tiers

Dans notre dernier exemple, voyons comment nous pouvons vérifier qu'un outil tiers que nous utilisons a fonctionné correctement dans notre pipeline et a créé le résultat attendu sous la forme d'un fichier JSON. 

attester : cocosign : politiques : - nom : verify_policy activer : vrai modules : - nom : type de règle tierce : vérifier-artefact activer : vrai entrée : signé : faux format : attester d'identité générique : e-mails : - bob@scribesecurity. com match : target_type : type de contexte générique : azure git_url : https://dev.azure.com/mycompany/somerepo git_branch : nom_d'entrée principal : 3rd-party-scan.json

Dans cet exemple, nous imaginons qu'à un moment donné du pipeline, nous avons exécuté un outil tiers qui a créé, en conséquence, le fichier « 3rd-party-scan.json ». Pour satisfaire à la stratégie, ce fichier doit provenir d'Azure DevOps, déclenché par le `https://dev.azure.com/mycompany/somerepo` dépôt et signé par `bob@scribesecurity.com`. 

Pour générer les preuves que nous recherchons, juste après l'exécution de l'outil tiers, nous devons capturer le fichier résultant et le transformer en preuve à l'aide de Valint :

valint bom 3rd-party-scan.json -o attest-generic --predicate-type https://scanner.com/scan_format

Que prouvent les preuves ? 

Nous avons donc vu que nous pouvons utiliser Valine pour vérifier diverses choses dans notre pipeline. À quoi peut réellement servir cette capacité ?

Imaginons que notre pipeline ait été violé et que des méchants aient commencé à y faire des choses que nous ne voulons pas qu'ils fassent. En vérifiant que les différentes étapes du pipeline se sont déroulées comme prévu, produisant les résultats escomptés et signées par le personnel approuvé, nous rendons encore plus difficile la tâche des méchants qui peuvent nous tromper.

Une attaque potentielle consiste à remplacer le fichier binaire à la fin du pipeline afin que la version obtenue par vos clients soit malveillante plutôt que la version originale. En signant votre version et en demandant à vos clients de vérifier par rapport à cette copie principale, vous pouvez vous assurer qu'ils utilisent tous le même fichier que vous avez produit et non une contrefaçon intelligente.

Ce modèle de création de preuves puis de vérification ne fait que commencer. Nous travaillons constamment à ajouter des fonctionnalités supplémentaires à Valint pour le rendre encore plus robuste et polyvalent. En attendant, je vous encourage à consulter notre Documentation pour en savoir plus sur ce que Scribe a à offrir et sur ce que vous pouvez faire de plus avec Valint. Valint est gratuit à télécharger et à utiliser, donc rien ne devrait vraiment vous empêcher d'essayer cet outil aujourd'hui.