In diesem Dokument werden Best Practices für die Verwaltung von Software-Quellcode beschrieben.
Ein grundlegender Schritt, den Softwareteams zur Verwaltung ihres Quellcodes unternehmen, ist die Einführung eines Versionsverwaltungssystems. Versionsverwaltungssysteme bieten einen Verlauf und die Prüfbarkeit von Änderungen. Gehostete Versionsverwaltungssysteme wie GitHub bieten zusätzliche Vorteile wie Verfügbarkeit, Stabilität, Sicherheitskontrollen, integrierte Tools für die Codeüberprüfung und die Integration mit anderen Clouddiensten.
Die meisten Teams verwenden heute die Versionsverwaltung. Es gibt jedoch viele Möglichkeiten, ein Versionsverwaltungssystem und seine Integrationen mit anderen Teilen der CI/CD-Pipeline zu konfigurieren.
In diesem Dokument werden die Sicherheitsaspekte der Softwarelieferkette für die Konfiguration eines Versionsverwaltungssystems untersucht. Es werden Best Practices aus Supply-chain Levels for Software Artifacts, einem Framework zum Schutz Ihrer Softwarelieferkette beschrieben. Das Framework enthält Anforderungen auf mehreren Ebenen, damit Sie Änderungen schrittweise implementieren können, einschließlich der Anforderungen an die Quelle.
Ein Versionsverwaltungssystem mit Änderungsverlauf und unveränderlichen Überarbeitungen ist eine Anforderung von SLSA-Ebene 2. Wir empfehlen, sich an SLSA-Ebene 2 zu orientieren, da dies eine gute Ausgangsbasis für Ihre Softwarelieferkette ist.
Auf SLSA-Ebene 3 erfüllen Quell- und Build-Plattformen strengere Sicherheits anforderungen, einschließlich eines überprüften Quellverlaufs und einer Richtlinie zur Quellaufbewahrung. Auf SLSA-Ebene 4 werden den Anforderungen an die Quelle Überprüfungen durch zwei Personen hinzugefügt.
Versionsverwaltung für mehr als nur den Quellcode Ihrer Anwendung verwenden
Die Speicherung von Anwendungsquellcode in der Versionsverwaltung ist eine etablierte Methode, wenn historische Überprüfungen und Audits erforderlich sind. Es gibt jedoch auch andere Arten von Quellcode, die von der Versionsverwaltung profitieren, darunter Konfiguration, Richtlinien und Daten. Dazu gehören alle Dateien, die:
- die Verfügbarkeit und Sicherheit Ihrer Compute-Infrastruktur beeinträchtigen
- für die Fertigstellung eine Zusammenarbeit erfordern
- einen wiederholbaren Genehmigungsprozess erfordern
- einen Änderungsverlauf erfordern
Dazu einige Beispiele:
- Infrastructure as Code: Unternehmen, die ihre Infrastruktur skalierbar und sicher verwalten möchten, verwenden Infrastructure as Code als Schlüsselmethode. Sie können beispielsweise Terraform-Module in der Versions verwaltung speichern, die Artifact Registry-Repositories erstellen.
- Konfigurationsverwaltung: Die Konfigurationsverwaltung ähnelt Infrastructure as Code, konzentriert sich aber auf die Verwaltung der Anwendungskonfiguration mit Tools wie Ansible, Puppet und Chef. Sie speichern und verwalten Anwendungskonfigurationsdateien in Ihrem Versionsverwaltungssystem.
- Datenbankkonfigurationen und Migrationsskripts: Speichern Sie die Konfiguration und die Skripts für Ihre Produktdatenbanken sowie für Analyse- oder Logging Datenbanken.
- Jupyter-Notebooks: Es gibt verschiedene Möglichkeiten, mit in GitHub gespeicherten Notebooks zu arbeiten, einschließlich der Erweiterung für JupyterLab, Colaboratory und Vertex AI Workbench
- Sicherheitsrichtlinien: Speichern Sie Richtliniendateien für die automatisierte Durchsetzung von Richtlinien. Sie können beispielsweise Gatekeeper-Richtlinien speichern, die das Bereitstellungsverhalten in GKE zulassen oder ablehnen oder Sentinel-Richtlinien, die verhindern, dass Terraform Infrastruktur bereitstellt, die gegen Richtlinien verstößt.
Die Versionsverwaltung ist eine der technischen Funktionen, die in der DORA DevOps-Studie ermittelt wurden und die die Softwarebereitstellung und die Leistung verbessern. Wenn Sie Ihre Skripts, Ihren Quellcode und Ihre Konfigurationsdateien in der Versionsverwaltung 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 für die Organisation von Code und zugehörigen Rollen, Berechtigungen, Integrationen und Genehmigungen.
Probleme, die bei der Repository-Konfiguration auftreten können, sind:
- Die Repository-Konfiguration ist nicht standardisiert. Daher ist es schwierig, sicherzustellen, dass die Repository-Sicherheit für die Anwendung geeignet ist, die sie darstellt. Dies gilt insbesondere für das häufige Szenario, in dem ein Unternehmen Hunderte oder Tausende von Repositories hat.
- Wer das Repository erstellt, wird Inhaber mit vollständigen Administratorberechtigungen, einschließlich der Möglichkeit, Zusammenführungen ohne weitere Prüfer durchzuführen.
- Die Integration von Repositories mit Codeanalysen, Build-Servern, Issue-Trackern, Benachrichtigungsdiensten und anderen Teilen der CI/CD-Infrastruktur kann sehr aufwendig sein. Eine Standardmethode zum Erstellen und Einrichten von Repositories spart wiederholte Arbeit und unterstützt Best Practices.
Um diese Probleme zu beheben, sollten Sie folgende Best Practices anwenden:
- Richten Sie Repositories mit einem automatisierten, wiederholbaren und sicherheitsbewussten Prozess ein. Sie können beispielsweise Terraform-Module einrichten, die die Sicherheitsanforderungen der Anwendung enthalten, für die das Repository bestimmt ist. Anwendungen mit hoher Sicherheit erfordern mehr und andere Genehmiger für die Zusammenführung als Anwendungen mit geringerer Sicherheit.
- Repository-Administratoren sollten aus einer Reihe von Vorlagen für die Repository-Konfiguration auswählen können, die die Einrichtung neuer Repositories ermöglichen, anstatt jedes Repository von Grund auf zu konfigurieren. Diese Vorlagen sollten die verschiedenen Sicherheitsstufen Ihrer Anwendungen widerspiegeln und mit den Nutzeridentitäten synchronisiert werden, die für jede Sicherheitsstufe erforderlich sind. In der Praxis bedeutet dies in der Regel die Verwendung eines hierarchischen Systems für die Identitäts- und Zugriffssteuerung (Identity and Access Management, IAM) das die Anwendungen und die Infrastruktur in Ihrem Unternehmen sowie die dafür verantwortlichen Nutzer widerspiegelt.
- Erfordern Sie eine zentrale Identitätsverwaltung mit Multi-Faktor-Authentifizierung für Repository-Nutzer.
- Die zentrale Identitätsverwaltung sorgt dafür, dass Sie das Prinzip der geringsten Berechtigung für die Quellcodeverwaltung beibehalten, wenn Nutzer das Unternehmen verlassen oder in neue Teams wechseln.
- Die Multi-Faktor-Authentifizierung verringert das Risiko von Phishing und anderen Arten von Angriffen auf Ihren Quellcode erheblich. Die 2-Faktor-Authentifizierung ist eine der Anforderungen von SLSA-Ebene 4 für Code-Genehmiger.
- Beschränken Sie die Anzahl der Repository-Inhaber auf eine kleine Anzahl vertrauenswürdiger Mitarbeiter. Dazu ist möglicherweise die Integration der Versionsverwaltung in ein Identitätsverwaltungssystem und die Verlagerung der Möglichkeit, Richtlinien festzulegen, auf eine höhere Ebene in der Organisation erforderlich. Entfernen Sie nach Möglichkeit die Möglichkeit für Repository-Inhaber, Zusammenführungen ohne einen zweiten Prüfer durchzuführen.
Code Review
Die Codeüberprüfung ist die wichtigste Methode, mit der Unternehmen die Qualität und Sicherheit ihrer Software gewährleisten. Bei der Codeüberprüfung werden verschiedene Fehlerarten berücksichtigt, z. B.:
- Einführung von Code mit Softwarefehlern oder einem unflexiblen Design
- Schlecht definierte APIs
- Einführung von Sicherheitsproblemen aufgrund von unsicherem Code, der vom Entwickler geschrieben wurde
- Einführung von Sicherheitsproblemen durch das Hinzufügen von Bibliotheken von Drittanbietern, die unsicher sind oder unsicher werden könnten
Einige Möglichkeiten zur Risikominimierung sind:
- Implementieren Sie die Testautomatisierung während des gesamten Softwarelebenszyklus. Automatisierte Tests, die ausgelöst werden, wenn Sie Quellcode in das Versionsverwaltungssystem übertragen, ermöglichen es Entwicklern, schnell Feedback zu Problemen zu erhalten, die bei den Tests gefunden wurden.
- Die Anzahl und Identität der Prüfer sollte dem Sicherheitsniveau der Anwendung entsprechen. Eine Intranet-App mit geringer Nutzung hat beispielsweise geringere Sicherheitsanforderungen als eine öffentlich zugängliche geschäftskritische Anwendung.
- Weisen Sie Prüfer sowohl anhand ihrer technischen Expertise als auch anhand der Vertrauensstufe zu, die für die Änderung im Commit erforderlich ist. Der Prüfer sollte ein Experte für die zu überprüfende Sprache, die Systeme, mit denen der Code interagiert, und die Sicherheitsrisiken in dieser Klasse von Anwendungen sein. Die Anforderung an die technische Expertise hat viele Dimensionen. Beispiel:
- Ist der Code lesbar?
- Ist das sicher?
- Werden geeignete Bibliotheken von Drittanbietern verwendet?
- Gibt es einen Prozess zum Schutz von Bibliotheken von Drittanbietern?
- Ist der Code zusammensetzbar?
- Entspricht das API-Design den Best Practices?
Überprüfungen sollten kein bürokratischer Schritt sein, sondern ein fortlaufendes Gespräch über Best Practices. Erstellen Sie Checklisten, Styleguides und Designstandards für jeden Teil Ihres Technologie-Stacks sowie Schulungsprogramme für neue Entwickler. Einige IDEs wie VS Code und IntelliJ bieten Linter, die programmatische oder stilistische Fehler automatisch kennzeichnen können. Linter helfen Entwicklern, konsistenteren Code zu erstellen, und ermöglichen es Code-Prüfern, sich mehr auf Probleme zu konzentrieren, die mit automatisierten Prüfungen nicht einfach zu identifizieren sind.
Developing Secure Software ist ein kostenloser Onlinekurs der Open Source Security Foundation (OpenSSF). Darin werden grundlegende Softwareentwicklungspraktiken im Kontext der Sicherheit der Softwarelieferkette beschrieben.
Führen Sie Codeüberprüfungen mit Pull-Requests für Feature-Branches durch, sobald ein einzelner Entwickler bereit ist. Warten Sie nicht bis kurz vor der Testphase einer Neuveröffentlichung, um Sicherheitsprüfungen und Code Review durchzuführen.
Durch die Integration der Überprüfung auf Sicherheitslücken, einschließlich der Überprüfung von Bibliotheken von Drittanbietern, in Pull-Requests und IDEs können Probleme so schnell wie möglich erkannt werden. Mit der On-Demand Scanning API Google Cloud können Sie Container lokal auf Sicherheitslücken scannen.
Integrieren Sie automatisierte Tests vor der Zusammenführung, damit Entwickler Änderungen erkennen und beheben können, die die Anwendung beschädigen. Weitere Informationen zur Testautomatisierung.
Genehmigungen für die Zusammenführung
In kontinuierlich integrierten CI/CD-Pipelines kann die Zusammenführung von Code in einen Produktions-Branch nachgelagerte Änderungen zur Folge haben, einschließlich automatisierter Builds und Rollouts. Daher ist es ein wichtiger Teil der Sicherung von Softwarebereitstellungen, zu kontrollieren, wer Zusammenführungen durchführen kann. Folgende Punkte gehören dazu:
- Richten Sie Inhaber für geschützte Branches in Ihren Produktions-Branches ein. Die Anzahl und Identität der Personen, die Zusammenführungen durchführen dürfen, sollten den Sicherheitsanforderungen der Anwendung entsprechen. SLSA-Ebene 4 erfordert zwei stark authentifizierte Genehmiger, aber die Anzahl der Genehmiger sollte dem Inhalt des Repository angemessen sein.
- Kontrollieren Sie die Identitäten der Repository-Inhaber genau, da sie in den meisten Versionsverwaltungssystemen Zusammenführungen selbst durchführen können.
- Trennen Sie die Prozesse für die Bereitstellung und die Genehmigung der Zusammenführung für Rollouts mit mehreren Repositories und mehreren Artefakten.
Tools zum Schutz der 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 von Software-Quellcode bei:
Cloud Workstations (Vorabversion)
Cloud Workstations bietet vollständig verwaltete Entwicklungsumgebungen in der Google Cloud. IT- und Sicherheitsadministratoren können damit ihre Entwicklungsumgebungen ganz einfach bereitstellen, skalieren, verwalten und absichern. Entwickler können auf Entwicklungsumgebungen mit konsistenten Konfigurationen und anpassbaren Tools zugreifen.
Cloud Workstations trägt dazu bei, die Sicherheit zu verbessern, indem der Sicherheitsstatus Ihrer Entwicklungsumgebungen für Anwendungen erhöht wird. Es bietet Sicherheitsfunktionen wie VPC Service Controls, privaten eingehenden oder ausgehenden Traffic, erzwungene Image-Updates und IAM-Zugriffsrichtlinien. Weitere Informationen finden Sie in der Cloud Workstations-Dokumentation.
Cloud Code Source Protect (Vorabversion)
Cloud Code bietet IDE-Unterstützung zum Erstellen, Bereitstellen und Einbinden von Anwendungen in Google Cloud. Entwickler können damit eine neue Anwendung aus Beispielvorlagen erstellen und anpassen und die fertige Anwendung ausführen. Cloud Code Source Protect gibt Entwicklern in Echtzeit Sicherheitsfeedback, z. B. die Identifizierung anfälliger Abhängigkeiten und Lizenzberichte, während sie in ihren IDEs arbeiten. Es bietet schnelles und umsetzbares Feedback, mit dem Entwickler zu Beginn des Softwareentwicklungsprozesses Korrekturen an ihrem Code vornehmen können.
Verfügbarkeit der Funktion: Cloud Code Source Protect ist nicht öffentlich zugänglich. Informationen zum Zugriff auf diese Funktion finden Sie auf der Seite Zugriffsanforderung.
Nächste Schritte
- Lernen Sie die Best Practices zum Schutz von Builds.
- Lernen Sie die Best Practices zum Schutz von Abhängigkeiten.
- Lernen Sie die Best Practices zum Schutz von Bereitstellungen.