Vom Chaos zur Klarheit: So sichern Sie Ihre Lieferkette mit Attestierungen

Da jeder immer bewusster wird, Schutz Ihrer Software-Lieferketten sollte ein wesentlicher Bestandteil der Cybersicherheitsstrategie jedes Unternehmens sein.
Eine der Hauptschwierigkeiten bei der Entwicklung einer umfassenden Strategie zur Minderung von Bedrohungen in der Software-Lieferkette ist die Komplexität und Vielfalt der Lieferketten. Jede Lieferkette ist einzigartig und die beteiligten Elemente ändern sich ständig, was es schwierig macht, der eigenen Lieferkette zu vertrauen, ganz zu schweigen von der Software, die sie produziert.
In diesem Artikel beschreiben wir eine kontinuierliche Compliance-Plattform, die es Softwarekonsumenten und -produzenten ermöglicht, Vertrauen und Compliance transparent nachzuweisen, um SDLC zu sichern, bewährte Sicherheitspraktiken zu fördern, regulatorische Anforderungen zu erfüllen und Abhilfemaßnahmen zu ergreifen Cyberrisiken Verwendung von aPrüfungen.
Unser vorgeschlagenes Modell besteht aus festgelegten Blöcken, die problemlos erweitert und in Ihren Stack integriert werden können, unabhängig von Ihrer bevorzugten Plattform oder Ihren bevorzugten Anwendungsfällen. Abschließend demonstrieren wir eine grundlegende Verifizierungsrichtlinie mit Valint-Werkzeug des Schreibers um zu zeigen, dass dieser Prozess nicht so kompliziert ist, wie Sie vielleicht zunächst befürchten. 

Supply-Chain-Chaos-Theorie

Eine der größten Herausforderungen bei der Sicherung von Lieferketten ist die Komplexität der beteiligten Systeme. Ihre Software-Lieferkette umfasst jede Software, die an der Erstellung Ihres Endprodukts beteiligt ist, entweder als Teil der Umgebung oder als in Ihre Codebasis integrierte Software. Anhand dieser Beschreibung können Sie erkennen, dass diese Lieferketten umfangreich sind und alles umfassen, vom Moment, in dem ein Entwickler mit dem Schreiben von Code beginnt, über das Kompilieren, Testen und Integrieren bis hin zu dem Punkt, an dem das Endprodukt ausgeführt wird und alle Teile davon integriert Software und Bibliothek, die unterwegs verwendet werden.

Um das Sicherheitsmodell für solche Systeme zu definieren, ist ein Verständnis der umfangreichen Programmiervielfalt erforderlich Sprachen, Paketmanager, Produkte, Technologie-Stacks, CI-Dienste, Cloud-Anbieter, Abhängigkeitsimporte, VMs, Betriebssysteme und andere Komponenten, die in einer bestimmten Lieferkette enthalten sein können. Es ist wichtig, das breite Spektrum an Vermögenswerten zu berücksichtigen, die in einem solchen System gefährdet sein könnten, einschließlich Anwendungen, Token, Schlüssel und andere Formen von Zugriffsberechtigungen.

Überblick über das Richtlinienüberprüfungsmodell 

Unser vorgeschlagenes Modell umfasst mehrere Bausteine, die zusammenarbeiten, um die Sicherheit und Compliance einer Lieferkette zu gewährleisten. Diese Bausteine ​​werden für die kontinuierliche Überprüfung von Software-Sicherheitsaspekten und der Einhaltung der Software-Lieferkettenvorschriften benötigt.

• Beweisbar: Unveränderliche Objekte, die automatisch von den Richtlinien genutzt werden sollen. Diese Objekte enthalten Metadaten, die zur Durchsetzung von Richtlinien und zur Erfüllung von Compliance-Anforderungen erforderlich sind. Beweisinhalte umfassen Metadaten zu Artefakten, Ereignissen und Einstellungen, können aber auch tatsächliche Berichte, Konfigurationen oder Scans erfassen.
  Beweisbar kann sowohl in signierter als auch in unsignierter Form vorliegen. Wir empfehlen, dem i zu folgenn-toto Bescheinigung spez Verwendung der unterzeichneten Bescheinigung und unsigniert Aussage Formate bzw.
  • Bescheinigungen (auch bekannt als überprüfbare, unterschriebene Beweise): Überprüfbare Beweise, die mit einer bestimmten Person verknüpft sind Umweltkontext, Vermittlung von Vertrauen mithilfe irgendeiner Form von PKI-Signaturen. 
• Umweltkontext: Die Kontextinformationen verbinden das Modell.
  Es beantwortet die Frage, woher die Beweise stammen und welche Informationen sie enthalten. Es ist wichtig, dass der Kontext mit den Beweisen verknüpft ist und nicht Teil davon ist, da Sie mehrere Beweisstücke mit demselben Kontext verknüpfen können und dieses Modell eine einfachere, effizientere Suche und den Abruf von Beweisen ermöglicht.
  Grundsätzlich handelt es sich bei einem Umgebungskontext um ein Kennzeichnungssystem, bei dem die meisten Kennzeichnungen aus der Umgebung, Plattform oder Artefakten gelesen werden. Labels bieten einen normalisierten Zugriff auf viele Prozesse Ihres Entwicklungsprozesses und Ihrer CI/CD-Pipeline. Aspekte im Zusammenhang mit der Herkunft der Beweise wie Git-Repositorys, Tags und Commits, aber auch Workflow-Namen, Jobnamen, RunID usw. Der Umgebungskontext kann auch Aspekte des Themas umfassen, wie etwa Artefakt-Hashes, Namen und Tags.
  Der Kontext kann als Erweiterung des Gesamtbildes betrachtet werden Attestierungsspez, integriert in die signierte Nutzlast. Mithilfe des Kennzeichnungssystems können wir der Phase der Richtlinienbewertung eine Möglichkeit bieten, Beweise anhand von Kennzeichnungen in einer Reihe von Aspekten abzufragen. Darüber hinaus können die Kontextdaten als Teil des Politikbewertungsprozesses verwendet werden, um den Beweisen ein „Situationsbewusstsein“ zu verleihen.

• Richtlinien: Eine Reihe benutzerkonfigurierter Richtlinienmodule, die den erforderlichen Compliance-Bericht definieren. Richtlinien können die Mindestsicherheitsstandards oder die erforderlichen Konformitätsniveaus für verschiedene Arten von Produkten oder Systemen festlegen, die in Ihrer Build-Pipeline oder Ihrem Entwicklungsprozess enthalten sind. Am wichtigsten ist, dass die daraus resultierenden Richtlinienbewertungen Compliance-Berichte erstellen Bescheinigungen sowie. Dies ermöglicht uns nicht nur die Verwaltung der Compliance-Berichte – z. B. die Offenlegung Ihres Compliance-Status gegenüber Stakeholdern –, sondern auch die Nutzung des Compliance-Berichts für komplexere Richtlinien, die möglicherweise einen größeren Umfang an Compliance-Vorschriften für eine Organisation umfassen. Richtlinien können gruppiert werden Politikmodule. Hierbei handelt es sich um Plugins, die Gruppen von Richtlinienregeln implementieren, die einige gemeinsame Merkmale aufweisen (ähnlich wie Softwaremodule). Diese Plugins werden von Richtlinienanbietern bereitgestellt (mehr dazu später).
  Die Auswertung eines Richtlinienmoduls liefert Ergebnisse, die Bewertungen, Compliance-Details und Urteile in Bezug auf die betreffende Sicherheitsverordnung umfassen. Darüber hinaus umfassen die Ergebnisse die Verlaufsspur der Beweise, die zur Rückverfolgung des auf Konformität bewerteten Beweismoduls erforderlich sind.
• Shops: Dienste, die Hosting-, Upload-/Download- und Abfragefunktionen für Beweise bereitstellen (mehr dazu später). Sie können über Bildregister (OCI als Speicher), dedizierte Dienste (z. B. Scribe Service) oder einfach über das lokale Dateisystem genutzt werden.
• Versicherungsanbieter: Hierbei handelt es sich um Einheiten (Unternehmen, Organisationen), die für die Unterzeichnung und Bereitstellung von Richtlinienmodulen verantwortlich sind. Durch die Bereitstellung von Policen als eine Art Bescheinigung vermitteln Anbieter Vertrauen und Transparenz in die Police selbst. Beispielsweise kann eine OPA-Bundle-Bescheinigung den Regulierungsbehörden die Möglichkeit geben, offizielle OPA-Bundles zur Umsetzung von Richtlinienmodulen zu veröffentlichen und zu unterzeichnen.

Durch die Verwendung dieser Bausteine ​​ermöglicht unser Modell Unternehmen, die Sicherheit und Konformität ihrer Build-Pipelines und ihres Entwicklungslebenszyklus relativ einfach zu überprüfen.

Wie funktioniert es? 

Der Ausgangspunkt dieses Workflows ist ein Entwickler oder ein System, das Beweise für ein Softwareprodukt oder eine Softwarekomponente generiert. Der Beweisinhalt sowie Kontextinformationen, Themen und Signaturen werden gesammelt und in einen Beweisspeicher hochgeladen.

Auf der anderen Seite werden Compliance-Berichte durch die Bewertung von Richtlinien erstellt, die an die Bedürfnisse und Anforderungen der Organisation angepasst sind.

Mithilfe von Kontextinformationen können Richtlinienbewertungen von Ihrer Lieferkette erstellte Beweise abfragen und sicherstellen, dass sie alle Informationen enthalten, die möglicherweise von den Vorschriften verlangt werden.

Ein zusätzlicher Vorteil besteht darin, dass Richtlinien und Compliance-Berichte selbst als Beweismittel zugänglich sind, was für Transparenz und Vertrauen sowie eine Rückverfolgung aller beteiligten Beweise sorgt. Dies ermöglicht es Unternehmen, Compliance-Berichte zu verwalten, diese aber auch als vertrauenswürdige Bescheinigungen zu verwenden, um den Softwarekonsumenten Vertrauen zu vermitteln.

Durch die Nutzung dieses Flusses können Organisationen und Stakeholder Risiken reduzieren, Transparenz schaffen und die Einhaltung von Vorschriften innerhalb ihrer Lieferkette sicherstellen, wodurch die Auswirkungen von Chaos verringert und die Gesamtsicherheit und das Vertrauen in ihre Produkte verbessert werden.

Politikbewertung
Die Auswertung Die Erstellung einer Richtlinie erfolgt durch die Überprüfung einer Reihe von Richtlinienmodulen, die jeweils spezifische Vorschriften und Compliance-Anforderungen einhalten.

Bei einer Richtlinienevaluierung werden jedem Modul zwei einfache Fragen gestellt:

• Welche Nachweise sind zur Erfüllung des Moduls erforderlich?

• Welche Kriterien gelten für den Nachweis der Compliance?

Zum Beispiel im Rahmen der SLSA-Framework (Supply Chain Levels for Software Artifacts).In Richtlinienmodulen kann festgelegt werden, dass sowohl ein signierter SLSA-Herkunftsnachweis als auch ein Sicherheitsstatus-Scan für die Build-Pipeline erforderlich sind, um die Sicherheitsanforderungen zu erfüllen. Die von diesen Modulen bereitgestellten Nachweise würden dann überprüft, um sicherzustellen, dass sie alle SLSA-Anforderungen erfüllen.

1. Welche Nachweise sind erforderlich, um die SLSA-Anforderungen zu erfüllen?
   • Eine SLSA-Provenienzbescheinigung (unterschriebener Nachweis) des Build-Artefakts.
   • Sicherheitsstatusscan der CI-Pipeline, die das Artefakt erzeugt.
2. Welche Kriterien gelten für den Nachweis der Einhaltung der SLSA-Anforderungen?
   • Beide Nachweise müssen Informationen enthalten, die alle SLSA-Anforderungen erfüllen.
     In diesem Beispiel muss die SLSA-Herkunftsbescheinigung Ihren Image-Erstellungsprozess vollständig beschreiben, während die Sicherheitsstatusbescheinigung überprüfen muss, ob der SCM, der die Image-Quelle gespeichert hat, Zweigschutzregeln verwendet.

Ein weiteres Beispiel für ein Richtlinienmodul ist das Überprüfen Sie das Artefaktmodul, was angibt, dass einige Artefakte von einer vertrauenswürdigen Quelle signiert werden müssen. Verwendung von Attesten (überprüfbare, unterschriebene Beweise) PKI-Signatur (Public Key Infrastructure), um den Anforderungen einer bestimmten Person/Entität zu entsprechen, die die Artefakte signieren muss, und um den Kontext zu bestätigen, aus dem die Artefakte stammen.
Die Überprüfen Sie das Artefaktmodul beantwortet folgende Fragen:

1. Welche Nachweise sind erforderlich, um die Einhaltung der Sicherheitsanforderungen nachzuweisen?

• Nachweis, der ein Artefakt beschreibt, das eine PKI-Signatur (Bescheinigung) enthält.

2. Wie können diese Nachweise überprüft werden, um die Einhaltung sicherzustellen?

• Die PKI-Signatur des Nachweises ist gültig.
• Die Identität des PKI-Zertifikats entspricht den Benutzeranforderungen.
• Gegenstand des Nachweises entspricht den Nutzeranforderungen.
• Format und Herkunft entsprechen den Benutzeranforderungen.

Von der Theorie zur Praxis 

Schauen wir uns die Implementierung dieses Modells an, das derzeit vom Valint-Tool unterstützt wird.

Schauen wir uns ein einfaches Beispiel einer Richtlinie an, die angibt, wie die Signaturen und die Herkunft eines Bildes überprüft werden.

Insbesondere müssen wir überprüfen, ob die Beweise die folgenden Kriterien erfüllen:

• Der Beweistyp ist die CycloneDX SBOM-Bescheinigung, die ein Bild beschreibt.
• Das Artefakt ist signiert von mycompany.com.
• Das Bild stammt aus einem Circle-CI-Workflow, der durch ausgelöst wurde my_image_src Repo.

Vorlagenrichtlinie
Im vorherigen Beispiel war die Richtlinie statisch und wurde nur auf ein bestimmtes Bild mit dem Namen überprüft meinefirma/mein_bild. Allerdings ist es oft vorzuziehen, über Richtlinien zu verfügen, die Vorlagen-/Variablenfunktionen unterstützen. Dadurch können Sie Anforderungen definieren, die auf mehrere ähnliche Prozesse oder Artefakte in Ihrer CI/CD-Build-Pipeline angewendet werden können.

Um die Richtlinie als Vorlage zu verwenden, können Sie eine Variable verwenden, anstatt die Richtlinie statisch an ein Produkt zu binden. Im obigen Beispiel können Sie die ändern Artefaktname Wert auf `$MY_IMAGEStattdessen können Gutachter eine Richtlinie für eine Vielzahl von Bildern konfigurieren, für die dieselben Compliance-Vorschriften gelten.

Ich freue mich auf

At SchreiberUnser oberstes Ziel ist es, Risiken in der Lieferkette durch ein überprüfbares, evidenzbasiertes Compliance-Modell zu mindern. Einer der ersten Orte, an denen Sie dieses Modell ausprobieren können, ist Ihre CI/CD-Build-Pipeline. Wir glauben, dass dieser evidenzbasierte Ansatz der Schlüssel zur Gewährleistung von Transparenz und Rechenschaftspflicht in der Lieferkette ist und allen Beteiligten Vorteile bringt. Unser Modell fasst viele der aufkommenden Ideen in der Software-Supply-Chain-Community zusammen und definiert die Beziehung zwischen vielen von ihnen. Wir engagieren uns für Innovationen und die Verbesserung der Transparenz der Software-Lieferkette. Wenn dieses Modell Ihr Interesse geweckt hat, empfehle ich Ihnen, sich unser Modell anzusehen Valint CLI-Dokumentation Hier erläutern wir die Fähigkeiten und Einsatzmöglichkeiten des Tools. Probieren Sie es gerne aus.

Zusammenhängende Artikel

Eine geheime Begegnung in der Software-Lieferkette

Eines der Risiken der Software-Lieferkette ist die Offenlegung von Geheimnissen. Überall in der Software-Lieferkette lauern Geheimnisse. Entwickler und die CI\CD-Pipelines müssen Geheimnisse verwenden, um auf den SCM, die Pipeline, die Artefaktregister, die Cloud-Umgebungen und externe Dienste zuzugreifen. Und wenn es überall Geheimnisse gibt, ist es eine Frage der Zeit […]

Best Practices für CI/CD-Sicherheit

Die Einzelheiten dessen, was in CI/CD-Pipelines passiert, sind äußerst undurchsichtig. Wie können Sie sicher sein, dass alles genau so abläuft, wie es beschrieben wird, obwohl Sie die YAML-Konfigurationsdatei geschrieben haben, bei der es sich um die Pipeline-Anweisungsliste handelt? Schlimmer noch: Die meisten Pipelines sind völlig transient, sodass selbst im Falle einer Fehlfunktion […]

ML-Was? Das ML-Bom-Konzept und seine Verwendung verstehen

Die Branche hat die Idee einer SBOM noch nicht vollständig verstanden, und wir hören bereits einen neuen Begriff – ML-BOM – Machine Learning Bill of Material. Bevor Panik ausbricht, wollen wir verstehen, warum eine solche Stückliste erstellt werden sollte, welche Herausforderungen bei der Generierung einer ML-Stückliste bestehen und wie eine solche ML-Stückliste aussehen kann. […]