Builds schützen

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

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 verschleiern: Beispielsweise parst und analysiert das Open-Source-Tool Closure Compiler JavaScript, entfernt toten Code und schreibt den Code neu und minimiert ihn. Außerdem wird der Code auf häufige Fehler in JavaScript geprüft.
  • Code in Zwischencode kompilieren: Du kannst beispielsweise Java-Code in Java-Klassendateien (.class) oder C++-Code in eine Objektdatei (.obj) kompilieren.
  • Code kompilieren und verknüpfen, Bibliothek oder ausführbare Datei erstellen, z. B. Kompilieren von C++ Code in eine gemeinsam genutzte Bibliothek (.so) oder eine ausführbare Windows-Datei (.exe).
  • Verpacken von Code in ein verteilbares oder bereitstellbares Format: Beispiele dafür sind das Erstellen von Java-WAR-Dateien (.war) aus Java-Klassendateien, ein Docker-Image oder eine Python-Distribution (.whl).

Je nach verwendeter Programmiersprache und Umgebung, in der Sie den Build erstellen, kann Ihr Build unterschiedliche Kombinationen dieser Vorgänge enthalten. Ein Build kann 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 Functions verwenden können. Sie können auch den Python-Code containerisieren und das Container-Image in Cloud Run oder Google Kubernetes Engine bereitstellen.

In diesem Dokument geht es vor allem darum, Code für die Paketerstellung oder Bereitstellung in Laufzeitumgebungen zu erstellen, anstatt Code zu kompilieren.

Automatisierte Builds verwenden

Ein automatisierter Build oder ein Skript-Build definiert alle Build-Schritte im Build-Skript oder in der Build-Konfiguration, einschließlich der Schritte zum Abrufen des Quellcodes und der Schritte zum Erstellen des Codes. Der einzige manuelle Befehl (falls vorhanden) ist der Befehl zum Ausführen des Builds.

Ein Build-Skript kann beispielsweise so aussehen:

  • Ein 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 gespeichert ist.

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

Obwohl lokale Builds für die Fehlerbehebung hilfreich sein können, kann die Freigabe von Software aus lokalen Builds eine Menge Sicherheitsbedenken, Inkonsistenzen und Ineffizienzen in den Build-Prozess mit sich bringen.

  • Wenn Sie lokale Builds zulassen, können Angreifer mit böswilliger Absicht den Build-Prozess ändern.
  • Inkonsistenzen in lokalen Entwicklungsumgebungen und in Entwicklerpraktiken erschweren die Reproduktion von Builds und die Diagnose von Build-Problemen.

Manuelle Builds machen den Prozess ineffizient, da mehr Infrastrukturressourcen wie Computing, Speicher und Netzwerke genutzt werden. In den Anforderungen für das SLSA-Framework sind automatisierte Builds für die SLSA-Level 1 erforderlich und die Verwendung eines Build-Dienstes anstelle von Entwicklungsumgebungen für Builds ist für SLSA-Level 2 erforderlich.

Cloud Build ist der verwaltete Build-Dienst in Google Cloud. Es verwendet eine Build-Konfigurationsdatei, um Build-Schritte für Cloud Build bereitzustellen. 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 Google Cloud Deploy sowie Laufzeitumgebungen wie GKE und Cloud Run eingebunden. Außerdem ist die 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.

Provenance-Metadaten enthalten Details wie die Digests der erstellten Images, die Speicherorte der Eingabequelle, die Build-Toolchain und die Build-Dauer.

Wenn Sie die Herkunft der Build-Generierung generieren, können Sie:

  • Prüfen Sie, ob ein Build-Artefakt aus einem vertrauenswürdigen Quellort und von einem vertrauenswürdigen Build-System erstellt wurde.
  • Identifizieren Sie Code, der von einem nicht vertrauenswürdigen Quellort oder Build-System eingeschleust wurde.

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

Für SLSA-Stufe 1 muss die Build-Herkunft den Nutzern der erstellten Artefakte zur Verfügung stehen. Für SLSA-Level 2 müssen die Build-Herkunftsdaten auch:

  • Wird vom Build-Dienst generiert oder direkt aus dem Build-Dienst gelesen.
  • Von einem Nutzer überprüfbar. Verwenden Sie dazu eine digitale Signatur, die vom Dienst generiert wird, der die Build-Herkunftsdaten erstellt.

Bei SLSA-Stufe 3 muss der Inhalt der Herkunft Folgendes umfassen:

  • Der Einstiegspunkt der Build-Definition.
  • Alle Build-Parameter werden vom Nutzer gesteuert.

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

Flüchtige Build-Umgebung verwenden

Sitzungsspezifische Umgebungen sind temporäre Umgebungen, die auf einen einzelnen Build-Aufruf bestehen. Nach dem Build werden die Umgebungsdaten gelöscht oder die Umgebung gelöscht. Sitzungsspezifische Builds sorgen dafür, 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 eine neue Umgebung für jeden Build bereit und zerstört diese nach Abschluss des Build-Prozesses.

Sitzungsspezifische Umgebungen sorgen für saubere Builds, da keine Restdateien oder Umgebungseinstellungen aus vorherigen Builds vorhanden sind, die den Build-Prozess beeinträchtigen können. Eine nicht sitzungsspezifische Umgebung bietet Angreifern die Möglichkeit, schädliche Dateien und Inhalte einzuschleusen. Eine sitzungsspezifische Umgebung reduziert auch den Wartungsaufwand und verringert Inkonsistenzen in der Build-Umgebung.

Cloud Build richtet eine neue virtuelle Maschinenumgebung für jeden Build ein und zerstört sie nach dem Build.

Zugriff auf den Build-Dienst einschränken

Folgen Sie dem Sicherheitsprinzip der geringsten Berechtigung, indem Sie dem Build-Dienst und den Build-Ressourcen die erforderlichen Mindestberechtigungen erteilen. Sie sollten außerdem 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 Ihrer Organisation mindestens die erforderlichen Berechtigungen.
  • 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 Standard-Cloud Build-Dienstkontos oder verwenden Sie stattdessen ein benutzerdefiniertes Dienstkonto.
  • Mit der Organisationsrichtlinie Zulässige Integrationen von Cloud Build können Sie die externen Dienste steuern, die Build-Trigger aufrufen dürfen.
  • Platzieren Sie Cloud Build mithilfe von VPC Service Controls in einem Dienstperimeter. Der Perimeter ermöglicht die kostenlose Kommunikation zwischen Google Cloud-Diensten innerhalb des Perimeters, schränkt jedoch die Kommunikation über den Perimeter basierend auf von Ihnen festgelegten Regeln ein. Außerdem verringert das Perimeter das Risiko der Daten-Exfiltration.

    Cloud Build unterstützt VPC Service Controls nur für Builds, die Sie in einem privaten Pool ausführen.

Anmeldedaten schützen

Builds enthalten häufig Verbindungen zu anderen Systemen wie Versionsverwaltung, Artefaktspeicher und Bereitstellungsumgebungen. Der Schutz von Anmeldedaten, die Sie in Ihren Builds verwenden, hilft, unbefugte Zugriffe auf Systeme in Ihrer Softwarelieferkette und Daten-Exfiltration zu verhindern.

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

In Google Cloud speichert Secret Manager API-Schlüssel, Passwörter und andere sensible Daten sicher. 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 von der Integrität des von Ihnen entwickelten Codes und von den verwendeten Abhängigkeiten ab. Sie müssen außerdem 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 zum Abhängigkeitsmanagement finden Sie unter Abhängigkeiten verwalten.

In Cloud Build verwenden Sie Cloud-Builder, um Befehle auszuführen. Builder sind Container-Images, in denen gängige Sprachen und Tools installiert sind. Sie können öffentliche Container-Images aus öffentlichen Registrys wie Docker Hub, von Cloud Build bereitgestellten Buildern, von der Community zur Verfügung gestellten Buildern und von Ihnen erstellten benutzerdefinierten Builder verwenden. Sie können auch Buildpacks als Builder verwenden, einschließlich Google Cloud-Buildpacks.

Prüfen Sie die Builder, die Sie in Ihren Cloud Build-Builds verwenden, um herauszufinden, wer sie bereitstellt, und entscheiden Sie, ob Sie ihnen in der 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 eine Vielzahl anderer Faktoren, die sich auf den Build auswirken können, darunter:

  • Builds, die gleichzeitig ausgeführt werden und sich gegenseitig beeinflussen können, oder ein Build, der bestehen bleibt und einen nachfolgenden Build beeinträchtigt.
  • Builds, die außer dem Build-Einstiegspunkt und dem Quellspeicherort der obersten Ebene Nutzerparameter akzeptieren.
  • Builds, die Abhängigkeiten mit Bereichen oder änderbare Abhängigkeiten angeben, z. B. mit einem Image mit dem Tag latest. Bei diesen Ansätzen besteht das Risiko, dass bei Builds fehlerhafte oder unerwünschte Versionen von Abhängigkeiten verwendet werden.

So verringern Sie die Risiken:

  • Führen Sie jeden Build in einer sitzungsspezifischen Umgebung aus.
  • Führen Sie keine Builds mit zusätzlichen Parametern aus, damit Nutzer die in den Build-Skripts 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 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.

Best Practices für Containererstellung

In den Best Practices zum Erstellen von Containern erfahren Sie, wie Sie Container-Images erstellen, die zuverlässiger und weniger anfällig für Angriffe sind. Dazu gehören:

  • Verpacken einzelner Anwendungen
  • Prozesse verarbeiten
  • Docker-Cache für Builds optimieren
  • Entfernen Sie unnötige Tools und halten Sie Ihre Bilder so klein wie möglich.
  • Mit Container Analysis nach Sicherheitslücken suchen. Sie können Images, die in Artifact Registry gespeichert sind, oder lokal scannen, bevor Sie sie speichern.
  • Best Practices für das Tagging
  • Sicherheitsüberlegungen zur Verwendung öffentlicher Images

Software Delivery Shield

Software Delivery Shield ist eine vollständig verwaltete End-to-End-Sicherheitslösung für die Softwarelieferkette. Es bietet umfassende und modulare Funktionen und Tools für alle Google Cloud-Dienste, die Entwickler, DevOps und Sicherheitsteams nutzen können, um den Sicherheitsstatus der Softwarelieferkette zu verbessern. Hier werden Sicherheitsstatistiken für erstellte Anwendungen in der Cloud Build-UI in der Google Cloud Console angezeigt. Dazu zählen:

  • SLSA-Level, der den Reifegrad Ihrer Softwarelieferkette angibt.
  • Sicherheitslücken in Build-Artefakten.
  • Build-Herkunft, d. h. eine Sammlung von überprüfbaren Metadaten zu einem Build. Sie enthält Details wie die Digests der erstellten Images, die Speicherorte der Eingabequelle, die Build-Toolchain, Build-Schritte und die Build-Dauer.

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

Nächste Schritte