Ein Blick auf Googles neues Projekt zur Erhöhung der Sicherheit von Open-Source- (und anderem) Software-Code

Cyber Security News

Das Google-Logo ist vor der Enthüllung des Google Nexus One Android-Smartphones in der Google-Zentrale am 5. Januar 2010 in Mountain View, Kalifornien, zu sehen. (Robert Galbraith-Pool/Getty Images). Google stellt ein neues Framework vor, um die Sicherheit des Entwicklungsprozesses für den Open-Source-Code, der moderne Softwareanwendungen antreibt, zu erhöhen.

Der Tech-Gigant Google wirft seinen Hut in den Ring, wenn es darum geht, das Chaos der Softwaresicherheit zu bereinigen. Er stellte heute ein neues Framework vor, das den Kodierungs- und Entwicklungsprozess, der moderner Software zugrunde liegt, sichern und das Potenzial für schädliche Angriffe in der Lieferkette verringern soll.

Die Supply Chain Levels for Software Artifacts (SLSA, oder “Salsa”, wenn Sie nach einer griffigen Abkürzung suchen) sind nicht auf die Abwehr eines bestimmten Angriffs an einem bestimmten Punkt im Softwareentwicklungsprozess ausgerichtet, sondern sind als Roadmap für Entwickler konzipiert, um ihre Sicherheitsprozesse so zu gestalten, dass sie gängige Angriffe an jedem Glied der Entwicklungs- und Produktionskette erkennen und abwehren können.

Ähnlich wie Frameworks wie das Cybersecurity Maturity Model Certification, das vom Verteidigungsministerium für seine Auftragnehmer implementiert wird, bildet das Google-Framework eine Vielzahl von Prozessen und Praktiken in vier verschiedenen Stufen zunehmender Software-Sicherheitsanforderungen ab. Außerdem werden acht Punkte im Entwicklungs- und Produktionsworkflow markiert, die anfällig für verschiedene Formen der Korruption sind.

“Es geht darum, den Leuten eine Rampe zu verschaffen, sie irgendwo anzufangen und zu erkennen, dass man nicht einfach von Anfang an auf die höchsten Stufen aufsteigen kann – und das muss auch nicht jeder, je nachdem, was man macht”, sagte Dan Lorenc, ein Software-Ingenieur bei Google, in einem Interview.

Das Framework richtet sich in erster Linie an Open-Source-Entwickler, denn Open-Source-Code “ist das [common] Bindeglied zwischen allen Beteiligten in der Lieferkette ist”, sagte er. Aber es kann auch auf Aspekte des kommerziellen Softwareentwicklungsprozesses angewendet werden.

Es berücksichtigt Szenarien wie das Einreichen von schlechtem oder bösartigem Code in Quellcode-Repositories, die Kompromittierung eines Build- oder Update-Servers, die Modifizierung von Code auf dem Weg von der Quellcodekontrolle zur Build-Plattform und Angriffe, die den Prozess der kontinuierlichen Integration und Entwicklung umgehen. Jede Schwachstelle wird durch einen Angriff aus der realen Welt und eine Erklärung, wie das Framework verwendet werden könnte, um die Kompromittierung zu erkennen oder zu stoppen, bevor sie nachgelagerte Kunden infiziert, untermauert – zum Beispiel der Hack des Orion-Build-Servers von SolarWinds, um bösartigen Code in ein Software-Update einzuschleusen.

Höhere Stufen von SLSA umfassen Sicherheitskontrollen, die entweder die Durchführung eines ähnlichen Angriffs erschweren oder die Fähigkeit eines Bedrohungsakteurs einschränken, sich in einer kompromittierten Umgebung über längere Zeiträume hinweg einzunisten. Ebenso gibt es mehrere Kontrollen, die dabei helfen, die Herkunft von Softwarecode festzustellen und die Umgehung des CI/CD-Prozesses zu verhindern, wodurch Angreifer in der Lage waren, CodeCov zu überwinden, um in den Besitz von Kundentestcode und anderen Daten zu gelangen.

In einem Blog-Post sagten die Sicherheitsverantwortlichen von Google, dass die Idee vorerst als allgemeine Anleitung dienen wird, aber sie stellen sich letztendlich einen formelleren Prozess vor.

“In seinem aktuellen Zustand ist SLSA eine Reihe von schrittweise annehmbaren Sicherheitsrichtlinien, die durch einen Branchenkonsens etabliert werden”, schrieben Kim Lewandowski, ein Mitglied des Open-Source-Sicherheitsteams von Google, und Mark Lodato, der an der Sicherung des internen Softwareprozesses von Google arbeitet. “In seiner endgültigen Form, [it] wird sich von einer Liste von Best Practices durch ihre Durchsetzbarkeit unterscheiden: Sie wird die automatische Erstellung von auditierbaren Metadaten unterstützen, die in Policy Engines eingespeist werden können, um einem bestimmten Paket oder einer Build-Plattform eine ‘SLSA-Zertifizierung’ zu geben.”

Googles schiere Größe und Reichweite über verschiedene Software- und Hardwareprodukte hinweg geben dem Unternehmen sowohl eine Handhabe im Spiel als auch die potenzielle Reichweite, um eine große Anzahl von Unternehmen in die Compliance zu bringen. Es könnte auch ein mächtiges Werkzeug für ein kommerzielles Unternehmen sein, das es gegenüber potenziellen Konkurrenten oder Rivalen einsetzen kann.

Lorenc sagte gegenüber SC Media, dass man zwar noch dabei sei, zu bestimmen, wie ein solches Zertifizierungsprogramm strukturiert oder implementiert werden würde, dass aber wahrscheinlich eine “herstellerneutrale” dritte Partei – nicht Google selbst – mit der Überwachung des Zertifizierungsprozesses beauftragt werden würde.

“Ich denke nicht, dass wir zu viel zu tun haben. [many] feste Details dazu im Kopf haben”, sagte er. “Ich glaube nicht, dass es etwas sein würde [where] ein einzelnes Unternehmen beaufsichtigen oder verwalten würde; das macht wahrscheinlich nicht wirklich Sinn.”

Im Moment wird das Projekt für offene Kommentare ausgeschrieben (siehe hier für die GitHub-Seite von SLSA) und Google bittet aktiv um Vorschläge von außen, wie das Framework weiter verbessert und standardisiert werden kann, damit es eine breite Anwendung findet.

Wir denken, dass es in einem guten Zustand ist, in dem die Leute anfangen können, es zu benutzen und zu versuchen, einen Sinn darin zu sehen, und dann wollen wir sehen, wie es funktioniert. Wir wollen Feedback, um es zu härten und sicherzustellen, dass wir alles richtig gemacht haben”, sagte Lorenc.

Einige Teile dieses Artikels stammen aus:
www.scmagazine.com