Google schickt Framework gegen Supply-Chain-Angriffe ins Rennen

Inhaltsverzeichnis

Als Abwehrmaßnahme gegen Supply-Chain-Angriffe hat Google ein Framework mit dem Titel Supply Chain Levels for Software Artifacts (SLSA) vorgeschlagen. Es soll die Integrität von Softwareartefakten während des kompletten Entwicklungs- und Bereitstellungsprozesses sicherstellen und berücksichtigt acht Stufen vom Einreichen des Codes bis zum Verwenden der Pakete. Der Vorschlag bringt vier Sicherheitsstufen ins Gespräch, die wachsende Voraussetzungen abdecken.

Als Grundlage für den Vorstoß dienen laut Google die internen Richtlinien und Prozesse, die das Unternehmen unter dem Namen Binary Authorization for Borg wohl seit gut acht Jahren anwendet. SLSA soll vor allem Open-Source-Projekte gegen diverse Angriffe auf die Supply Chain absichern.

Acht Angriffspunkte im Visier

Supply-Chain-Attacken zielen auf Schwachstellen im Prozess der Softwareentwicklung und dem Verwenden von Paketen. SLSA identifiziert insgesamt acht Angriffspunkte. So lässt sich gleich zum Beginn der Kette Schadcode einfügen, wie das Einbringen von Schadcode in den Linux-Kernel durch Informatikstudenten der University of Minnesota vor Kurzem gezeigt hat. Das zweite Glied ist die Source-Control-Plattform. Hier waren die PHP-Verantwortlichen im März Opfer eines Angriffs auf den internen Git-Server.

Der dritte Angriffspunkt ist der Übergang vom Repository zum Build-System, worauf als vierter die Build-Plattform folgt. Hier war Solarwinds 2020 ein prominentes Opfer. Als Nächstes stehen die Dependencies im Fokus. Beispielsweise kann ein zunächst nützliches und harmloses Paket in vielen Projekten zum Einsatz kommen. Schließlich fügt ein Update Schadcode ein, der zahlreiche Softwareprojekte betrifft. Der sechste Schwachpunkt ist der Übergang vom Build-System auf das Repository wie beim Angriff auf Codecov.

Hiese devSec: Die Konferenz zu sicherer Softwareentwicklung

Dieses Jahr erweitern heise Developer, heise Security und dpunkt.verlag die Konferenz für sichere Softwareentwicklung heise devSec um drei Thementage. Das Absichern der Pipeline und damit auch der Schutz der Supply Chain steht am DevSecOps-Tag am 29. Juni im Fokus. Auch der Web-Application-Security-Thementag am 1. Juli hat das Thema im Blick mit dem Vortrag "NPM: Bitte haben Sie noch einen Augenblick Geduld, der nächste Supply-Chain-Angriff ist gleich für Sie da."

Als nächster Punkt sind Angriffe auf die Package-Repositories möglich, und abschließend steht das Bereitstellen von Paketen mit Schadcode, die unter anderem über Typosquatting oder Brandjacking ein nützliches Package vortäuschen. Letzteres verwendet Firmennamen wie Twilio, um eine legitime Quelle vorzutäuschen. Beim Typosquatting geben die Entwickler von Schadcode ihren Paketen Namen, die den Bezeichnungen beliebter Pakete ähneln. Dabei nutzen sie zum einen Tippfehler und verwenden zum anderen Trennzeichen wie Unter- und Bindestrichen. Aus my-packet wird my-paket, mypacket oder my_packet. Irgendwer wird sich schon vertippen, so die durchaus berechtigte Hoffnung der Angreifer.

Mehr als ein Pflichtenheft

Supply Chain Levels for Software Artifacts definiert Security-Richtlinien für vier Stufen von SLSA 1 bis SLSA 4. Die niedrigeren Levels sollen dabei als Zwischenschritt für die höchste Stufe dienen. Eine Tabelle zeigt die jeweiligen Anforderungen. Als Minimum steht ein vollständig geskripteter Build-Prozess und das Bereitstellen von Informationen über den Ursprung (Provenance) des Codes.

Für SLSA 4 stehen neunzehn Voraussetzungen im Pflichtenheft, die in vier Kategorien unterteilt sind. Das Framework soll allerdings letztlich mehr bieten als eine manuell abzuarbeitende Liste mit Voraussetzungen beziehungsweise Best Practices. Es soll das Generieren von Metadaten ermöglichen, die sich in Policy-Engines zum automatischen Prüfen der jeweiligen Prozesse verwenden lassen.

Start auf Ebene eins

Weitere Details lassen sich dem Google-Security-Blog entnehmen. Der Internetriese hat neben dem nun veröffentlichten Vorstoß ein GitHub-Repository angelegt. Dort finden sich die Vorschläge zu den SLSA-Levels sowie die Voraussetzungen für die Kategorien Source, Build und Provenance. Außerdem enthält das Repository ein Proof-of-Concept für einen SLSA1-Provenance-Generator.

(rme)