Diese Seite wurde von der Cloud Translation API übersetzt.

Builds schützen

In diesem Dokument werden Best Practices zum Schutz Ihrer Builds beschrieben. Bauvorschriften können sich auf verschiedene Arten von Betrieben beziehen, z. B.:

Code optimieren oder verschleieren: Mit dem Open-Source-Tool Closure Compiler von Google wird JavaScript geparst und analysiert, inaktiver Code entfernt und der verbleibende Code neu geschrieben und minimiert. Außerdem wird der Code auf häufige JavaScript-Fallen geprüft.
Code in Zwischencode kompilieren: Sie können beispielsweise Java-Code in eine Java-Klassendatei (.class) oder C++-Code in eine Objektdatei (.obj) kompilieren.
Kompilieren von Code und Verknüpfen, Erstellen einer Bibliothek oder ausführbaren Datei: Beispielsweise C++-Code in eine freigegebene Bibliothek (.so) oder eine ausführbare Windows-Datei (.exe) kompilieren.
Code in ein distribuierbares oder ausführbares Format verpacken: Beispiele hierfür sind das Erstellen von Java-WAR-Dateien (.war) aus Java-Klassendateien, das Erstellen eines Docker-Images oder das Erstellen einer Python-Distribution (.whl).

Je nach verwendeter Programmiersprache und Bereitstellungsumgebung kann Ihr Build unterschiedliche Kombinationen dieser Vorgänge enthalten. So kann ein Build beispielsweise Python-Code in eine erstellte Distribution verpacken und in einen Artefaktspeicher wie Artifact Registry oder PyPI hochladen, damit Sie ihn als Abhängigkeit in Cloud Run-Funktionen verwenden können. Sie können den Python-Code auch containerisieren und das Container-Image in Cloud Run oder der Google Kubernetes Engine bereitstellen.

Die Best Practices in diesem Dokument konzentrieren sich auf das Erstellen von Code für das Verpacken oder Bereitstellen in Laufzeitumgebungen, anstatt Code zu kompilieren.

Automatisierte Builds verwenden

Bei einem automatisierten Build oder Build mit Script werden alle Build-Schritte im Build-Script oder in der Build-Konfiguration definiert, einschließlich der Schritte zum Abrufen des Quellcodes und zum Erstellen des Codes. Der einzige manuelle Befehl, falls vorhanden, ist der Befehl zum Ausführen des Builds.

Ein Build-Script kann beispielsweise:

Eine Cloud Build-cloudbuild.yaml.
Ein Makefile, das Sie mit dem make-Tool ausführen.
Eine GitHub Actions-Workflowdatei im YAML-Format, die im Verzeichnis .github/workflows/ gespeichert ist.

Automatisierte Builds sorgen für Einheitlichkeit bei den Build-Schritten. Es ist jedoch auch wichtig, Builds in einer konsistenten, vertrauenswürdigen Umgebung auszuführen.

Lokale Builds können zwar für Debugging-Zwecke nützlich sein, die Freigabe von Software aus lokalen Builds kann jedoch viele Sicherheitsrisiken, Inkonsistenzen und Ineffizienzen in den Build-Prozess einbringen.

Wenn lokale Builds zulässig sind, kann ein Angreifer mit böswilligen Absichten den Build-Prozess ändern.
Inkonsistenzen in den lokalen Umgebungen und Entwicklungspraktiken von Entwicklern erschweren die Reproduktion von Builds und die Diagnose von Build-Problemen.

Manuelle Builds machen den Prozess ineffizient, da mehr Infrastrukturressourcen wie Rechenleistung, Speicher und Netzwerke genutzt werden. Gemäß den Anforderungen für das SLSA-Framework sind automatisierte Builds für SLSA-Ebene 1 erforderlich. Für SLSA-Ebene 2 ist die Verwendung eines Build-Dienstes anstelle von Entwicklerumgebungen für Builds erforderlich.

Cloud Build ist der verwaltete Build-Dienst in Google Cloud. Dabei wird eine Build-Konfigurationsdatei verwendet, um Cloud Build Build-Schritte zur Verfügung zu stellen. Sie können Builds konfigurieren, um Abhängigkeiten abzurufen, Einheitentests, statische Analysen und Integrationstests auszuführen und Artefakte mit Build-Tools wie Docker, Gradle, Maven, Go und Python zu erstellen. Cloud Build ist vollständig in andere CI/CD-Dienste in Google Cloud wie Artifact Registry und Cloud Deploy sowie in Laufzeitumgebungen wie GKE und Cloud Run eingebunden. Außerdem ist eine Integration in gängige Quellcodeverwaltungssysteme wie GitHub und Bitbucket möglich.

Build-Herkunft generieren

Die Build-Herkunft ist eine Sammlung überprüfbarer Daten zu einem Build.

Herkunftsmetadaten enthalten Details wie die Digests der erstellten Images, die Quell-Speicherorte, die Build-Toolchain und die Build-Dauer.

Wenn Sie die Build-Herkunft generieren, haben Sie folgende Möglichkeiten:

Prüfen, ob ein erstelltes Artefakt von einem vertrauenswürdigen Quellspeicherort und einem vertrauenswürdigen Build-System erstellt wurde.
Code identifizieren, der von einem nicht vertrauenswürdigen Quellspeicherort oder Build-System eingeschleust wurde

Sie können Benachrichtigungs- und Richtlinienmechanismen verwenden, um Daten zur Buildherkunft proaktiv zu nutzen. Sie können beispielsweise Richtlinien erstellen, die nur Deployments von Code zulassen, der aus bestätigten Quellen erstellt wurde.

Bei SLSA-Level 1 muss die Build-Herkunft für die Nutzer der erstellten Artefakte verfügbar sein. Für SLSA-Ebene 2 müssen die Daten zur Build-Herkunft außerdem:

Sie werden vom Build-Dienst generiert oder können direkt aus dem Build-Dienst gelesen werden.
Sie müssen von Verbrauchern auf Authentizität und Integrität überprüft werden können. Dies sollte mit einer digitalen Signatur erfolgen, die vom Dienst generiert wird, der die Build-Herkunftsdaten erstellt.

Bei SLSA-Level 3 müssen die Inhalte zur Provenienz außerdem Folgendes enthalten:

Der Einstiegspunkt der Build-Definition.
Alle Build-Parameter, die ein Nutzer verwalten kann.

Cloud Build kann eine Build-Herkunft für Container-Images generieren, die eine Build-Sicherheit auf SLSA-Level 3 bieten. Weitere Informationen finden Sie unter Herkunft von Builds ansehen.

Sitzungsspezifische Build-Umgebung verwenden

Sitzungsspezifische Umgebungen sind temporäre Umgebungen, die für eine einzelne Buildausführung gedacht sind. Nach dem Build wird die Umgebung gelöscht. Mit sitzungsspezifischen Builds wird sichergestellt, dass der Build-Dienst und die Build-Schritte in einer sitzungsspezifischen Umgebung wie einem Container oder einer VM ausgeführt werden. Anstatt eine vorhandene Build-Umgebung wiederzuverwenden, stellt der Build-Dienst für jeden Build eine neue Umgebung bereit und zerstört sie nach Abschluss des Build-Prozesses.

Mit sitzungsspezifischen Umgebungen können Sie saubere Builds erzielen, da es keine Dateien oder Umgebungseinstellungen aus früheren Builds gibt, die den Buildprozess beeinträchtigen könnten. Eine nicht sitzungsspezifische Umgebung bietet Angreifern die Möglichkeit, schädliche Dateien und Inhalte einzuschleusen. Außerdem wird durch eine sitzungsspezifische Umgebung der Wartungsaufwand reduziert und Inkonsistenzen in der Build-Umgebung werden verringert.

Cloud Build richtet für jeden Build eine neue VM-Umgebung ein und löscht sie nach dem Build.

Zugriff auf den Build-Dienst einschränken

Beachten Sie das Sicherheitsprinzip der geringsten Berechtigung, indem Sie dem Build-Dienst und den Build-Ressourcen die minimal erforderlichen Berechtigungen gewähren. Sie sollten auch eine nicht menschliche Identität verwenden, um Builds auszuführen und im Namen des Builds mit anderen Diensten zu interagieren.

Wenn Sie Cloud Build verwenden:

Gewähren Sie den Mitgliedern Ihrer Organisation die erforderlichen Mindestberechtigungen.
Passen Sie die Berechtigungen für das Dienstkonto an, das im Namen von Cloud Build agiert, sodass es nur die für Ihre Nutzung erforderlichen Berechtigungen hat. Bearbeiten Sie die Berechtigungen des standardmäßigen Cloud Build-Dienstkontos oder verwenden Sie stattdessen ein benutzerdefiniertes Dienstkonto.
Mit der Cloud Build-Organisationsrichtlinie Zulässige Integrationen können Sie die externen Dienste steuern, die Build-Trigger auslösen dürfen.
Platzieren Sie Cloud Build mit VPC Service Controls in einem Dienstperimeter. Der Perimeter ermöglicht die freie Kommunikation zwischen Google Cloud-Diensten innerhalb des Perimeters, schränkt aber die Kommunikation über den Perimeter basierend auf von Ihnen angegebenen Regeln ein. Der Perimeter verringert auch das Risiko der Daten-Exfiltration.

Cloud Build unterstützt VPC Service Controls nur für Builds, die in einem privaten Pool ausgeführt werden.

Anmeldedaten schützen

Builds umfassen häufig Verbindungen zu anderen Systemen wie Versionskontrollsystemen, Artefaktspeichern und Bereitstellungsumgebungen. Wenn Sie die Anmeldedaten schützen, die Sie in Ihren Builds verwenden, können Sie den unbefugten Zugriff auf Systeme in Ihrer Softwarelieferkette und die Daten-Exfiltration verhindern.

Speichern Sie hartcodierte Anmeldedaten nicht direkt in der Versionskontrolle oder in der Build-Konfiguration. Speichern Sie Anmeldedaten stattdessen in einem sicheren Schlüsselspeicher.

In Google Cloud werden API-Schlüssel, Passwörter und andere sensible Daten sicher in Secret Manager gespeichert. Sie können Cloud Build so konfigurieren, dass in Secret Manager gespeicherte Secrets verwendet werden.

Abhängigkeiten verwalten

Die Integrität Ihrer Anwendungen hängt sowohl von der Integrität des von Ihnen entwickelten Codes als auch von allen verwendeten Abhängigkeiten ab. Außerdem müssen Sie berücksichtigen, wo Sie Ihre Abhängigkeiten veröffentlichen, wer Lese- und Schreibzugriff auf Ihre Artefakt-Repositories hat, und Richtlinien für vertrauenswürdige Quellen von Build-Artefakten, die Sie in Ihren Laufzeitumgebungen bereitstellen.

Weitere Informationen zur Abhängigkeitsverwaltung finden Sie unter Abhängigkeiten verwalten.

In Cloud Build verwenden Sie Cloud-Builder, um Befehle auszuführen. Builder sind Container-Images, in denen häufig genutzte Sprachen und Tools installiert sind. Sie können öffentliche Container-Images aus öffentlichen Registern wie Docker Hub, von Cloud Build bereitgestellte Builds, von der Community erstellte Builds und benutzerdefinierte Builds verwenden, die Sie erstellen. Sie können auch buildpacks als Builders verwenden, einschließlich der Buildpacks von Google Cloud.

Prüfen Sie die Builder, die Sie in Ihren Cloud Build-Builds verwenden, und finden Sie heraus, wer sie bereitstellt. Entscheiden Sie dann, ob Sie ihnen in Ihrer Softwarelieferkette vertrauen. Wenn Sie mehr Kontrolle über den Code in einem Builder haben möchten, können Sie benutzerdefinierte Builder erstellen, anstatt Builder aus einer öffentlichen Quelle zu verwenden.

Möglichkeiten zur Änderung des Builds reduzieren

Es gibt eine Vielzahl anderer Faktoren, die einen Build beeinflussen können, darunter:

Builds, die gleichzeitig ausgeführt werden und sich gegenseitig beeinflussen können, oder ein Build, der beibehalten wird und sich auf einen nachfolgenden Build auswirkt.
Builds, die andere Nutzerparameter als den Build-Einstiegspunkt und den Quellspeicherort der obersten Ebene akzeptieren.
Builds, bei denen Abhängigkeiten mit Bereichen oder veränderliche Abhängigkeiten angegeben werden (z. B. mit einem Image mit dem latest-Tag) Diese Ansätze bergen das Risiko, dass bei Builds fehlerhafte oder unerwünschte Versionen von Abhängigkeiten verwendet werden.

Mit den folgenden Praktiken können Sie diese Risiken minimieren:

Führen Sie jeden Build in einer sitzungsspezifischen Umgebung aus.
Führen Sie Builds nicht mit zusätzlichen Parametern aus, damit Nutzer die in den Build-Scripts definierten Variablen nicht beeinflussen können.
Beschränken Sie den Zugriff auf den Build-Dienst und die Build-Ressourcen.
Verweise auf unveränderliche Versionen von Abhängigkeiten anstelle von Kennungen wie Tags, die in Zukunft auf eine andere Version des Artefakts verweisen können. Weitere Informationen zu Abhängigkeiten finden Sie unter Abhängigkeitsverwaltung.

Sicherheit der Softwarelieferkette

Google Cloud bietet eine Reihe modularer Funktionen und Tools, mit denen Sie die Sicherheit Ihrer Softwarelieferketten verbessern können. Dort werden Sicherheitserkenntnisse für mit Cloud Build erstellte Anwendungen angezeigt. Dazu zählen:

Die SLSA-Ebene, die die Reife der Sicherheit Ihrer Softwarelieferkette angibt.
Sicherheitslücken, Software-Materiallisten (SBOM) und VEX-Anweisungen (Vulnerability Exploitability eXchange) für Build-Artefakte.
Build-Herkunft, eine Sammlung überprüfbarer Metadaten zu einem Build. Sie enthalten Details wie die Digests der erstellten Images, die Quell-Speicherorte, die Build-Toolchain, die Build-Schritte und die Build-Dauer.

Eine Anleitung zum Ansehen von Sicherheitsstatistiken für erstellte Anwendungen finden Sie unter Anwendung erstellen und Sicherheitsstatistiken ansehen.