Verwenden von Valint zum Anwenden von Richtlinien auf Ihren SDLC

Valint ist das wichtigste Scribe-Tool zum Erstellen, Verwalten, Signieren und Überprüfen von Beweisen. In einem previous posthaben wir die Theorie behandelt, wie das Signieren und Verifizieren von Beweisen als Hauptinstrument zur Validierung der Sicherheit Ihrer CI/CD-Pipeline dient. Zur Erinnerung: Das von Scribe vorgeschlagene Modell umfasst mehrere Bausteine, die je nach Bedarf gemischt und gestapelt werden können. Zu den Bausteinen gehören die gesammelten Beweise (SBOMs, SLSA Herkunft, alle Testergebnisse Dritter, die Sie einbeziehen möchten), den Umweltkontext der gesammelten Beweise (wer hat sie erstellt, wo, wann usw.) und die Richtlinie, die Sie auf diese Beweise anwenden möchten.

Da die Richtlinien, die Sie auf Ihre Beweise anwenden möchten, ein Schlüsselfaktor in diesem Modell sind, dachten wir, dass wir einen Blogbeitrag widmen, um das Potenzial der von uns angebotenen Richtlinien-Engine detaillierter zu untersuchen.

In diesem Artikel gehen wir auf die grundlegendste Richtlinie ein, die wir entwickelt haben (Informationen signieren und überprüfen). Wir behandeln, wie die Vorlage für eine komplexere Richtlinie aussieht, und geben einige Standardbeispiele für Richtlinien, z. B. wie Sie überprüfen können, ob ein bestimmter Benutzer derjenige war, der den letzten „Hauptzweig“ erstellt hat, oder wie Sie überprüfen können, ob Ihre Pipeline ausgeführt wird Enthält einen Tooltest eines Drittanbieters, der enthalten sein muss.

Beginnen Sie hier: Beweise unterzeichnen und überprüfen

Valint ist ein sehr vielseitiges Tool, aber um diesen Artikel einfach zu halten, verwenden wir hauptsächlich die CLI-Schnittstelle von Valint als Beispiel.

Der erste Schritt wäre, Valint herunterzuladen:

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

Der Befehl zum Erstellen einer SBOM aus einem Repository oder einem Image lautet „bom“. Also zum Beispiel, wenn Sie möchten bom Das Bild von busybox:latest Der Befehl sieht folgendermaßen aus:

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

Beachten Sie, dass attest ist ein Alias ​​für attest-cyclonedx-json.

Standardmäßig verwendet Valint signstore interaktiver Fluss als Motor hinter dem Signaturmechanismus, der in die Cocosign-Bibliothek von Scribe eingebettet ist. Diese Bibliothek befasst sich mit digitalen Signaturen zum Signieren und Verifizieren. Sobald Sie den Befehl anwenden, müssen Sie zunächst bestätigen, dass Sie den Beweis mit der Option J/[N] unterschreiben möchten:

Sie können zum Signieren auch Standard-PKI verwenden (wir unterstützen x509-Zertifikate). Es gibt mehrere Optionen zum Speichern des Signaturschlüssels – z. B. KMS, GitHub Secret Store, und Sie können Valint einfach so konfigurieren, dass es den gewünschten Signaturmechanismus verwendet.

Vorausgesetzt, Sie genehmigen die Signatur, werden Sie in Ihrem Browser zu Sigstore weitergeleitet, wo Sie sich entweder mit Ihrem GitHub-Konto, Ihrem Google-Konto oder Ihrem Microsoft-Konto anmelden müssen:

Sobald Sie sich angemeldet haben, sehen Sie, dass die Anmeldung erfolgreich war:

Anschließend können Sie den Browser schließen und zu Ihrer Shell zurückkehren, wo Sie sehen können, dass der Beweis erfolgreich erstellt wurde.

Die Bescheinigung wird standardmäßig in den lokalen Cache geschrieben, dessen Speicherort von bereitgestellt wird --output-directory Flag in der Konfigurationsdatei Flag. Sie können auch die verwenden –Ausgabedatei Flag, um einen benutzerdefinierten Pfad für die Bescheinigung bereitzustellen.

Nachdem wir nun eine signierte Bescheinigung erstellt haben, versuchen wir zu überprüfen, ob sie existiert und signiert ist. Der Befehl zum Überprüfen von Beweisen lautet verify. Die Verwendungsweise ist nahezu identisch mit der bom Befehl, außer dass wir die Flagge verwenden -idas ist die Abkürzung für --input-format und die Standardeinstellung dafür ist, wie in bom, attest-cyclonedx-json. Der Verifizierungsbefehl sucht zunächst am von Valint verwendeten Standardspeicherort nach den benötigten Beweisen. Sie können einen anderen Speicherort angeben, wenn Sie die Beweise sowohl speichern als auch später danach suchen möchten.

Also, wenn wir das überprüfen wollen busybox:latest Bildbescheinigung, die wir im vorherigen Beispiel generiert und signiert haben, sieht der Befehl folgendermaßen aus:

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

Vorausgesetzt, Sie haben alles richtig gemacht, sollte das Ergebnis so aussehen:

Sie können die Liste der E-Mails sehen, die die E-Mail-Adresse des Unterzeichners auf der ursprünglichen Bescheinigung enthält, und Sie können auch den Typ der überprüften Bescheinigung sehen, in diesem Fall cyclonedx-json. 

Scheint ziemlich einfach zu sein, oder? Lasst es uns noch einen Schritt weiter gehen.

Richtlinienvorlagen

A Datenschutzrichtlinien besteht aus einer menge von Module. Die Richtlinie ist verifiziert, wenn alle darin enthaltenen Module evaluiert und verifiziert werden. Ein Modul wird verifiziert, wenn IRGENDWELCHE Beweise gefunden werden, die mit der Modulkonfiguration und -einstellung übereinstimmen.  

Richtlinien werden als Teil der Valint-Konfigurationsdatei im Abschnitt „Richtlinien“ konfiguriert. Dies ist ein Beispiel für einen Teil einer Valint-Konfigurationsdatei, der potenzielle Richtlinien enthält. 

Denken Sie daran, dass Sie keine Konfigurationsdatei in Ihr Projekt einbinden müssen – Valint kann problemlos funktionieren, wenn nur die Standardoptionen aktiviert sind. Da außerdem alles in dieser Datei optional ist, ist es vollkommen zulässig, eine solche Datei zu haben, die NUR Ihre Richtlinien enthält. 

Die Konfigurationsdatei mit dem Standardnamen .valint.yaml sollte im Stammverzeichnis Ihres Repositorys enthalten sein. Basierend auf den Richtlinien, die Sie in diese Datei einfügen, wenn Sie den Befehl ausführen valint verify Es werden alle aktivierten Richtlinien und Module ausgeführt. Da die grundlegende „Verify“-Richtlinie die Standardeinstellung ist, müssen Sie nichts dafür konfigurieren verify Der Befehl funktioniert auch ohne eine .valint.yaml-Datei ordnungsgemäß.

Welche Richtlinie Sie auch immer zur Konfigurationsdatei hinzufügen, hängt davon ab, dass Sie nach Beweisen suchen müssen. Wenn Sie den Befehl „bom“ in Ihrer Pipeline ausführen, werden die resultierenden Beweise standardmäßig in den Scribe-Beweisspeicher hochgeladen. Wenn Sie den Befehl „verify“ ausführen, wird in ähnlicher Weise im Scribe-Beweisspeicher nach Beweisen gesucht. Sie können diese Standardeinstellung ändern und ein OCI oder einen Cache als Beweisspeicher verwenden. Für diesen Artikel gehen wir jedoch davon aus, dass die Standardeinstellung verwendet wird und alle Beweise aus dem Scribe-Beweisspeicher hochgeladen und abgerufen werden.

Schauen wir uns also anhand dieses Beispiels die Komponenten einer Richtlinie an. Der Datenschutzrichtlinien unterstützt die folgenden Felder:

• Name, der Richtlinienname (erforderlich).
• ermöglichen, aktivieren Sie das Modul (der Standardwert ist false).
• Module, Liste der Richtlinienmodulkonfigurationen.  

 

Das Modulen Abschnitte unterstützen die folgenden Felder:

• Name, der Name des Richtlinienmoduls (erforderlich).
• ermöglichen, aktivieren Sie das Modul (der Standardwert ist false).
• tippe, Typ des Moduls, das derzeit unterstützt wird Verifizierungsartefakt und Git-Besitzer.
• Spiel, Übereinstimmung anhand von Beweisen mit einem bestimmten Kontext.
• Varianten des Eingangssignals:, modulspezifische Konfiguration.

Eine Richtlinie kann mehrere Module haben und alle aktivierten Module werden ausgeführt, sobald Sie den Befehl „verify“ ausführen. 

Da ich weiß, dass eine trockene Liste von Feldern nicht sehr informativ ist, tauchen wir gleich in den nächsten Abschnitt ein, Beispielrichtlinien.

Beispielrichtlinien

Richtlinie zur Bildüberprüfung

Beginnen wir mit der einfachsten Richtlinie, einer Richtlinie, die den Sign-Verify-Ablauf von Valint ausdrückt. 

attest: cocosign: Richtlinien: - Name: verify_policy aktivieren: wahr Module: - Name: signiertes_sbom Typ: überprüfen-Artefakt aktivieren: wahr Eingabe: signiert: wahr Format: attest-cyclonedx-json Identität: E-Mails: - barak@scribesecurity.com

Auch diese Richtlinie sollte in der Datei .valint.yaml im Stammverzeichnis Ihres Repositorys enthalten sein. Damit es funktioniert, müssen Sie im Voraus eine signierte SBOM erstellt haben, indem Sie Folgendes ausführen valint bom Befehl. Sobald Sie bereit sind, es zu überprüfen, müssen Sie Folgendes ausführen valint verify Befehl.

Wenn wir uns dieses Beispiel ansehen, können wir sehen, dass die Richtlinie aktiviert ist und über ein aktiviertes Modul dieses Typs verfügt ‘verify-artifact‘. Das Modul prüft, ob die Eingabe signiert und formatiert ist ‘attest-cyclonedx-json’, und dass es von der in der E-Mail dargestellten Identität signiert wurde ‘barak@scribesecurity.com’.

Um diese Richtlinie auszuführen, müssen wir Folgendes ausführen verifyBefehl in unserer Pipeline wie folgt:

valint verify busybox:latest

Da der verify Der Befehl basiert nun auf der von uns bereitgestellten Richtlinie und sucht nach einem busybox:latest Beweisstück in Ihrem Scribe-Beweisspeicher. Es wird nach einer signierten SBOM des Formats gesucht `cyclonedx-json` und es würde prüfen, ob die Identität, die das SBOM unterzeichnet hat, die in der Richtlinie vorgeschriebene E-Mail-Adresse verwendet `barak@scribesecurity.com`.

Man könnte sagen, dass es in diesem Beweismittellager mehrere solcher Bilder geben könnte, und Sie haben Recht. Hier kommt der Kontext ins Spiel. Standardmäßig, verify Der Befehl sucht nach der nächstgelegenen verfügbaren Übereinstimmung. Sie können jedoch angeben, dass der Befehl mit dem Kontext der Pipeline-Lauf-ID oder dem Build-System, in dem das Artefakt erstellt wurde, übereinstimmen muss. Dazu müssen Sie das Feld verwenden match: mit dem entsprechenden Kontexttyp. Zum Beispiel:

            Übereinstimmung: context_type: github git_url: github.com/my_org/myimage.git branch: main

In diesem Fall mussten die Beweise von Github generiert worden sein, und zwar von dem von ihm benannten Repository git_url und durch die main Zweig dieses Repositorys. Es ist wichtig, bei Bedarf den richtigen Kontext zu verwenden, um sicherzustellen, dass Ihre Richtlinien genau das überprüfen, was Sie überprüfen möchten. 

Binäre Verifizierungsrichtlinie

Schauen wir uns ein anderes Beispiel an. Mit dieser Richtlinie soll überprüft werden, ob eine von uns überprüfte exe-Datei aus einem bestimmten Repository stammt und von einer von mehreren bekannten Personen signiert wurde. 

attest: cocosign: Richtlinien: - Name: verify_policy aktivieren: wahr Module: - Name: Binärmodul Typ: überprüfen-Artefakt aktivieren: wahr Eingabe: signiert: wahr Format: attest-cyclonedx-json Identität: E-Mails: - barak@scribesecurity.com - mikey@scribesecurity.com – adam@scribesecurity.com match: target_type: file context_type: azure git_url: https://dev.azure.com/mycompany/somerepo # Git-URL der Umgebung. Eingabename: my_binary.exe

Wenn wir uns dieses Beispiel ansehen, können wir sehen, dass die Richtlinie aktiviert ist und über ein aktiviertes Modul dieses Typs verfügt ‘verify-artifact‘ Das Modul prüft, ob die Eingabe signiert ist und im Format vorliegt ‘attest-cyclonedx-json’, und dass es von einer der drei im Modul aufgeführten zulässigen E-Mail-Adressen signiert wurde. Darüber hinaus wird überprüft, ob die verify Der Befehl empfängt eine Eingabe, um zu überprüfen, ob die Eingabe benannt ist ‘my_binary.exe’, dass es sich bei der Eingabe um eine Datei handelt, die in Azure erstellt wurde und von einer bestimmten Git-URL stammt: https://dev.azure.com/mycompany/somerepo.

Wie Sie sehen, gibt es in diesem Beispiel noch viel mehr Anforderungen an die zu verifizierende Richtlinie.

Um diese Richtlinie auszuführen, müssen wir Folgendes ausführen verify Befehl in unserer Pipeline wie folgt:

valint verify file:my_binary.exe

Um sicherzustellen, dass Ihr Scribe-Beweisspeicher über eine signierte Version dieser Binärdatei verfügt, sollten Sie die Beweise zunächst wie folgt erstellen:

valint bom file:my_binary.exe -o attest

Richtlinie zur Beweisüberprüfung durch Dritte

In unserem letzten Beispiel sehen wir uns an, wie wir überprüfen können, ob ein von uns verwendetes Drittanbieter-Tool in unserer Pipeline ordnungsgemäß ausgeführt wurde und das erwartete Ergebnis in Form einer JSON-Datei erstellt hat. 

attest: cocosign: Richtlinien: - Name: verify_policy aktivieren: wahr Module: - Name: 3rd-party-rule Typ: verify-artifact aktivieren: wahr Eingabe: signiert: falsch Format: attest-generische Identität: E-Mails: - bob@scribesecurity. com-Übereinstimmung: Zieltyp: generisch Kontexttyp: Azure Git-URL: https://dev.azure.com/mycompany/somerepo Git-Branch: Haupteingabename: 3rd-party-scan.json

In diesem Beispiel stellen wir uns vor, dass wir irgendwann in der Pipeline ein Drittanbieter-Tool ausgeführt haben, das als Ergebnis die Datei „3rd-party-scan.json“ erstellt hat. Um die Richtlinie zu erfüllen, sollte diese Datei von Azure DevOps stammen, ausgelöst durch „https://dev.azure.com/mycompany/somerepo`-Repository und signiert von `bob@scribesecurity.com`. 

Um die gesuchten Beweise zu generieren, müssen wir direkt nach der Ausführung des Drittanbieter-Tools die resultierende Datei erfassen und sie mit Valint in Beweise umwandeln:

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

Was beweisen die Beweise? 

Wir haben also gesehen, dass wir Valine verwenden können, um verschiedene Dinge in unserer Pipeline zu überprüfen. Wofür kann diese Fähigkeit wirklich genutzt werden?

Stellen wir uns vor, dass unsere Pipeline durchbrochen wurde und dass einige Bösewichte damit begonnen haben, darin Dinge zu tun, die wir nicht wollen. Indem wir überprüfen, ob verschiedene Schritte der Pipeline wie erwartet abliefen, die erwarteten Ergebnisse lieferten und von den zugelassenen Mitarbeitern unterzeichnet wurden, machen wir es den Bösewichten noch schwerer, uns zu täuschen.

Ein möglicher Angriff besteht darin, die Binärdatei am Ende der Pipeline zu ersetzen, sodass die Version, die Ihre Kunden erhalten, eine bösartige Version und nicht Ihr Original ist. Indem Sie Ihre Version signieren und Ihre Kunden bitten, sie anhand dieser Masterkopie zu überprüfen, können Sie sicherstellen, dass alle dieselbe Datei verwenden, die Sie erstellt haben, und keine clevere Fälschung.

Dieses Modell der Beweiserstellung und anschließenden Überprüfung steht erst am Anfang. Wir arbeiten ständig daran, Valint um zusätzliche Funktionen zu erweitern, um es noch robuster und vielseitiger zu machen. In der Zwischenzeit empfehle ich Ihnen, einen Blick auf unsere zu werfen Dokumentation um mehr darüber zu erfahren, was Scribe zu bieten hat und was Sie mit Valint noch tun können. Valint kann kostenlos heruntergeladen und verwendet werden, sodass Sie wirklich nichts davon abhalten sollte, dieses Tool noch heute auszuprobieren.