Das SLSA Cybersecurity Framework verstehen

Wie SLSA zur Abwehr von Angriffen auf die Software-Lieferkette beiträgt

Das SLSA-Sicherheitsframework ist mehr als ein Regelwerk, es ist ein Standardframework, das potenziell die Integrität der Komponenten eines Softwareartefakts stärken kann. Diese End-to-End-Richtlinie stellt eine Reihe von Abwehrmaßnahmen dar, die Manipulationen oder jede Art von unbefugter Änderung der Softwarepakete, aus denen ein Softwareprodukt besteht, schrittweise verhindern. Die Einführung des SLSA-Frameworks kann dazu beitragen, Ihre Software vor verbreiteten Angriffen zu schützen Angriffe auf die Lieferkette wie die folgenden:

Schädliche Commit-Repository-Angriffe von PHP

Im März 2021 gab Nikita Popov bekannt, dass böswillige Akteure versuchten, den Quellcode von PHP anzugreifen, indem sie eine Hintertür erstellten, die ihnen unbefugten Zugriff auf die Codeplattform ermöglichen würde. Im Erfolgsfall wäre der Angriff verheerend gewesen, da PHP etwa 80 % der Websites im Internet antreibt. Glücklicherweise wurde der Angriff rechtzeitig erkannt – aber dieser Vorfall zeigt immer noch, wie SLSA-Kontrollen dazu beitragen können, Angriffe wie diesen in Zukunft zu verhindern. Das Befolgen von SLSA-Protokollen wie einer Zwei-Personen-Überprüfung und einer Zwei-Faktor-Authentifizierung hätte die Quellcode-Plattform geschützt und sie zu einem viel schwierigeren Ziel für Angreifer gemacht.

Apples bösartiger Compiler-Verstoß

Im Jahr 2015 luden Softwareentwickler, die Apps für Apple-Produkte entwickelten, eine Version von Xcode (einem Code-Schreibtool für Apple-Geräte) von einer nicht verifizierten Hosting-Plattform herunter. Die als XcodeGhost bekannte Xcode-Version war mit Schadcode infiziert, der heimlich auf damit erstellte Apps übertragen wurde. Es wurde eine Hintertür zu mehreren Apps erstellt, die dem Codeüberprüfungsprozess von Apple und den im App Store angebotenen Apps entgangen sind. Das SLSA-Framework enthält buildbezogene Sicherheitsprotokolle, die einen solchen Angriff verhindert oder erschwert hätten. Eine dieser Maßnahmen ist die Hermetik-Build-Anforderung, die Entwickler dazu gezwungen hätte, alle ihre Quellen einschließlich des von ihnen verwendeten Build-Tools zu deklarieren.

Schädliche Artefakte hochgeladen

Am 1. April 2021 deckte das Codecov-Team Angriffe auf, die seine Bash-Uploader betrafen, darunter Codecov GitHub Action, The Codecov CircleCI Orb und Codecov Bitrise Step. Der Angreifer verschaffte sich unbefugten Zugriff, indem er einen HMAC-Schlüssel extrahierte, der Zugriff auf das Google Cloud Storage-Dienstkonto einer Zwischenschicht eines der öffentlichen selbstgehosteten Docker-Images von Codecov ermöglichte. Mit diesem Schlüssel konnten sie den Bash Uploader so modifizieren, dass Schadcodes direkt an Endbenutzer hochgeladen wurden. Das SLSA-Framework hätte diese Aktion abgefangen, indem es angezeigt hätte, wenn Artefakte auf eine Weise erstellt wurden, die von der erwarteten Form in ihrem Quell-Repository abweicht.

Schlechte Abhängigkeit des Ereignisstroms

Im Jahr 2018 veröffentlichten Hacker ein bösartiges Paket „flatmap-stream“ für npm, das später als Abhängigkeit zum weit verbreiteten Event-Stream-Paket der Plattform hinzugefügt wurde. Nachdem sie die Abhängigkeit hinzugefügt hatten, aktualisierten die Angreifer sie mit bösartigem Verhalten. Da das Update nicht mit dem an GitHub übermittelten Code übereinstimmte, hätte das SLSA-Framework den Angriff abgefangen und den Vektor verhindert. Die Verfolgung der Herkunft des Schadcodes hätte ergeben, dass dieser nicht von GitHub oder dem richtigen Builder stammte. So oder so hätte der Angriff verhindert werden können.

Die vier Sicherheitsstufen des SLSA Cybersecurity Framework

Das SLSA-Framework ist ein inkrementelles und umsetzbares Protokoll. Es besteht aus vier Ebenen, wobei Ebene 4 den idealen Endzustand eines gesicherten Systems darstellt. Artefakte auf höchstem Niveau erfüllen alle Anforderungen, um den Verbrauchern die Gewissheit zu geben, dass sie in keiner Weise manipuliert wurden und dass alle ihre Bestandteile bis zu ihren Quellen zurückverfolgt werden können. Artefakte auf niedrigeren Ebenen sind solche, die abhängig von ihrem Rang auch inkrementelle Meilensteine ​​mit spezifischen Integritätsgarantien erreicht haben.

Ebene 1 – den Grundstein legen

Sie können Level 1 des SLSA-Frameworks als eine Art Grundlage für das gesamte Framework zur Erstellung sicherer Software betrachten. In dieser Phase müssen Entwickler oder Organisationen, die SLSA einführen, zwei Dinge tun. Zunächst müssen sie ihren Build-Prozess vollständig automatisieren. Dies kann auf unterschiedliche Weise erfolgen, die herkömmliche Methode zur Automatisierung von Builds ist jedoch die Verwendung eines Makefiles. GitHub-Aktionen können auch verwendet werden, um die gleichen Ergebnisse zu erzielen.

Der zweite Teil zum Erreichen von SLSA Level 1 besteht in der Erstellung einer vollständigen Herkunftsdokumentation. Hierbei handelt es sich um Metadaten, die zeigen, wie ein Softwareartefakt erstellt wurde. Es sollte den gesamten Build-Prozess, alle Abhängigkeiten und die bei der Erstellung verwendeten Quellen der obersten Ebene detailliert beschreiben.

Durch die Skripterstellung des Erstellungsprozesses und die Darstellung der Herkunft eines Softwareartefakts auf diese Weise können Verbraucher leichter fundierte Entscheidungen über die Verwendung eines Softwareprodukts treffen. Obwohl die SLSA 1-Verifizierung nicht bedeutet, dass die Software vollständig vor Manipulationen geschützt ist, erleichtert sie die Identifizierung der Komponenten der Software. Dies ist der erste Schritt beim Management von Schwachstellen.

Stufe 2 – Stellen Sie sicher, dass Ihr Build-Prozess manipulationssicher ist

Auf Stufe 2 des SLSA-Frameworks beginnen Sie mit der Umsetzung von Maßnahmen, um sicherzustellen, dass Ihr Build-Prozess so manipulationssicher wie möglich ist. Das Erreichen von Level 2 des SLSA-Frameworks gibt dem Verbraucher auch mehr Vertrauen in die Herkunft der Software.

Auch dies erfolgt in zwei Schritten: Im ersten Schritt wird die Versionskontrolle verwendet und im zweiten Schritt wird ein gehosteter Build-Dienst zur Authentifizierung der Herkunft verwendet. Im ersten Schritt wird GitHub, GitLab oder ein anderer ähnlicher Dienst verwendet, um den Code zu speichern und alle daran vorgenommenen Änderungen aufzuzeichnen. Durch die Verfolgung aller Versionsänderungen ist es einfacher, alle Änderungen zu verstehen, die während des Erstellungsprozesses am Artefakt vorgenommen wurden.

Obwohl Level 2 wie Level 1 eine Herkunftsdokumentation erfordert, besteht der Unterschied hier darin, dass das Softwareartefakt von einem gehosteten Build-Service authentifiziert werden muss. Der gehostete Dienst fungiert als vertrauenswürdiger Dritter, der bestätigen kann, dass der im ursprünglichen Herkunftsdokument beschriebene Erstellungsprozess korrekt ist. GitHub Actions ist eine Art Hosting-Dienst, der eine authentifizierte Herkunft bereitstellen kann.

 Stufe 3 – Sicherheitskontrollen von SLSA

Auf Stufe 3 beginnen Sie mit der Implementierung der spezifischen Sicherheitskontrolle, wie im SLSA-Framework hervorgehoben. Um dieses Niveau zu erreichen, müssen die Quell- und Build-Plattformen für Ihre Softwareartefakte bestimmte Standards erfüllen, die garantieren, dass die Quelle überprüfbar ist und der Herkunft des Codes vertraut werden kann. SLSA Level 3 bietet eine viel stärkere Garantie dafür, dass das Artefakt gut vor Manipulation und bestimmten Bedrohungsklassen geschützt ist.

Zu den spezifischen Anforderungen von Level 3 gehören:

•     Verifizierter Verlauf und Aufbewahrung des Quellcodes– Eine verifizierte Historie des Quellcodes stellt sicher, dass jede am Software-Quellcode vorgenommene Änderung von einer authentifizierten Identität des Autors, Prüfers oder Uploaders begleitet wird, der die Änderung vorgenommen hat, mit spezifischen Zeitstempeln der Änderung. Auch diese Änderungshistorie muss mindestens 18 Monate aufbewahrt werden.
•   Isolierte Gebäude in kurzlebigen Umgebungen– Um diese Anforderung zu erfüllen, müssen die Software-Builds in kurzlebigen Umgebungen implementiert werden, in denen sie völlig unabhängig von anderen Build-Instanzen sind. Um dies zu erreichen, können Sie einen Dienst wie GitHub Actions verwenden, der eine virtuelle Build-Maschine verwendet, um Ihren Build bei Bedarf zu erstellen.
•     Wird als Code erstellt– Diese Kriterien erfordern, dass Sie Ihre Build-Dateien wie Code behandeln. Dies bedeutet, dass sie in einem Versionskontrollsystem gespeichert werden müssen, das es ermöglicht, Build-Prozesse bei Bedarf neu zu erstellen.
•     Nicht fälschbare Herkunft– Der Zweck dieser Anforderung besteht darin, zu verhindern, dass Benutzer die vom Build-Service generierte Herkunftsdokumentation manipulieren.

Stufe 4 – Verbrauchervertrauen

Level 4 des SLSA-Frameworks soll sicherstellen, dass die Software in keiner Weise manipuliert wurde. Nur Softwareartefakte, die die folgenden Anforderungen erfüllt haben, können Level 4 des Frameworks erreichen:

Überprüfung aller Änderungen durch zwei Personen

Dieses Kriterium erfordert, dass Organisationen zwei qualifizierte Prüfer beauftragen, alle vorgeschlagenen Änderungen am Softwarecode und an den Komponenten gründlich zu prüfen. Dieser Überprüfungsprozess durch zwei Personen stellt sicher, dass nur vertrauenswürdige und authentifizierte Entwickler Änderungen an Softwareartefakten vornehmen können.

Ein hermetischer und reproduzierbarer Bauprozess

Ein Build-Prozess wird als hermetisch bezeichnet, wenn alle Eingaben vorab und außerhalb des Build-Prozesses angegeben werden. Diese Regel gilt für den Quellcode sowie alle im Build verwendeten Compiler, Bibliotheken und Tools. Dies trägt dazu bei, die Integrität aller Drittimporte zu gewährleisten. Die Kriterien der reproduzierbaren Bauweise sind keine zwingende Voraussetzung, werden aber auch empfohlen. Die Kriterien erfordern, dass der Build-Prozess die gleiche Ausgabe erzeugt, unabhängig davon, wo oder wann er ausgeführt wird.

Technische Anforderungen zur Erfüllung der SLSA-Stufen

Das SLSA-Framework stellt spezifische technische Anforderungen für die verschiedenen Ebenen. Diese Anforderungen werden in fünf Hauptkategorien eingeteilt: Quellanforderungen, Anforderungen an den Erstellungsprozess, allgemeine Anforderungen, Anforderungen an den Herkunftsinhalt und Anforderungen an die Herkunftsgenerierung. Jede dieser Anforderungskategorien wird unten hervorgehoben.

Quellenanforderungen

Damit sind Anforderungen gemeint, die die Integrität Ihres Quellcodes sicherstellen sollen. Das Befolgen dieser Protokollsätze verhindert Manipulationen und böswillige Änderungen an Ihrem Code. Es stellt außerdem sicher, dass schändliche Handlungen nicht unbemerkt bleiben. Die Quellenanforderungen sind in der folgenden Tabelle aufgeführt.

Build-Anforderungen

Das SLSA-Framework hebt Build-Anforderungen hervor, die die Sicherheit der Build-Plattform verbessern und die Integrität des Build-Prozesses aufrechterhalten sollen.

Anforderungen an die Provenienzgenerierung

Mit diesen Anforderungen soll die Quelle aller Komponenten eines Software-Assets überprüft werden. Die Anforderungen an die Herkunftsgenerierung sind in der folgenden Tabelle hervorgehoben.

Anforderungen an den Provenienzinhalt

Die Anforderungen an den Herkunftsinhalt überprüfen die Identität und Quelle aller Artefakte, Abhängigkeiten und Build-Einschränkungen, die im Build-Prozess verwendet wurden. Sie sind in der folgenden Tabelle hervorgehoben.

Allgemeine Anforderungen

Die allgemeinen Anforderungen gelten für Softwareartefakte auf SLSA Level 4. Von jedem vertrauenswürdigen Artefakt wird erwartet, dass es diese Anforderungen erfüllt. Sie umfassen grundlegende Sicherheitsanforderungen und Protokolle, die alle physischen und Fernzugriffe detailliert beschreiben. Die allgemeinen Anforderungen sehen außerdem eine kleine Anzahl von Plattformadministratoren vor, die die Bestimmungen in der SLSA-Dokumentation außer Kraft setzen können.