Bedrohungen der Softwarelieferkette

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

Zu den Risiken von angreifbarer 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 zu Zeit- und Geldverlust sowie zu einem Vertrauensverlust bei den Kunden.

Die Eintrittspunkte für Bedrohungen umfassen den gesamten Softwarelebenszyklus und können innerhalb oder außerhalb Ihrer Organisation liegen.

Eingangspunkte für Angriffe auf die Softwarelieferkette

Die Diagrammlegende enthält zwei Arten von Bedrohungen:

Google Cloud bietet eine modulare Reihe von Funktionen und Tools, die Best Practices zur Minimierung beider Bedrohungen umfassen.

In den Unterabschnitten dieses Dokuments werden die Bedrohungen im Zusammenhang mit Quellcode, Builds, Bereitstellung und Abhängigkeiten beschrieben.

Quellbedrohungen

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

  • 1: unsicheren Code schreiben Wenn keine sicheren Codierungspraktiken angewendet werden, kann es passieren, dass Code geschrieben wird, der unbeabsichtigt Sicherheitslücken enthält. Unsichere Entwickler-Workstations können auch schädlichen oder unsicheren Code einschleusen. Zu den Maßnahmen 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 Vorabversion) bietet Echtzeit-Sicherheitsfeedback, 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 im Betriebssystem und in Sprachpaketen zu prüfen.
    • Informationen zu Methoden zur Sicherheit von Code

  • 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 eröffnet. Zu den Maßnahmen gehören:

    • Manuelle Überprüfung von Änderungen am Quellcode
    • Code-Scan- und Lint-Tools verwenden, die in IDEs und Quellcodekontrollsysteme eingebunden sind

  • B: Das Versionskontrollsystem manipulieren. Durch die Einschränkung des Zugriffs auf das Versionskontrollsystem und andere Systeme in Ihrer Build-Pipeline und die Verwendung der Multi-Faktor-Authentifizierung lässt sich dieses Risiko verringern.

Prüfen Sie bei der Bewertung der Quellintegrität auch die unterstützenden Scripts und Konfigurationen, die Sie zum Erstellen und Bereitstellen Ihrer Software verwenden. Nehmen Sie sie in Ihr Versionskontrollsystem und Ihre Codeüberprüfungsprozesse auf, um das Risiko von Sicherheitslücken in diesen Dateien zu verringern.

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

Bedrohungen aufbauen

Diese Bedrohungen gefährden Ihre Software beim Erstellen oder Verpacken oder täuschen Nutzer Ihrer Software vor, eine fehlerhafte Version zu verwenden.

  • C: Build mit einer Quelle, die nicht aus dem vertrauenswürdigen System zur Quellenkontrolle stammt. Maßnahmen zur Risikominimierung:
    • Verwenden Sie Build-Dienste wie Cloud Build, die Informationen zur Herkunft generieren, damit Sie prüfen können, ob für Ihre Builds eine vertrauenswürdige Quelle verwendet 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.
    • Speichern und Verwenden vertrauenswürdiger Kopien der benötigten Open-Source-Abhängigkeiten in einem privaten Artefaktspeicher wie Artifact Registry.
  • D: Das Build-System manipulieren. Maßnahmen zur Risikominimierung:
    • Beschränken Sie den direkten Zugriff auf das Buildsystem auf Personen, die ihn benötigen, und folgen Sie dabei dem Prinzip der geringsten Berechtigung. In Google Cloud können Sie die entsprechenden vordefinierten Rollen gewähren oder benutzerdefinierte Rollen erstellen.
    • Verwaltete Build-Dienste wie Cloud Build verwenden Cloud Build führt sitzungsspezifische 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 Daten-Exfiltration 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. Mit Build-Systemen, die die Herkunft von Builds generieren und signieren, können Sie überprüfen, ob Ihre Software mit einem vertrauenswürdigen Build-System erstellt wurde.
  • G: Das Repository manipulieren, in dem Sie Ihre Software für Ihre internen oder externen Nutzer speichern. Maßnahmen zur Risikominimierung:
    • Speichern und Verwenden vertrauenswürdiger Kopien der benötigten Open-Source-Abhängigkeiten in privaten Artefaktspeichern wie der Artifact Registry.
    • Validierung der Herkunft von Build und Quelle
    • Berechtigungen für Uploads auf nicht von Menschen verwaltete Konten und Repository-Administratoren beschränken In Google Cloud handeln Dienstkonten im Namen von Diensten und Anwendungen.

Bedrohungen bei der Bereitstellung und Laufzeit

  • H: Wenn Sie Abhängigkeiten durch Angabe eines Versionsbereichs oder eines Tags auflösen, das nicht dauerhaft mit einer bestimmten Buildversion verknüpft ist, kann dies zu mehreren Problemen führen:

    • Builds sind nicht reproduzierbar, da sich die Abhängigkeiten, die ein Build zum 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 auf eine manipulierte Version oder eine Version mit Änderungen verweisen, die Ihre Software beeinträchtigen. Böswillige Akteure können diese Unsicherheit ausnutzen, um dafür zu sorgen, dass bei Ihrem Build ihre Version eines Pakets anstelle der von Ihnen beabsichtigten Version ausgewählt wird. Mit einer Reihe von Best Practices für Abhängigkeiten können Sie das Risiko von Abhängigkeitsverwirrung minimieren.

  • 2: Den Bereitstellungsprozess manipulieren. Wenn Sie einen kontinuierlichen Bereitstellungsprozess verwenden, kann eine Manipulation dieses Prozesses unerwünschte Änderungen an der Software verursachen, die Sie Ihren Nutzern zur Verfügung stellen. Sie können das Risiko verringern, indem Sie den Zugriff auf Ihren Bereitstellungsdienst einschränken und Änderungen in Vorproduktionsumgebungen testen. Cloud Deploy kann Ihnen dabei helfen, den kontinuierlichen Bereitstellungsprozess und die Hochstufung zwischen Umgebungen zu verwalten.

  • 3: Sie stellen manipulierte oder nicht konforme Software bereit. Durch die Durchsetzung von Bereitstellungsrichtlinien lässt sich dieses Risiko 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 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 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 laufenden Arbeitslasten.

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

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

Abhängigkeitsrisiken

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

Im Diagramm steht E für die Verwendung einer fehlerhaften Abhängigkeit in Ihrem Build. Beispiele für schädliche Abhängigkeiten:

  • Alle Software, von der Ihre Anwendung abhängt, einschließlich intern entwickelter Komponenten, kommerzieller Drittanbietersoftware und Open-Source-Software.
  • Sicherheitslücken, die sich aus anderen Angriffsvektoren ergeben. Beispiel:
    • Ein Angreifer erlangt Zugriff auf Ihr Versionskontrollsystem und ändert die Version einer Abhängigkeit, die in Ihrem Projekt verwendet wird.
    • Ihr Build enthält eine Komponente, die von einem anderen Team in Ihrer Organisation entwickelt wurde. Er erstellt und veröffentlicht die Komponente direkt aus seinen lokalen Entwicklungsumgebungen und führt versehentlich eine Sicherheitslücke in einer Bibliothek ein, die er nur lokal für Tests und Debugging verwendet.
  • Das vorsätzliche 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, nicht mehr funktionieren.

Informationen dazu, wie Sie Risiken minimieren können, finden Sie in den Best Practices für Abhängigkeiten.

Bedrohungen mindern

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

Sie müssen aber nicht alles auf einmal ändern. Der Kumulative-Aktion-Effekt, besser bekannt als Schweizer-Käse-Modell, gilt auch für die Sicherheit der Softwarelieferkette. Jede Risikominderung, die Sie implementieren, reduziert Ihr Risiko. Wenn Sie Risikominderungen in Ihrer gesamten Lieferkette kombinieren, erhöhen Sie den Schutz vor verschiedenen Arten von Angriffen.

  • Bewerten Sie Ihren Sicherheitsstatus mithilfe von Frameworks und Tools, die Ihnen dabei helfen, die Fähigkeit Ihres Unternehmens zur Erkennung, Reaktion und Behebung von Bedrohungen zu bewerten.
  • Hier finden Sie Best Practices zum Schutz Ihrer Softwarelieferkette und Google Cloud-Produkte, die diese Best Practices unterstützen.
  • Binden Sie die Sicherheitsfunktionen von Google Cloud in Ihre Entwicklungs-, Build- und Bereitstellungsprozesse ein, um die Sicherheit Ihrer Softwarelieferkette zu verbessern. Sie können Dienste je nach Ihren Prioritäten und Ihrer vorhandenen Infrastruktur nach und nach implementieren.

Nächste Schritte