Angriffsvektoren für Softwarelieferketten sind die verschiedenen Möglichkeiten, wie jemand Ihre Software absichtlich oder versehentlich kompromittieren kann.
Risiken durch anfällige Software sind unter anderem das Preisgeben 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 und zu einem Vertrauensverlust bei den Kunden.
Die Angriffspunkte für Bedrohungen erstrecken sich über den gesamten Softwarelebenszyklus und können innerhalb oder außerhalb Ihrer Organisation entstehen.
Die Diagrammlegende enthält zwei Arten von Bedrohungen:
- Die Buchstaben A bis H geben Angriffspunkte in der Softwarelieferkette an, die im Supply Chain Levels for Software Artifacts (SLSA)-Framework als Bedrohungen beschrieben werden.
- Die Zahlen 1 bis 4 weisen auf zusätzliche Angriffsvektoren hin, die im SLSA-Framework nicht direkt beschrieben werden.
Google Cloud bietet eine modulare Reihe von Funktionen und Tools, die Best Practices zur Eindämmung beider Arten von Bedrohungen enthalten.
In den Unterabschnitten dieses Dokuments werden die Bedrohungen im Kontext von Quelle, Builds, Bereitstellung und Abhängigkeiten beschrieben.
- Quellbedrohungen
- Build-Bedrohungen
- Bereitstellungs- und Laufzeitbedrohungen
- Bedrohungen durch Abhängigkeiten
Quellbedrohungen
Diese Bedrohungen beeinträchtigen die Integrität Ihres Quellcodes.
1: Unsicheren Code schreiben. Wenn keine sicheren Codierungspraktiken angewendet werden, kann es passieren, dass Code geschrieben wird, der unbeabsichtigt Sicherheitslücken enthält. Unsichere Entwicklerarbeitsplätze können auch schädlichen oder unsicheren Code einschleusen. Mögliche Maßnahmen:
- 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 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 im Betriebssystem und in Sprachpaketen zu scannen.
- Informationen zu Methoden, um Code sicherer zu machen.
A: Ungültiger Code wird an das Quell-Repository gesendet. Dazu gehört nicht nur schädlicher Code, sondern auch Code, der unbeabsichtigt Sicherheitslücken für Angriffe wie Cross-Site-Scripting einführt. Mögliche Maßnahmen:
- Änderungen am Quellcode müssen von Menschen überprüft werden.
- Verwenden Sie Tools zum Scannen und Linting von Code, die in IDEs und Quellcodeverwaltungssysteme integriert sind.
B: Das Quellcodeverwaltungssystem manipulieren. Das Risiko lässt sich verringern, indem Sie den Zugriff auf das Versionsverwaltungssystem und andere Systeme in Ihrer Build-Pipeline einschränken und die Multi-Faktor-Authentifizierung verwenden.
Prüfen Sie bei der Bewertung der Quellintegrität auch unterstützende Skripts und Konfigurationen, die Sie zum Erstellen und Bereitstellen Ihrer Software verwenden. Nehmen Sie sie in Ihr Versionsverwaltungssystem und Ihre Code-Review-Prozesse 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 erkennen
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 Quellcodeverwaltungssystem stammt.
Folgende Maßnahmen können helfen, dieses Risiko zu verringern:
- Verwenden Sie Build-Dienste wie Cloud Build, die Herkunftsinformationen generieren, damit Sie überprüfen können, ob Ihre Builds eine vertrauenswürdige Quelle verwenden.
- 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 kompromittieren. Zu den Maßnahmen, die dazu beitragen, dieses Risiko zu verringern, gehören:
- Befolgen Sie das Prinzip der geringsten Berechtigung, indem Sie den direkten Zugriff auf das Build-System auf Personen beschränken, die ihn benötigen. In Google Cloud können Sie entsprechende vordefinierte Rollen zuweisen 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 die Herkunft von Builds generieren und signieren, ermöglichen es Ihnen, zu prüfen, ob Ihre Software von einem vertrauenswürdigen Build-System erstellt wurde.
- G: Das Repository, in dem Sie Ihre Software für interne oder externe Nutzer speichern, wird manipuliert. Zu den Maßnahmen, die dazu beitragen, dieses Risiko zu verringern, gehören:
- Speichern und Verwenden von vertrauenswürdigen Kopien der Open-Source-Abhängigkeiten, die Sie in privaten Artefaktspeichern wie Artifact Registry benötigen.
- Build- und Quellherkunft validieren.
- Einschränken der Uploadberechtigungen auf dedizierte Konten, die nicht von Menschen genutzt werden, und auf Repository-Administratoren. Auf Google Cloudagieren Dienstkonten im Namen von Diensten und Anwendungen.
Bedrohungen bei der Bereitstellung und Laufzeit
H: Das Auflösen von Abhängigkeiten durch Angabe eines Versionsbereichs oder eines Tags, das nicht dauerhaft an eine bestimmte Build-Version angehängt ist, kann zu mehreren Problemen führen:
- Builds sind nicht reproduzierbar, da sich Abhängigkeiten, die ein Build beim ersten Mal verwendet, von Abhängigkeiten unterscheiden können, die der Build bei zukünftigen Ausführungen desselben Builds verwendet.
- Eine Abhängigkeit kann in eine manipulierte Version oder eine Version mit Änderungen aufgelöst werden, die Ihre Software beschädigen. Böswillige Akteure können diese Unsicherheit ausnutzen, damit bei Ihrem Build ihre Version eines Pakets anstelle der von Ihnen beabsichtigten Version ausgewählt wird. Eine Reihe von Best Practices für Abhängigkeiten kann dazu beitragen, die Risiken von Dependency Confusion zu minimieren.
2: Den Bereitstellungsprozess manipulieren. Wenn Sie einen Prozess für die kontinuierliche Bereitstellung verwenden, können durch eine Kompromittierung dieses Prozesses unerwünschte Änderungen an der Software vorgenommen werden, die Sie Ihren Nutzern bereitstellen. Sie können das Risiko verringern, 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 Hochstufung zwischen Umgebungen zu verwalten.
3: Bereitstellung von kompromittierter oder nicht konformer Software. Durch die Erzwingung 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. Neue Ergebnisse können daher das Sicherheitsrisiko für Ihre Produktionsanwendungen ändern.
- Einige Konfigurationen erhöhen das Risiko eines unbefugten Zugriffs, z. B. die Ausführung als Root-Nutzer oder die Zulassung einer 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 auch Sicherheitsinformationen zu Ihren bereitgestellten Revisionen aufrufen, einschließlich bekannter Sicherheitslücken in den von Ihnen bereitgestellten Container-Images.
Weitere Informationen zum Schutz Ihres Quellcodes finden Sie unter Builds schützen und zum Schutz von Bereitstellungen unter Bereitstellungen schützen.
Bedrohungen durch Abhängigkeiten
Abhängigkeiten umfassen direkte Abhängigkeiten in Ihren Builds sowie alle transitiven Abhängigkeiten, den rekursiven Baum von Abhängigkeiten, die von Ihren direkten Abhängigkeiten abgeleitet sind.
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 intern entwickelter Komponenten, kommerzieller Drittanbietersoftware und Open-Source-Software.
- Sicherheitslücken, die durch einen der anderen Angriffsvektoren entstehen. Beispiel:
- Ein Angreifer erhält Zugriff auf Ihr Quellcodeverwaltungssystem 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 erstellen und veröffentlichen die Komponente direkt aus ihren lokalen Entwicklungsumgebungen und führen versehentlich eine Sicherheitslücke in einer Bibliothek ein, die sie nur lokal zum Testen und Debuggen verwenden.
- Die absichtliche Entfernung 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.
Best Practices für Abhängigkeiten
Bedrohungen abwehren
Die allgemeine Integrität Ihrer Lieferkette ist nur so stark wie ihr anfälligster Teil. Wenn Sie einen Angriffsvektor vernachlässigen, steigt das Risiko eines Angriffs in diesem Teil Ihrer Lieferkette.
Sie müssen aber nicht alles auf einmal ändern. Der kumulative Effekt, besser bekannt als das Schweizerkäsemodell, gilt für die Sicherheit der Softwarelieferkette. Jede umgesetzte Maßnahme verringert Ihr Risiko. 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 Ihres Unternehmens bewerten können, Bedrohungen zu erkennen, darauf zu reagieren und sie zu beheben.
- Best Practices zum Schutz Ihrer Softwarelieferkette und Google Cloud Produkte, die diese Praktiken unterstützen.
- Integrieren Sie Google Cloud Sicherheitsfunktionen in Ihre Entwicklungs-, Build- und Bereitstellungsprozesse, um die Sicherheit Ihrer Softwarelieferkette zu verbessern. Sie können Dienste basierend auf Ihren Prioritäten und Ihrer vorhandenen Infrastruktur schrittweise implementieren.