Quelle absichern

In diesem Dokument werden Best Practices für die Verwaltung von Softwarequellcode beschrieben.

Ein grundlegender Schritt, den Softwareteams zur Verwaltung ihrer Quelle unternehmen, ist die Einführung eines Versionsverwaltungssystems (VCS). Versionsverwaltungssysteme bieten einen Verlauf und eine Nachvollziehbarkeit von Änderungen. Gehostete Versionskontrollsysteme wie GitHub bieten zusätzliche Vorteile wie Verfügbarkeit, Stabilität, Sicherheit, integrierte Tools zur Codeüberprüfung und Einbindung in andere Cloud-Dienste.

Obwohl die meisten Teams derzeit die Versionsverwaltung verwenden, gibt es viele Möglichkeiten, ein Versionsverwaltungssystem und seine Integrationen in andere Teile der CI/CD-Pipeline zu konfigurieren.

In diesem Dokument werden Sicherheitsaspekte der Softwarelieferkette für die Konfiguration eines Versionsverwaltungssystems erläutert. Darin werden Best Practices aus dem Framework Supply Chain Levels for Software Artifacts beschrieben, einem Framework zum Schutz Ihrer Softwarelieferkette. Das Framework enthält Anforderungen auf mehreren Ebenen, damit Sie Änderungen schrittweise implementieren können, einschließlich Quellanforderungen.

Ein Versionsverwaltungssystem mit Änderungsverlauf und unveränderlichen Überarbeitungen ist eine SLSA-Stufe 2-Anforderung. Wir empfehlen, sich an SLSA-Level 2 als Ausgangsbasis für Ihre Softwarelieferkette zu orientieren.

Auf SLSA-Ebene 3 erfüllen Quell- und Build-Plattformen höhere Sicherheitsanforderungen, einschließlich eines bestätigten Quellverlaufs und einer Quellaufbewahrungsrichtlinie. Bei SLSA-Level 4 werden den Anforderungen an Quellen zwei Bewertungen durch zwei Personen hinzugefügt.

Versionsverwaltung für mehr als nur den Quellcode der Anwendung verwenden

Das Speichern der Anwendungsquelle in der Versionsverwaltung ist eine bewährte Praxis, wenn Verlaufsprüfungen und Audits erforderlich sind. Es gibt jedoch auch andere Arten von Quellen, die von der Versionsverwaltung profitieren, darunter Konfiguration, Richtlinien und Daten. Dazu gehören alle Dateien, die:

Auswirkungen auf die Verfügbarkeit und Sicherheit Ihrer Computing-Infrastruktur
Zusammenarbeit vor Abschluss erforderlich
Wiederholbaren Genehmigungsprozess verlangen
Änderungsverlauf verlangen

Dazu einige Beispiele:

Infrastruktur als Code: Organisationen, die ihre Infrastruktur auf skalierbare und sichere Weise verwalten möchten, verwenden Infrastruktur als Code als Schlüsselmethode. Beispielsweise können Sie Terraform-Module in der Versionsverwaltung speichern, die Artifact Registry-Repositories erstellen.
Konfigurationsverwaltung: Die Konfigurationsverwaltung ähnelt der Infrastruktur als Code, konzentriert sich jedoch 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 Skripts für Ihre Produktdatenbanken und Analyse- oder Logging-Datenbanken.
Jupyter-Notebooks: Es gibt verschiedene Möglichkeiten, mit in GitHub gespeicherten Notebooks zu arbeiten, darunter die [Erweiterung für JupyterLab][jlab], Colaboratory und [Vertex AI Workbench][vertex].
Sicherheitsrichtlinien: Speichern von Richtliniendateien für die automatisierte Richtlinienerzwingung. Sie können beispielsweise Gatekeeper-Richtlinien speichern, die Bereitstellungsverhalten in GKE zulassen oder ablehnen, oder Sentinel-Richtlinien, die verhindern, dass Terraform richtlinienwidrige Infrastruktur bereitstellt.

Die Versionsverwaltung ist eine der technischen Funktionen, die in der DORA-DevOps-Studie ermittelt wurden und zu einer höheren Softwarebereitstellung und höheren Unternehmensleistung führen sollen. Wenn Sie Ihre Skripts, Quellcodes und Konfigurationsdateien in der Versionsverwaltung speichern, können Sie Umgebungen reproduzieren und wiederherstellen, Änderungen verfolgen 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 unter anderem folgende Probleme auftreten:

Da die Repository-Konfiguration nicht standardisiert ist, kann es schwierig sein, dafür zu sorgen, dass die Repository-Sicherheit für die Anwendung angemessen ist, insbesondere in dem häufigen Szenario, in dem eine Organisation Hunderte oder Tausende von Repositories hat.
Die Person, die das Repository erstellt, wird Inhaber mit vollständigen Administratorberechtigungen, einschließlich der Möglichkeit, Zusammenführungen mit keinen anderen Prüfern durchzuführen.
Die Einbindung von Repositories in Codeanalysen, Build-Server, Problemverfolgungsdienste, Benachrichtigungsdienste und andere Teile der CI/CD-Infrastruktur kann aufwendig sein. Eine Standardmethode zum Erstellen und Einrichten von Repositories spart sich wiederholende Arbeiten und unterstützt Best Practices.

Um diese Probleme zu lösen, umfassen Best Practices

Richten Sie Repositories mit einem automatisierten, wiederholbaren, sicherheitsbewussten Prozess ein. Beispielsweise können Sie 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.
Schaffen Sie eine Möglichkeit, mit der Repository-Administratoren aus einer Reihe von Konfigurationsvorlagen für das neue Repository auswählen können, 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 die einzelnen Sicherheitsstufen erforderlich sind. In der Praxis bedeutet dies in der Regel, dass ein hierarchisches Identitäts- und Zugriffssteuerungssystem (IAM) verwendet wird, das die Anwendungen und Infrastruktur in Ihrer Organisation und die Nutzer abbildet, die für sie verantwortlich sind.
Verlangen Sie für Repository-Nutzer eine zentralisierte Identitätsverwaltung mit Multi-Faktor-Authentifizierung.
- Die zentralisierte Identitätsverwaltung sorgt dafür, dass Sie die geringsten Berechtigungen für die Quellenverwaltung haben, wenn Nutzer die Organisation verlassen oder in neue Teams wechseln.
- Die Multi-Faktor-Authentifizierung reduziert das Risiko von Phishing und anderen Angriffen auf Ihre Quelle erheblich. Die 2-Faktor-Authentifizierung ist eine der SLSA-Level 4-Anforderungen für Code-Genehmiger.
Beschränken Sie Repository-Inhaber auf eine kleine Anzahl vertrauenswürdiger Mitarbeiter. Dazu kann es erforderlich sein, die Versionsverwaltung in ein Identitätsverwaltungssystem zu integrieren und die Möglichkeit zu schaffen, Richtlinien in der Organisation weiter oben festzulegen. Entfernen Sie nach Möglichkeit, dass Repository-Inhaber Zusammenführungen ohne einen zweiten Prüfer ausführen können.

Codeüberprüfung

Die Codeüberprüfung ist die wichtigste Methode, um die Qualität und Sicherheit ihrer Software aufrechtzuerhalten. Bei der Codeüberprüfung werden verschiedene Fehlermodi 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.

Zu den Möglichkeiten, das Risiko zu mindern, gehören:

Testautomatisierung während des gesamten Softwarelebenszyklus implementieren Automatisierte Tests, die ausgelöst werden, wenn Sie die Quelle an das Versionsverwaltungssystem übergeben, bietet Entwicklern die Möglichkeit, schnell Feedback zu den bei den Tests gefundenen Problemen zu erhalten.
Die Anzahl und Identität der Prüfer sollte der Sicherheitsstufe der Anwendung entsprechen. Beispielsweise hat eine Intranetanwendung mit geringer Nutzung geringere Sicherheitsanforderungen als eine öffentlich zugängliche geschäftskritische Anwendung.
Weisen Sie Prüfer sowohl anhand des technischen Fachwissens als auch der Vertrauensstufe zu, die für die Änderung des Commits erforderlich ist. Der Prüfer sollte 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 technisches Know-how hat viele Dimensionen. Beispiel:
- Ist der Code lesbar?
- Ist es sicher?
- Werden geeignete Bibliotheken von Drittanbietern verwendet?
- Gibt es einen Prozess zum Sichern von Bibliotheken von Drittanbietern?
- Ist der Code zusammensetzbar?
- Entspricht das API-Design den Best Practices?
Überprüfungen sollten kein bürokratischer Schritt sein, sondern eine fortwährende Diskussion über Best Practices sein. Erstellen Sie Checklisten, Styleguides und Designstandards für jeden Teil Ihres Technology Stacks sowie Bildungsprogramme für neue Entwickler. Einige IDEs wie VS Code und IntelliJ bieten Linter, mit denen programmatische oder stilistische Fehler automatisch gekennzeichnet werden. Linters helfen Entwicklern, einen konsistenteren Code zu erstellen, und ermöglichen es Codeprüfern, sich mehr 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) erstellt wurde. Es werden grundlegende Praktiken zur Softwareentwicklung im Kontext der Sicherheit der Softwarelieferkette beschrieben.
Codeüberprüfungen mit Feature-Branch-Pull-Anfragen durchführen, sobald ein einzelner Entwickler bereit ist Warten Sie nicht unmittelbar vor dem Testen eines neuen Release, um Sicherheits- und Codeprüfungen durchzuführen.
Durch das Einbinden des Scannens auf Sicherheitslücken, einschließlich Scannen nach Bibliotheken von Drittanbietern, in Pull-Anfragen und IDEs können Probleme so schnell wie möglich identifiziert werden. Mit der On-Demand Scanning API in Google Cloud können Sie Container lokal auf Sicherheitslücken scannen.
Integrieren Sie automatisierte Tests vor der Zusammenführung, damit Entwickler Änderungen, die die Anwendung beeinträchtigen, identifizieren und korrigieren können. Weitere Informationen zur Testautomatisierung

Zusammenführungsgenehmigungen

In kontinuierlich integrierten CI/CD-Pipelines kann das Zusammenführen von Code in einem Produktionszweig zu nachgelagerten Änderungen führen, einschließlich automatisierter Builds und Rollouts. Aus diesem Grund ist die Sicherung, wer zusammengeführt werden kann, ein wichtiger Bestandteil des Schutzes von Software-Deployments. Folgende Punkte gehören dazu:

Richten Sie Inhaber von geschützten Zweigen in Ihren Produktionszweigen ein. Die Anzahl und Identität der Personen, die zusammengeführt werden dürfen, sollten den Sicherheitsanforderungen der Anwendung entsprechen. Für SLSA-Level 4 sind zwei stark authentifizierte Genehmiger erforderlich. Die Anzahl der Genehmiger sollte jedoch dem Inhalt des Repositorys entsprechen.
Sie sollten die Identitäten von Repository-Inhabern genau kontrollieren, da sie in den meisten Versionsverwaltungssystemen selbst zusammenführen können.
Trennen Sie Bereitstellungs- und Zusammenführungsgenehmigungsprozesse für Roll-outs mit mehreren Repositories und mehreren Artefakten.

Tools für eine sichere Entwicklung

Software Delivery Shield ist eine vollständig verwaltete End-to-End-Lösung für die Sicherheit der Softwarelieferkette. Es bietet einen umfassenden und modularen Satz von Funktionen und Tools für Google Cloud-Dienste, mit denen Entwickler, DevOps- und Sicherheitsteams den Sicherheitsstatus der Softwarelieferkette verbessern können. Die folgenden Komponenten von Software Delivery Shield tragen zum Schutz von Softwarequellcode bei:

Cloud Workstations (Vorabversion)

Cloud Workstations bietet vollständig verwaltete Entwicklungsumgebungen in Google Cloud. Es ermöglicht IT- und Sicherheitsadministratoren, ihre Entwicklungsumgebungen einfach bereitzustellen, zu skalieren, zu verwalten und zu schützen. Außerdem haben Entwickler die Möglichkeit, auf Entwicklungsumgebungen mit einheitlichen Konfigurationen und anpassbaren Tools zuzugreifen.

Cloud Workstations verbessert den Sicherheitsstatus Ihrer Anwendungsentwicklungsumgebungen und hilft dabei, die Sicherheit zu verschieben. Es bietet Sicherheitsfeatures wie VPC Service Controls, privaten ein- oder ausgehenden Traffic, erzwungene Image-Updates und Zugriffsrichtlinien für Identity and Access Management. Weitere Informationen finden Sie in der Dokumentation zu Cloud Workstations.
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 anhand von Beispielvorlagen erstellen und anpassen und die fertige Anwendung ausführen. Mit dem Cloud Code-Quellschutz erhalten Entwickler Sicherheitsfeedback in Echtzeit, z. B. zur Identifizierung von gefährdeten Abhängigkeiten und Lizenzberichten, während sie in ihren IDEs arbeiten. Sie erhalten schnelles und umsetzbares Feedback, mit dem Entwickler zu Beginn des Softwareentwicklungsprozesses Korrekturen an ihrem Code vornehmen können.

Funktionsverfügbarkeit: Der Cloud Code-Quellschutz ist für den öffentlichen Zugriff nicht verfügbar. Informationen zum Zugriff auf diese Funktion finden Sie auf der Seite „Zugriffsanfragen“.