In diesem Dokument werden Best Practices für die Verwaltung von Software-Quellcode beschrieben.
Ein grundlegender Schritt, den Softwareteams zur Verwaltung ihrer Quelle unternehmen, ist die Einführung eines Versionskontrollsystems (VCS). Versionskontrollsysteme bieten einen Verlauf und eine Überprüfbarkeit von Änderungen. Gehostete Versionskontrollsysteme wie GitHub bieten zusätzliche Vorteile wie Verfügbarkeit, Stabilität, Sicherheitskontrollen, integrierte Codeüberprüfungstools und Integration in andere Cloud-Dienste.
Die meisten Teams nutzen heute Versionskontrolle. Es gibt jedoch viele Möglichkeiten, ein Versionskontrollsystem und seine Integration in andere Teile der CI/CD-Pipeline zu konfigurieren.
In diesem Dokument werden Sicherheitsaspekte der Softwarelieferkette für die Konfiguration eines Versionskontrollsystems untersucht. Es werden Best Practices aus Supply Chain Levels for Software Artifacts beschrieben, einem Framework zum Schutz Ihrer Softwarelieferkette. Das Framework enthält Anforderungen auf mehreren Ebenen, die Ihnen helfen, Änderungen schrittweise umzusetzen, einschließlich Anforderungen an die Quelle.
Ein Versionskontrollsystem mit Änderungsverlauf und unveränderlichen Überarbeitungen ist eine Anforderung der SLSA-Ebene 2. Wir empfehlen, als Ausgangspunkt für Ihre Softwarelieferkette die Ausrichtung auf SLSA-Ebene 2.
Auf SLSA-Level 3 müssen Quell- und Build-Plattformen strengere Sicherheitsanforderungen erfüllen, einschließlich eines bestätigten Quellverlaufs und einer Richtlinie zur Aufbewahrung von Quellen. Bei SLSA-Level 4 werden den Quellanforderungen noch Prüfungen durch zwei Personen hinzugefügt.
Versionskontrolle nicht nur für die Anwendungsquelle verwenden
Das Speichern der Anwendungsquelle in der Versionsverwaltung ist eine bewährte Praxis, wenn bisherige Überprüfungen und Prüfungen erforderlich sind. Es gibt jedoch auch andere Arten von Quellen, die von der Versionskontrolle profitieren, z. B. Konfigurations-, Richtlinien- und Datenquellen. Dazu gehören Dateien, die:
- Auswirkungen auf die Verfügbarkeit und Sicherheit Ihrer Recheninfrastruktur
- Für die Fertigstellung ist die Zusammenarbeit erforderlich
- Wiederholbarer Genehmigungsprozess erforderlich
- Änderungsverlauf anfordern
Dazu einige Beispiele:
- Infrastruktur als Code: Organisationen, die ihre Infrastruktur auf skalierbare und sichere Weise verwalten möchten, verwenden Infrastruktur als Code als eine wichtige Methode. Sie können beispielsweise Terraform-Module in der Versionskontrolle speichern, die Artifact Registry-Repositories erstellen.
- Konfigurationsverwaltung: Die Konfigurationsverwaltung ähnelt der Infrastruktur-as-Code-Methode, konzentriert sich jedoch auf die Verwaltung der Anwendungskonfiguration mit Tools wie Ansible, Puppet und Chef. Sie speichern und verwalten Anwendungskonfigurationsdateien in Ihrem Versionskontrollsystem.
- Datenbankkonfigurationen und Migrationsscripts: Speichern Sie die Konfiguration und Scripts sowohl für Ihre Produktdatenbanken als auch für Analyse- oder Protokollierungsdatenbanken.
- Jupyter-Notebooks: Es gibt verschiedene Möglichkeiten, mit in GitHub gespeicherten Notebooks zu arbeiten, darunter die Erweiterung für JupyterLab, Colaboratory und Vertex AI Workbench.
- Sicherheitsrichtlinien: Speichern von Richtliniendateien für die automatisierte Richtlinienerzwingung. Sie können beispielsweise Gatekeeper-Richtlinien speichern, die das Bereitstellungsverhalten in GKE zulassen oder ablehnen, oder Sentinel-Richtlinien, die verhindern, dass Terraform eine Infrastruktur bereitstellt, die gegen Richtlinien verstößt.
Die Versionsverwaltung ist eine der technischen Funktionen, die in der DORA-DevOps-Forschung identifiziert wurden und zu einer besseren Softwarebereitstellung und einer höheren Unternehmensleistung beitragen. Wenn Sie Ihre Scripts, Ihren Quellcode und Ihre Konfigurationsdateien in der Versionskontrolle speichern, können Sie Umgebungen reproduzieren und wiederherstellen, Änderungen nachverfolgen und prüfen sowie schnell auf Fehler reagieren.
Repository-Konfiguration
Repositories sind die grundlegende logische Einheit zum Organisieren von Code und zugehörigen Rollen, Berechtigungen, Integrationen und Genehmigungen.
Bei der Repository-Konfiguration können folgende Probleme auftreten:
- Die Repository-Konfiguration ist nicht standardisiert. Daher ist es schwierig, dafür zu sorgen, dass die Repository-Sicherheit für die entsprechende Anwendung geeignet ist. Das gilt insbesondere für den häufigen Fall, dass eine Organisation Hunderte oder Tausende von Repositories hat.
- Der Nutzer, der das Repository erstellt, wird zum Inhaber mit vollen Administratorberechtigungen, einschließlich der Möglichkeit, Zusammenführungen ohne andere Prüfer durchzuführen.
- Die Einbindung von Repositories in Codeanalysen, Build-Server, Issue-Tracker, Benachrichtigungsdienste und andere Teile der CI/CD-Infrastruktur kann viel Arbeit erfordern. Eine Standardmethode zum Erstellen und Einrichten von Repositories erspart sich wiederkehrende Arbeit und unterstützt Best Practices.
Best Practices zur Behebung dieser Probleme:
- Repositories mit einem automatisierten, wiederholbaren und sicherheitsbewussten Prozess einrichten Sie können beispielsweise Terraform-Module einrichten, die die Sicherheitsanforderungen der Anwendung berücksichtigen, für die das Repository bestimmt ist. Für Anwendungen mit hoher Sicherheit sind mehr und andere Genehmiger für die Zusammenführung erforderlich als für Apps mit geringerer Sicherheit.
- Repository-Administratoren sollen aus einer Reihe von Repository-Konfigurationsvorlagen auswählen können, die die Einrichtung neuer Repositories unterstützen, anstatt jedes Repository von Grund auf neu zu konfigurieren. Diese Vorlagen sollten die verschiedenen Sicherheitsebenen Ihrer Anwendungen widerspiegeln und mit den Nutzeridentitäten synchronisiert werden, die für jede Sicherheitsebene erforderlich sind. In der Praxis bedeutet das in der Regel die Verwendung eines hierarchischen IAM-Systems (Identity and Access Control), das die Anwendungen und die Infrastruktur in Ihrer Organisation sowie die dafür verantwortlichen Nutzer widerspiegelt.
- Erforderliche zentrale Identitätsverwaltung mit Multi-Faktor-Authentifizierung für Repository-Nutzer.
- Durch die zentrale Identitätsverwaltung wird sichergestellt, dass Sie bei der Quellverwaltung die geringsten Berechtigungen beibehalten, wenn Nutzer die Organisation verlassen oder zu neuen Teams wechseln.
- Die Multi-Faktor-Authentifizierung reduziert das Risiko von Phishing und anderen Arten von Angriffen auf Ihre Quelle erheblich. Die Bestätigung in zwei Schritten ist eine der Anforderungen der SLSA-Ebene 4 für Codegenehmiger.
- Beschränken Sie die Repository-Inhaber auf eine kleine Anzahl vertrauenswürdiger Mitarbeiter. Möglicherweise müssen Sie die Versionskontrolle in ein Identitätsverwaltungssystem einbinden und die Möglichkeit zum Festlegen von Richtlinien in der Organisation höher ansiedeln. Entfernen Sie nach Möglichkeit die Möglichkeit für Repository-Inhaber, Zusammenführungen ohne einen zweiten Prüfer durchzuführen.
Code Review
Codeüberprüfungen sind die wichtigste Methode, mit der Organisationen die Qualität und Sicherheit ihrer Software aufrechterhalten. Bei der Codeüberprüfung werden verschiedene Fehlermodi berücksichtigt, z. B.:
- Einführung von Code mit Softwarefehlern oder einem starren Design.
- Schlecht definierte APIs
- Sicherheitsprobleme aufgrund von unsicherem Code, der vom Entwickler geschrieben wurde
- Sicherheitsprobleme durch das Hinzufügen von unsicheren oder potenziell unsicheren Drittanbieterbibliotheken
So können Sie das Risiko minimieren:
- Implementieren Sie Testautomatisierung während des gesamten Softwarelebenszyklus. Automatisierte Tests, die ausgelöst werden, wenn Sie die Quelle in das Versionskontrollsystem einchecken, sind eine Möglichkeit für Entwickler, schnell Feedback zu den bei den Tests gefundenen Problemen zu erhalten.
- Die Anzahl und Identität der Prüfer muss dem Sicherheitsniveau der Anwendung entsprechen. So gelten für eine Intranet-App mit geringer Nutzung beispielsweise geringere Sicherheitsanforderungen als für eine öffentlich zugängliche geschäftskritische Anwendung.
- Weisen Sie Prüfer sowohl aufgrund ihres technischen Fachwissens als auch des für die Änderung im Commit erforderlichen Vertrauensniveaus zu. Der Prüfer sollte ein Experte für die zu prüfende Sprache, die Systeme, mit denen der Code interagiert, und die Sicherheitsrisiken in dieser Anwendungsklasse sein. Die Anforderung an das technische Know-how hat viele Dimensionen. Beispiel:
- Ist der Code lesbar?
- Ist es sicher?
- Werden geeignete Drittanbieterbibliotheken verwendet?
- Gibt es ein Verfahren zur Sicherung von Bibliotheken von Drittanbietern?
- Ist der Code kombinierbar?
- Werden beim API-Design Best Practices berücksichtigt?
Bewertungen sollten kein bürokratischer Schritt, sondern ein fortlaufendes Gespräch über Best Practices sein. Erstellen Sie Checklisten, Styleguides und Designstandards für jeden Teil Ihres Technologie-Stacks sowie Bildungsprogramme für neue Entwickler. Einige IDEs wie VS Code und IntelliJ bieten Linter, die programmatische oder stilistische Fehler automatisch melden können. Lint-Tools helfen Entwicklern, einheitlicheren Code zu erstellen, und ermöglichen es Codeprüfern, sich stärker auf Probleme zu konzentrieren, die mit automatisierten Prüfungen nicht leicht zu erkennen sind.
Developing Secure Software ist ein kostenloser Onlinekurs, der von der Open Source Security Foundation (OpenSSF) entwickelt wurde. Es beschreibt grundlegende Praktiken der Softwareentwicklung im Kontext der Sicherheit der Softwarelieferkette.
Führen Sie Codeüberprüfungen mit Pull-Anfragen für Feature-Branches durch, sobald ein einzelner Entwickler bereit ist. Warten Sie nicht bis kurz vor dem Test eines neuen Releases, um Sicherheitsprüfungen und Codeüberprüfungen durchzuführen.
Wenn Sie das Scannen auf Sicherheitslücken, einschließlich des Scannens auf Bibliotheken von Drittanbietern, in Pull-Requests und IDEs einbinden, können Probleme so schnell wie möglich erkannt werden. Mit der On-Demand Scanning API in Google Cloud können Sie Container lokal auf Sicherheitslücken prüfen.
Integrieren Sie automatisierte Tests vor dem Zusammenführen, damit Entwickler Änderungen erkennen und korrigieren können, die die Anwendung beeinträchtigen. Weitere Informationen zur Testautomatisierung
Genehmigungen zusammenführen
In kontinuierlich integrierten CI/CD-Pipelines kann das Zusammenführen von Code in einen Produktionszweig zu nachgeschalteten Änderungen führen, einschließlich automatisiertem Build und Roll-out. Aus diesem Grund ist es ein wichtiger Bestandteil der Sicherheit von Softwarebereitstellungen, zu steuern, wer Zusammenführungen ausführen darf. Folgende Punkte gehören dazu:
- Richten Sie geschützte Branch-Inhaber in Ihren Produktions-Branchen ein. Die Anzahl und Identität der Personen, die eine Zusammenführung vornehmen dürfen, sollte den Sicherheitsanforderungen der Anwendung entsprechen. Für SLSA-Ebene 4 sind zwei stark authentifizierte Genehmiger erforderlich. Die Anzahl der Genehmiger sollte jedoch dem Inhalt des Repositories angemessen sein.
- Identitäten von Repository-Inhabern genau steuern, da sie in den meisten Versionskontrollsystemen Zusammenführungen selbst ausführen können.
- Separate Bereitstellungs- und Genehmigungsverfahren für Rollouts mit mehreren Repositories und mehreren Artefakten.
Tools zur sicheren Entwicklung
Google Cloud bietet eine Reihe modularer Funktionen und Tools, mit denen Sie die Sicherheit Ihrer Softwarelieferkette verbessern können. Die folgenden Komponenten tragen zum Schutz des Software-Quellcodes bei:
Cloud Workstations (Vorabversion)
Cloud Workstations bietet vollständig verwaltete Entwicklungsumgebungen in Google Cloud. Es ermöglicht IT- und Sicherheitsadministratoren, ihre Entwicklungsumgebungen ganz einfach bereitzustellen, zu skalieren, zu verwalten und zu schützen. Außerdem können Entwickler mit einheitlichen Konfigurationen und anpassbaren Tools auf Entwicklungsumgebungen zugreifen.
Cloud Workstations trägt dazu bei, die Sicherheit zu verlagern, indem die Sicherheitslage Ihrer Entwicklungsumgebungen verbessert wird. Sie bietet Sicherheitsfunktionen wie VPC Service Controls, privaten eingehenden und ausgehenden Traffic, erzwungene Image-Updates und IAM-Zugriffsrichtlinien. Weitere Informationen finden Sie in der Cloud Workstations-Dokumentation.
Cloud Code-Quellschutz (Vorabversion)
Cloud Code bietet IDE-Unterstützung zum Erstellen, Bereitstellen und Einbinden von Anwendungen in Google Cloud. Damit können Entwickler eine neue Anwendung aus Beispielvorlagen erstellen und anpassen sowie die fertige Anwendung ausführen. Cloud Code Source Protect bietet Entwicklern Echtzeit-Sicherheitsfeedback, z. B. die Identifizierung anfälliger Abhängigkeiten und Lizenzberichte, während sie in ihren IDEs arbeiten. Sie liefert schnelles und umsetzbares Feedback, mit dem Entwickler zu Beginn des Softwareentwicklungsprozesses Korrekturen an ihrem Code vornehmen können.
Verfügbarkeit der Funktion: Der Cloud Code-Quellcodeschutz ist nicht für den öffentlichen Zugriff verfügbar. Informationen zum Zugriff auf diese Funktion finden Sie auf der Seite Zugriffsanfrage.
Nächste Schritte
- Best Practices zum Schutz von Builds
- Best Practices zum Schutz von Abhängigkeiten
- Best Practices für die Sicherheit von Bereitstellungen