Bedrohungen der Softwarelieferkette

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

Zu den Risiken von anfälliger Software gehören das Durchsickern von Anmeldedaten oder vertraulichen Daten, die Beschädigung von Daten, die Installation von Malware und Anwendungsausfälle. Diese Probleme führen zu Zeit-, Geld- und Vertrauensverlust bei Kunden.

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

Einstiegspunkte für Angriffe auf die Softwarelieferkette

Die Legende des Diagramms enthält zwei Arten von Bedrohungen:

Google Cloud bietet ein modulares Set von Funktionen und Tools, die Best Practices zur Minimierung beider Arten von Bedrohungen enthalten.

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

Bedrohungen für die Quelle

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

  • 1: Unsicheren Code schreiben. Wenn keine sicheren Codierungspraktiken angewendet werden, kann Code geschrieben werden, der unbeabsichtigt Sicherheitslücken enthält. Unsichere Entwicklerarbeitsplätze können auch schädlichen oder unsicheren Code einführen. Zu den Maßnahmen zur Risikominimierung gehören:

    • Richtlinien für Entwicklerarbeitsplätze festlegen. Cloud Workstations bietet vollständig verwaltete, vorkonfigurierte Arbeitsplätze, die Sie an Ihre Anforderungen anpassen können.
    • Code lokal scannen. Cloud Code Source Protect (Private Preview) bietet Sicherheitsfeedback in Echtzeit, einschließlich Informationen zu Sicherheitslücken und Lizenzen für Abhängigkeiten. Entwickler können auch die On-Demand Scanning API verwenden, um Container-Images auf Sicherheitslücken in Betriebssystemen und Sprachpaketen zu scannen.
    • Informationen zu Praktiken, mit denen Code sicherer gemacht werden kann.

  • A: Ungültigen Code an das Quell-Repository senden. Dazu gehört nicht nur schädlicher Code, sondern auch Code, der unbeabsichtigt Sicherheitslücken für einen Angriff wie Cross-Site-Scripting einführt. Zu den Maßnahmen zur Risikominimierung gehören:

    • Manuelle Überprüfung von Änderungen am Quellcode erforderlich machen.
    • Tools zum Scannen und Linten von Code verwenden, die in IDEs und Versionsverwaltungssysteme integriert sind.

  • B: Das Versionsverwaltungssystem kompromittieren. Das Risiko kann minimiert werden, indem der Zugriff auf das Versionsverwaltungssystem und andere Systeme in Ihrer Build-Pipeline eingeschränkt und die Multi-Faktor-Authentifizierung verwendet wird.

Wenn Sie die Integrität Ihrer Quelle bewerten, sollten Sie auch unterstützende Skripts und Konfigurationen untersuchen, die Sie zum Erstellen und Bereitstellen Ihrer Software verwenden. Nehmen Sie sie in Ihre Versionsverwaltungssystem- und Code-Review-Prozesse auf, damit Sie das Risiko von Sicherheitslücken in diesen Dateien verringern können.

Weitere Informationen zum Schutz Ihrer Quelle finden Sie unter Quelle schützen.

Bedrohungen für Builds

Diese Bedrohungen kompromittieren Ihre Software, wenn Sie sie erstellen oder verpacken, oder verleiten Nutzer Ihrer Software dazu, eine fehlerhafte Version zu verwenden.

  • C: Mit einer Quelle erstellen, die nicht aus dem vertrauenswürdigen Versionsverwaltungssystem stammt. Zu den Maßnahmen zur Risikominimierung gehören:
    • Build-Dienste wie Cloud Build verwenden, die Herkunftsinformationen generieren, damit Sie prüfen können, ob Ihre Builds eine vertrauenswürdige Quelle verwenden.
    • Ihre CI/CD-Infrastruktur in einem Netzwerkperimeter platzieren, 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: Das Build-System kompromittieren. Zu den Maßnahmen zur Risikominimierung gehören:
    • Das Prinzip der geringsten Berechtigung befolgen, indem Sie den direkten Zugriff auf das Build-System auf Personen beschränken, die ihn benötigen. In Google Cloud Sie können geeignete vordefinierte Rollen gewähren oder benutzerdefinierte Rollen erstellen.
    • Verwenden Sie verwaltete Build-Dienste wie Cloud Build. Cloud Build führt kurzlebige Builds aus, indem für jeden Build eine VM-Umgebung eingerichtet und nach dem Build wieder gelöscht wird.
    • Platzieren Sie Ihre 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.
  • F: Software verpacken und veröffentlichen, die außerhalb des offiziellen Prozesses erstellt wurde. Build-Systeme, die Build-Herkunft generieren und signieren, ermöglichen es Ihnen, zu prüfen, ob Ihre Software von einem vertrauenswürdigen Build-System erstellt wurde.
  • G: Das Repository kompromittieren, in dem Sie Ihre Software für Ihre internen oder externen Nutzer speichern. Zu den Maßnahmen zur Risikominimierung gehören:
    • Vertrauenswürdige Kopien von Open-Source-Abhängigkeiten, die Sie benötigen, in privaten Artefaktspeichern wie Artifact Registry speichern und verwenden.
    • Herkunft von Builds und Quellen validieren.
    • Uploadberechtigungen auf dedizierte nicht menschliche Konten und Repository-Administratoren beschränken. Inhandeln Dienstkonten im Namen von Diensten und Anwendungen. Google Cloud

Bedrohungen für 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, kann dies zu mehreren Problemen führen:

    • Builds sind nicht reproduzierbar, da sich die Abhängigkeiten, die ein Build beim ersten Mal verwendet, von den Abhängigkeiten unterscheiden können, die der Build für zukünftige Ausführungen desselben Builds verwendet.
    • Eine Abhängigkeit kann zu einer kompromittierten Version oder einer Version mit Änderungen aufgelöst werden, die Ihre Software beschädigen. Böswillige Akteure können diese Unsicherheit ausnutzen, um zu bewirken, dass Ihr Build ihre Version eines Pakets anstelle der von Ihnen beabsichtigten Version auswählt. Eine Reihe von Best Practices für Abhängigkeiten kann dazu beitragen, die Risiken von Abhängigkeitsverwirrung zu minimieren.

  • 2: Den Bereitstellungsprozess kompromittieren. Wenn Sie einen Continuous Deployment-Prozess verwenden, können durch die Kompromittierung dieses Prozesses unerwünschte Änderungen an der Software vorgenommen werden, 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 helfen, den Continuous Delivery-Prozess und die Übertragung zwischen Umgebungen zu verwalten.

  • 3: Kompromittierte oder nicht konforme Software bereitstellen. Die Durchsetzung von Bereitstellungsrichtlinien kann dazu beitragen, dieses Risiko zu minimieren. Mit der Binärautorisierung können Sie prüfen, ob Container-Images den Richtlinienkriterien entsprechen, und die Bereitstellung von Container-Images aus nicht vertrauenswürdigen Quellen blockieren.

  • 4: Sicherheitslücken und Fehlkonfigurationen in der ausgeführten Software.

    • Regelmäßig werden neue Sicherheitslücken entdeckt. Das bedeutet, dass neue Ergebnisse das Sicherheitsrisiko für Ihre Anwendungen in der Produktion verändern können.
    • Einige Konfigurationen erhöhen das Risiko eines unbefugten Zugriffs, z. B. die Ausführung als Root-Nutzer oder die Zulassung der Rechteausweitung bei der Ausführung eines Containers.

    Das GKE-Sicherheitsstatus-Dashboard enthält Informationen zu Sicherheitslücken und Konfigurationsproblemen in Ihren ausgeführten Arbeitslasten.

    In Cloud Run können Sie auch Sicherheitsinformationen zu Ihren bereitgestellten Revisionen ansehen, einschließlich bekannter Sicherheitslücken in den von Ihnen bereitgestellten Container- Images.

Weitere Informationen zum Schutz Ihrer Quelle finden Sie unter Quelle schützen und zum Schutz von Bereitstellungen unter Bereitstellungen schützen.

Bedrohungen für Abhängigkeiten

Zu den Abhängigkeiten gehören direkte Abhängigkeiten in Ihren Builds sowie alle transitiven Abhängigkeiten, der rekursive Baum von Abhängigkeiten, die von Ihren direkten Abhängigkeiten abhängen.

Im Diagramm steht E für die Verwendung einer fehlerhaften Abhängigkeit in Ihrem Build. Eine fehlerhafte Abhängigkeit kann Folgendes umfassen:

  • Jegliche Software, von der Ihre Anwendung abhängt, einschließlich Komponenten, die Sie intern entwickeln, kommerzielle Drittanbietersoftware 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 Ihr Projekt verwendet.
    • Ihr Build enthält eine Komponente, die von einem anderen Team in Ihrer Organisation entwickelt wurde. Das Team erstellt und veröffentlicht die Komponente direkt aus seinen lokalen Entwicklungsumgebungen und führt versehentlich eine Sicherheitslücke in einer Bibliothek ein, die nur lokal zum Testen und Debuggen verwendet wird.
  • Absichtliches Entfernen einer Open-Source-Abhängigkeit aus einem öffentlichen Repository. Das Entfernen kann dazu führen, dass Pipelines, die die Abhängigkeit direkt aus dem öffentlichen Repository abrufen, unterbrochen werden.

Unter Best Practices für Abhängigkeiten finden Sie Informationen zu Möglichkeiten zur Risikominimierung.

Bedrohungen minimieren

Die allgemeine Integrität Ihrer Lieferkette ist nur so stark wie ihr anfälligster Teil. Wenn Sie einen Angriffsvektor vernachlässigen, erhöht sich das Risiko eines Angriffs in diesem Teil Ihrer Lieferkette.

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

  • Bewerten Sie Ihren Sicherheitsstatus mit Frameworks und Tools, mit denen Sie die Fähigkeit Ihrer Organisation bewerten können, Bedrohungen zu erkennen, darauf zu reagieren und sie zu beheben.
  • Informieren Sie sich über Best Practices zum Schutz Ihrer Softwarelieferkette, und Google Cloud über Produkte, die diese Praktiken unterstützen.
  • Integrieren Sie Google Cloud Sicherheitsfunktionen in Ihre Entwicklungs-, Build- und Bereitstellungsprozesse, um den Sicherheitsstatus Ihrer Software-Lieferkette zu verbessern. Sie können Dienste schrittweise implementieren, basierend auf Ihren Prioritäten und der vorhandenen Infrastruktur.

Nächste Schritte