Diese Seite wurde von der Cloud Translation API übersetzt.

Builds schützen

In diesem Dokument werden Best Practices zum Schutz Ihrer Builds beschrieben. Gebäudecode kann sich auf verschiedene Arten von Vorgängen beziehen, z. B.:

Code optimieren oder unkenntlich machen: 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 kompilieren. in eine Java-Klassendatei (.class) oder C++-Code in eine Objektdatei (.obj).
Code kompilieren und verknüpfen, Bibliothek oder ausführbare Datei erstellen: Beispiel: C++-Code in eine gemeinsam genutzte Bibliothek (.so) oder eine ausführbare Windows-Datei kompilieren Datei (.exe)
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 Umgebung, in der Sie die Bereitstellung vornehmen, kann Ihr Build verschiedene 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 Google Kubernetes Engine bereitstellen.

Bei den Best Practices in diesem Dokument geht es um die Erstellung von Code für die Verpackung oder die Bereitstellung in Laufzeitumgebungen vornehmen, 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 erstellen.

Ein Build-Script kann beispielsweise so aussehen:

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

Automatisierte Builds sorgen für Konsistenz 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.
Unstimmigkeiten in den lokalen Umgebungen und Praktiken der Entwicklerteams ist es schwierig, Builds zu reproduzieren und Build-Probleme zu diagnostizieren.

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 auf 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, Unittests, statische Analysen und Integrationstests ausführen und Artefakte erstellen mit Build-Tools wie Docker, Gradle, Maven, Go und Python. Cloud Build ist vollständig in andere CI/CD-Dienste auf Google Cloud wie Artifact Registry und Cloud Deploy, als sowie Laufzeitumgebungen wie GKE und Cloud Run ermöglicht auch die Einbindung in den wichtigsten Quellcode. wie GitHub und Bitbucket.

Build-Herkunft generieren

Build-Herkunft ist eine Sammlung überprüfbare Daten über einen Build.

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

Das Generieren der Build-Herkunft hilft Ihnen bei Folgendem:

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 die Build-Herkunft proaktiv zu nutzen Daten. Sie können beispielsweise Richtlinien erstellen, die nur Deployments von Code zulassen, der aus bestätigten Quellen erstellt wurde.

Für SLSA-Level 1 muss die Build-Herkunft für Verbraucher der erstellten Version verfügbar sein. Artefakte. Für SLSA-Level 2 müssen die Build-Herkunftsdaten außerdem:

Wird vom Build-Dienst generiert oder direkt aus dem Build-Dienst lesbar.
Von Verbrauchern nachprüfbar auf Authentizität und Integrität. Dies sollte mit einer digitalen Signatur erfolgen, die vom Dienst generiert wird, der die Build-Herkunftsdaten erstellt.

Für SLSA-Level 3 muss der Herkunftsinhalt auch Folgendes enthalten:

Der Einstiegspunkt der Build-Definition.
Alle Build-Parameter unter der Kontrolle eines Nutzers.

Cloud Build kann die Build-Herkunft für Container-Images generieren die für den Aufbau von SLSA-Level 3 sorgen. Weitere Informationen finden Sie unter Build-Herkunft 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 erstellen, 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. Eine sitzungsspezifische Umgebung reduziert Wartungsaufwand und reduziert Inkonsistenzen in der Build-Umgebung.

Cloud Build richtet eine neue VM-Umgebung für die und zerstört ihn 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 Mitgliedern Ihres Unternehmen.
Berechtigungen für das Dienstkonto anpassen, das im Auftrag von Cloud Build so eingerichtet werden, dass es nur die für Ihre Nutzung erforderlichen Berechtigungen hat. Berechtigungen der Standardeinstellung bearbeiten Cloud Build-Dienstkonto oder verwenden Sie ein benutzerdefinierten Dienstkonto.
Verwenden Sie die zulässigen Integrationen von Cloud Build Organisationsrichtlinie zur Steuerung der externen Dienste, die folgende Aktionen ausführen dürfen: Aufruf von Build-Triggern.
Platzieren Sie Cloud Build mithilfe von VPC Service Controls Der Perimeter ermöglicht eine freie Kommunikation zwischen Google Cloud-Diensten innerhalb des Perimeters, Kommunikation im Perimeter basierend auf von Ihnen festgelegten Regeln. 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 enthalten oft Verbindungen zu anderen Systemen, Artefaktspeicher und Bereitstellungsumgebungen. Anmeldedaten schützen, die Ihren Builds nutzen, verhindern Sie unbefugten Zugriff auf Systeme in Ihrem Softwarelieferkette und Daten-Exfiltration.

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 für In Secret Manager gespeicherte Secrets verwenden

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 überlegen, 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 Buildtools, von der Community erstellte Buildtools und benutzerdefinierte Buildtools verwenden, die Sie selbst erstellen. Sie können auch Buildpacks als Builder verwenden, darunter: 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 zum Ändern des Builds reduzieren

Es gibt viele weitere 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, die Abhängigkeiten mit Bereichen oder veränderliche Abhängigkeiten angeben (z. B. ein Image mit dem latest-Tag) Diese für Builds riskieren, dass sie fehlerhafte oder unerwünschte Versionen Abhängigkeiten.

Die folgenden Praktiken helfen, diese Risiken zu mindern:

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.
Verweisen Sie auf unveränderliche Versionen von Abhängigkeiten anstelle von Bezeichnern wie Tags, die in Zukunft auf eine andere Version des Artefakts verweisen können. Weitere Informationen zu Abhängigkeiten finden Sie unter Abhängigkeitsverwaltung:

Software Delivery Shield

Software Delivery Shield ist eine vollständig verwaltete End-to-End-Lösung für die Sicherheit der Softwarelieferkette. Sie bietet eine umfassende und modulare Reihe von Funktionen und Tools für Google Cloud-Dienste, mit denen Entwickler, DevOps- und Sicherheitsteams die Sicherheit der Softwarelieferkette verbessern können. Es zeigt Sicherheitsinformationen für erstellte Anwendungen in der Cloud Build-UI in der Google Cloud Console Dazu zählen:

Das SLSA-Level, das den Reifegrad Ihrer Software angibt Sicherheit der Lieferkette.
Sicherheitslücken, Software-Materiallisten (SBOM) und VEX-Anweisungen (Vulnerability Exploitability eXchange) für Build-Artefakte.
Build-Herkunft, d. h. eine Sammlung überprüfbarer Metadaten zu einem erstellen. 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.