Absicherung von Builds

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, z. B. das Open-Source-Tool von Google Closure Compiler parst und analysiert JavaScript, entfernt veralteten Code und schreibt den Rest um und minimiert ihn. Außerdem wird geprüft, den Code für häufig auftretende JavaScript-Fallstricke.
  • 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 einem verteilbaren oder bereitstellbaren Format verpacken: Beispiele: Erstellen von Java WAR-Dateien (.war) aus Java-Klassendateien, Erstellen eines Docker-Images oder Erstellen einer von Python erstellten Distribution (.whl)

Je nach verwendeter Programmiersprache und Umgebung, in der Sie die Bereitstellung vornehmen, kann Ihr Build verschiedene Kombinationen dieser Vorgänge enthalten. Für kann ein Build Python-Code in eine integrierte Distribution verpacken und in einen Artefaktspeicher wie Artifact Registry hochladen oder PyPI, damit Sie es als Abhängigkeit in einem Cloud Functions. Sie können den Python-Code auch containerisieren und bereitstellen, um das Container-Image zu Cloud Run oder zur Google Kubernetes Engine zu übertragen.

Bei den Best Practices in diesem Dokument geht es um die Erstellung von Code für die Verpackung oder in Laufzeitumgebungen zu implementieren, anstatt Code zu kompilieren.

Automatisierte Builds verwenden

Alle Build-Schritte im Build-Skript werden durch einen automatisierten Build oder einen scriptbasierten Build definiert. oder eine Build-Konfiguration, einschließlich Schritten zum Abrufen des Quellcodes und um den Code zu erstellen. Der einzige manuelle Befehl (falls vorhanden) ist der Befehl zum Ausführen des erstellen.

Ein Build-Script kann beispielsweise so aussehen:

  • Ein cloudbuild.yaml von Cloud Build.
  • 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 um Builds in einer einheitlichen, vertrauenswürdigen Umgebung auszuführen.

Obwohl lokale Builds zur Fehlerbehebung hilfreich sein können, von lokalen Builds können viele Sicherheitsbedenken, Inkonsistenzen und Ineffizienzen in den Build-Prozess einbauen.

  • Das Zulassen lokaler Builds bietet Angreifern mit böswilligen Absichten die Möglichkeit, um den Build-Prozess zu ä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 Infrastruktur genutzt wird etwa Rechenressourcen, Speicher und Netzwerke. Im Anforderungen an das SLSA-Framework erfüllen, sind automatisierte Builds Anforderung für SLSA-Level 1 und Verwendung eines Build-Dienstes anstelle des Entwicklers Umgebungen für Builds ist eine Voraussetzung für SLSA-Level 2.

Cloud Build ist der verwaltete Build-Dienst auf Google Cloud Dabei wird eine Build-Konfigurationsdatei verwendet, um einen Build bereitzustellen. Schritte zu Cloud Build. 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 Integration mit wichtigen Quellcodes. 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 Speicherorte der Eingabequellen, 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 erstellt wurde, und durch ein vertrauenswürdiges Build-System.
  • Identifizieren Sie Code, der aus 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 die Bereitstellung von Code aus verifizierten Quellen erstellt.

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 nun mit einer digitalen Signatur, die von dem Dienst generiert wurde, der den Build erstellt Herkunftsdaten.

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

Eine sitzungsspezifische Build-Umgebung verwenden

Sitzungsspezifische Umgebungen sind temporäre Umgebungen, einen einzelnen Build-Aufruf erstellen. Nach dem Build wird die Umgebung gelöscht. Sitzungsspezifische Builds stellen sicher, dass der Build-Dienst und die Build-Schritte in einer sitzungsspezifischen Umgebung wie einem Container oder einer VM ausgeführt werden. Anstatt mehrere in einer vorhandenen Build-Umgebung erstellt, stellt der Build-Dienst eine neue Umgebung bereit. für jeden Build und zerstört ihn nach Abschluss des Build-Prozesses.

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

Mit Cloud Build wird eine neue VM-Umgebung für und zerstört ihn nach dem Build.

Zugriff auf den Build-Dienst einschränken

Sicherheitsprinzip der geringsten Berechtigung befolgen, indem Sie das Prinzip der geringsten Berechtigung gewähren erforderliche Berechtigungen für den Build-Dienst und Build-Ressourcen. Sie sollten nutzen nicht-menschliche Identitäten, um Builds auszuführen und mit anderen im Auftrag des Builds erstellt.

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. Die und das Risiko der Daten-Exfiltration verringern.

    Cloud Build unterstützt VPC Service Controls nur für Builds, die Sie 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.

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

In Google Cloud: Secret Manager sicher API-Schlüssel, Passwörter und andere sensible Daten speichern. Sie können Cloud Build für In Secret Manager gespeicherte Secrets verwenden

Abhängigkeiten verwalten

Die Integrität Ihrer Anwendungen hängt von der Integrität des Codes ab, die Sie entwickeln und welche Abhängigkeiten Sie verwenden. Sie müssen auch berücksichtigen, veröffentlichen Sie Ihre Abhängigkeiten, die Lese- und Schreibzugriff auf Ihre Artefakt-Repositories 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 führen Sie mithilfe von Cloud-Buildern . Builder sind Container-Images mit gängigen Sprachen und Tools installiert haben. Sie können öffentliche Container-Images aus öffentlichen Registries verwenden wie Docker Hub, von Cloud Build bereitgestellte Builder, von der Community bereitgestellte und von Ihnen erstellte, benutzerdefinierte Builder. 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, herausfinden, von wem sie stammen, und entscheiden, ob Sie ihnen die Software anvertrauen. Lieferkette. Um mehr Kontrolle über den Code in einem Builder zu haben, können Sie Erstellen Sie benutzerdefinierte Builder, anstatt Builder zu verwenden. öffentlich zugänglich sind.

Weniger Möglichkeiten zum Ändern des Builds

Es gibt viele weitere Faktoren, die einen Build beeinflussen können, darunter:

  • Builds, die gleichzeitig ausgeführt werden und sich gegenseitig beeinflussen können, bleiben und sich auf einen nachfolgenden Build auswirken.
  • Builds, die andere Nutzerparameter als den Build-Einstiegspunkt und den Quellspeicherort auf oberster Ebene.
  • Builds, die Abhängigkeiten mit Bereichen oder Abhängigkeiten angeben, die änderbar, z. B. durch Verwendung eines Images mit dem Tag latest. Diese für Builds riskieren, dass sie fehlerhafte oder unerwünschte Versionen Abhängigkeiten.

Die folgenden Praktiken helfen, diese Risiken zu mindern:

Software Delivery Shield

Software Delivery Shield ist ein vollständig verwaltete End-to-End-Sicherheitslösung für die Softwarelieferkette. Es bietet eine umfassendes und modulares Angebot an Funktionen und Tools Google Cloud-Dienste, die Entwickler, DevOps und Sicherheitsteams nutzen können um den Sicherheitsstatus der Softwarelieferkette zu verbessern. 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 Stücklisten (SBOM) und Sicherheitslücken VEX-Anweisungen (Exploitability eXchange) für Build-Artefakte.
  • Build-Herkunft, d. h. eine Sammlung überprüfbarer Metadaten zu einem erstellen. Es enthält Details wie die Digests der erstellten Images, Speicherorte der Eingabequellen, die Build-Toolchain, die Build-Schritte und die Build-Dauer.

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

Nächste Schritte