Bedrohungen der Softwarelieferkette

Angriffsvektoren für Softwarelieferketten sind die verschiedenen Möglichkeiten, auf die jemand Ihre Software absichtlich oder versehentlich kompromittieren kann.

Zu den Risiken anfälliger Software gehören die Offenlegung von Anmeldedaten oder vertraulichen Daten, die Beschädigung von Daten, die Installation von Malware und Anwendungsausfälle. Diese Probleme führen dazu, dass Zeit, Geld und Kundenvertrauen verloren gehen.

Die Einstiegspunkte für Bedrohungen erstrecken sich über den gesamten Softwarelebenszyklus und können von innerhalb oder außerhalb Ihrer Organisation stammen.

Ein Diagramm, das Einstiegspunkte für Angriffe auf die Softwarelieferkette zeigt

Die Diagrammlegende enthält zwei Arten von Bedrohungen:

  • Die Buchstaben A bis H kennzeichnen Angriffsvektoren in der Softwarelieferkette, die im Framework Supply Chain Levels for Software Artifacts (SLSA) als Bedrohungen beschrieben werden.
  • Die Zahlen 1 bis 4 geben zusätzliche Angriffsvektoren an, die vom SLSA-Framework nicht direkt beschrieben werden.

Software Delivery Shield, eine vollständig verwaltete Sicherheitslösung für die Softwarelieferkette in Google Cloud, umfasst Best Practices, mit denen Sie beide Arten von Bedrohungen minimieren können.

In den Unterabschnitten dieses Dokuments werden die Bedrohungen im Kontext von Quelle, Builds, Bereitstellung und Abhängigkeiten beschrieben.

Quellenbedrohungen

Diese Bedrohungen wirken sich auf die Integrität Ihres Quellcodes aus.

  • 1: Unsicheren Code schreiben. Ein Mangel an sicheren Programmierpraktiken kann dazu führen, dass beim Schreiben von Code unbeabsichtigt Sicherheitslücken eingeschlossen werden. Unsichere Entwickler-Workstations können auch schädlichen oder unsicheren Code einschleusen. Zu den Risikominderungen gehören:

    • Richtlinien für Entwickler-Workstations festlegen. Cloud Workstations bietet vollständig verwaltete, vorkonfigurierte Workstations, die Sie an Ihre Anforderungen anpassen können.
    • Lokales Scannen von Code. Cloud Code Source Protect (private Vorschau) bietet Sicherheitsfeedback in Echtzeit, einschließlich Sicherheitslücken und Lizenzinformationen für Abhängigkeiten. Entwickler können auch die On-Demand Scanning API verwenden, um Container-Images auf Sicherheitslücken in Betriebssystem- und Sprachpaketen zu scannen.
    • Informationen zu Praktiken, die Code sicherer machen.

  • A: Sie senden ungültigen Code an das Quell-Repository. Dazu gehört nicht nur schädlicher Code, sondern auch Code, der bei einem Angriff unbeabsichtigt Sicherheitslücken wie Cross-Site-Scripting einschließt. Zu den Risikominderungen gehören:

    • Bei Änderungen am Quellcode ist eine manuelle Überprüfung erforderlich.
    • Code-Scan- und Linting-Tools verwenden, die in IDEs und Versionsverwaltungssysteme eingebunden sind

  • B: Manipulation des Versionsverwaltungssystems Wenn Sie den Zugriff auf das Versionsverwaltungssystem und andere Systeme in der Build-Pipeline einschränken und die Multi-Faktor-Authentifizierung verwenden, können Sie dieses Risiko minimieren.

Prüfen Sie bei der Bewertung der Quellintegrität auch unterstützende Skripts und Konfigurationen, mit denen Sie Ihre Software erstellen und bereitstellen. Nehmen Sie sie in Ihr Versionsverwaltungssystem und in Ihre Codeüberprüfungsprozesse auf, um Sicherheitslücken in diesen Dateien zu vermeiden.

Weitere Informationen zum Schützen Ihrer Quelle finden Sie unter Quelle absichern.

Build-Bedrohungen

Diese Bedrohungen gefährden Ihre Software, wenn Sie sie erstellen oder verpacken, oder verleiten Nutzer Ihrer Software dazu, eine schädliche Version zu verwenden.

  • C Build mit einer Quelle, die nicht aus dem vertrauenswürdigen Versionsverwaltungssystem stammt. Zu den Risikominderungen gehören:
    • Verwendung von Build-Diensten wie Cloud Build, die Herkunftsinformationen generieren, damit Sie prüfen können, ob Ihre Builds eine vertrauenswürdige Quelle verwenden.
    • Platzierung Ihrer CI/CD-Infrastruktur in einem Netzwerkperimeter, um die Exfiltration von Daten aus Ihren Builds zu verhindern. Verwenden Sie für Google Cloud-Dienste VPC Service Controls.
    • Vertrauenswürdige Kopien von Open-Source-Abhängigkeiten, die Sie benötigen, in einem privaten Artefaktspeicher wie Artifact Registry speichern und verwenden.
  • D: Manipulation des Build-Systems Zu den Risikominderungen, die dazu beitragen, dieses Risiko zu reduzieren, gehören:
    • Folgen Sie dem Prinzip der geringsten Berechtigung und beschränken Sie den direkten Zugriff auf das Build-System auf Personen, die ihn benötigen. In Google Cloud können Sie entsprechende vordefinierte Rollen gewähren oder benutzerdefinierte Rollen erstellen.
    • Verwenden Sie verwaltete Build-Dienste wie Cloud Build. Cloud Build führt sitzungsspezifische Builds aus. Dazu richtet es für jeden Build eine VM-Umgebung ein und löscht sie nach dem Build.
    • Platzieren Sie Ihre CI/CD-Infrastruktur in einem Netzwerkperimeter, um eine Exfiltration von Daten aus Ihren Builds zu verhindern. Verwenden Sie für Google Cloud-Dienste VPC Service Controls.
  • F: Verpacken und veröffentlichen Sie Software, die außerhalb des offiziellen Prozesses erstellt wurde. Wenn Sie Systeme erstellen, die Build-Herkunft generieren und signieren, können Sie prüfen, ob Ihre Software von einem vertrauenswürdigen Build-System erstellt wurde.
  • G: Manipulation des Repositorys, in dem Sie die Software für interne oder externe Nutzer speichern Zu den Risikominderungen, die dazu beitragen, dieses Risiko zu reduzieren, gehören:
    • Vertrauenswürdige Kopien von Open-Source-Abhängigkeiten, die Sie benötigen, in einem privaten Artefaktspeicher wie Artifact Registry speichern und verwenden.
    • Build- und Quellherkunft wird überprüft.
    • Beschränken von Uploadberechtigungen auf dedizierte Konten, die nicht menschlichen Ursprungs sind, und Repository-Administratoren. In Google Cloud agieren Dienstkonten im Namen von Diensten und Anwendungen.

Bedrohungen bei Bereitstellung und Laufzeit

  • H: Wenn Sie Abhängigkeiten auflösen, indem Sie einen Versionsbereich oder ein Tag angeben, das nicht dauerhaft an eine bestimmte Build-Version angehängt ist, können verschiedene Probleme auftreten:

    • Builds sind nicht reproduzierbar, da sich Abhängigkeiten, die ein Build beim ersten Mal verwendet, von Abhängigkeiten unterscheiden, die der Build bei zukünftigen Ausführungen desselben Builds verwendet.
    • Eine Abhängigkeit kann zu einer manipulierten Version oder einer Version mit Änderungen aufgelöst werden, durch die Ihre Software beeinträchtigt wird. Schädliche Akteure können diese Unsicherheit ausnutzen und dazu führen, dass Ihr Build die Version eines Pakets anstelle der Version auswählt, die Sie verwenden möchten. Eine Reihe von Best Practices für Abhängigkeiten kann helfen, das Risiko von Verwechslungen bei Abhängigkeiten zu mindern.

  • 2: Bereitstellungsprozess kompromittieren Wenn Sie einen Prozess zur kontinuierlichen Bereitstellung verwenden, kann die Kompromittierung dieses Prozesses unerwünschte Änderungen an der Software zur Folge haben, die Sie Ihren Nutzern zur Verfügung stellen. Sie können das Risiko minimieren, indem Sie den Zugriff auf Ihren Bereitstellungsdienst einschränken und Änderungen in Vorproduktionsumgebungen testen. Cloud Deploy kann Ihnen bei der Verwaltung des Continuous-Delivery-Prozesses und der Hochstufung zwischen Umgebungen helfen.

  • 3: Stellen Sie manipulierte oder nicht konforme Software bereit. Dieses Risiko kann durch das Erzwingen von Bereitstellungsrichtlinien verringert werden. Mit der Binärautorisierung können Sie überprüfen, ob Container-Images Richtlinienkriterien entsprechen, und das Deployment von Container-Images aus nicht vertrauenswürdigen Quellen blockieren.

  • 4: Sicherheitslücken und Fehlkonfiguration in laufender Software.

    • Es werden regelmäßig neue Sicherheitslücken entdeckt. Das bedeutet, dass neue Erkenntnisse das Sicherheitsrisikoniveau Ihrer Anwendungen in der Produktion ändern können.
    • Einige Konfigurationen erhöhen das Risiko nicht autorisierter Zugriffe, z. B. die Ausführung als Root-Nutzer oder die Berechtigungsausweitung bei Ausführung eines Containers.

    Das GKE-Dashboard für den Sicherheitsstatus enthält Informationen zu Sicherheitslücken des Betriebssystems und Konfigurationsprobleme in Ihren ausgeführten Arbeitslasten.

    In Cloud Run können Sie außerdem Sicherheitsinformationen zu Ihren bereitgestellten Überarbeitungen aufrufen, einschließlich bekannter Sicherheitslücken in von Ihnen bereitgestellten Container-Images.

Weitere Informationen zum Schützen Ihrer Quelle finden Sie unter Builds absichern. Weitere Informationen zum Schutz von Bereitstellungen finden Sie unter Bereitstellungen absichern.

Abhängigkeitsbedrohungen

Abhängigkeiten umfassen direkte Abhängigkeiten in Ihren Builds sowie alle transitiven Abhängigkeiten, die rekursive Baumstruktur der Abhängigkeiten, die Ihren direkten Abhängigkeiten nachgelagert ist.

Im Diagramm gibt E an, dass im Build eine schlechte Abhängigkeit verwendet wird. Eine schlechte Abhängigkeit kann Folgendes umfassen:

  • Jede Software, von der Ihre Anwendung abhängig ist, einschließlich Komponenten, die Sie intern entwickeln, kommerzielle Drittanbieter-Software und Open-Source-Software.
  • Sicherheitslücken, die von einem der anderen Angriffsvektoren stammen. Beispiel:
    • Ein Angreifer erhält Zugriff auf Ihr Versionsverwaltungssystem und ändert die Version einer Abhängigkeit, die von Ihrem Projekt verwendet wird.
    • Ihr Build enthält eine Komponente, die von einem anderen Team in Ihrer Organisation entwickelt wurde. Sie veröffentlichen den Build und die Komponente direkt über ihre lokale Entwicklungsumgebung und führen versehentlich eine Sicherheitslücke in einer Bibliothek ein, die sie nur lokal zum Testen und Debuggen verwenden.
  • Beabsichtigte Entfernung einer Open-Source-Abhängigkeit aus einem öffentlichen Repository. Das Entfernen kann dazu führen, dass Pipelines, die die Daten nutzen, nicht mehr funktionieren, wenn sie die Abhängigkeit direkt aus dem öffentlichen Repository abrufen.

Unter Best Practices für Abhängigkeiten erfahren Sie, wie Sie Risiken mindern können.

Bedrohungen mindern

Die allgemeine Integrität Ihrer Lieferkette ist nur so stark wie ihr anfälligster Teil. Das Vernachlässigen eines Angriffsvektors erhöht das Angriffsrisiko in diesem Teil Ihrer Lieferkette.

Außerdem müssen Sie nicht alles auf einmal ändern. Der kumulative Akt-Effekt, besser bekannt als Schweizer-Käse-Modell, gilt für die Sicherheit der Softwarelieferkette. Jede implementierte Risikominderung verringert das Risiko, und wenn Sie Maßnahmen in Ihrer gesamten Lieferkette kombinieren, erhöhen Sie den Schutz vor verschiedenen Arten von Angriffen.

  • Bewerten Sie Ihren Sicherheitsstatus mithilfe von Frameworks und Tools, mit denen Sie die Fähigkeit Ihrer Organisation bewerten können, Bedrohungen zu erkennen, darauf zu reagieren und zu beheben.
  • Informieren Sie sich über Best Practices zum Schutz Ihrer Softwarelieferkette und Google Cloud-Produkte, die diese Praktiken unterstützen.
  • Verwenden Sie Software Delivery Shield, um Ihre Software in Ihrer Softwarelieferkette in Google Cloud zu schützen. Sie können Dienste schrittweise auf der Grundlage Ihrer Prioritäten und der vorhandenen Infrastruktur implementieren.

Nächste Schritte