Seien Sie sicher und konform mit GitHub

Wie können wir die Sicherheit gewährleisten, nachdem wir unsere Anwendung implementiert haben? Diese Frage stellt sich in vielen Kundengesprächen. Wie können wir etwas sicher machen und wie können wir sicherstellen, dass wir die Vorschriften einhalten? Leider stellen sich viele dieser Fragen erst im Nachhinein. Nachdem die Anwendung erstellt wurde oder sogar nachdem sie bereitgestellt wurde, und genau das macht es so schwierig. Unsere Antwort auf diese Fragen lautet: Sie tun es nicht. Sie tun dies nicht im Nachhinein; Sie sind standardmäßig sicher und compliant.

Standardmäßig sicher und konform

Heutzutage wird Sicherheit oft mit der Absicht implementiert, einen Einbruch zu verhindern. Stellen Sie sicher, dass Ihre Umgebung sicher ist und verhindern Sie, dass schlimme Dinge passieren. Dies wird oft von einem Kontrollrahmen der Wahl begleitet, der auf drei wichtige Bereiche abzielt - Vertraulichkeit, Verfügbarkeit und Integrität.

In vielen Fällen erhalten wir eine Excel-Liste mit Hunderten von Regeln, die wir umsetzen müssen, um unsere Anwendung "sicher" zu machen. Wenn wir diese Regeln befolgen, sind wir zwar compliant, aber nicht unbedingt sicher. In der Praxis können wir die Sicherheitsbewertung wie in der folgenden Grafik veranschaulichen.

In dieser neuen Welt, in der Cyber-Bedrohungen die neue Normalität sind, sollten Sie und Ihr Unternehmen davon ausgehen, dass Ihre Software angegriffen wird oder werden kann und dass Menschen Ihre Software auf eine Weise nutzen werden, die Sie nicht vorhersehen können. An dieser Stelle kommt "Rugged DevOps" oder "SecDevOps" ins Spiel. Robust" zu sein bedeutet, dass Sie mit dieser unvorhergesehenen Nutzung und plötzlichen Angriffen umgehen können, dass Ihre Software und Infrastruktur widerstandsfähig gegen Missbrauch ist, dass sie keine Schwachstellen enthält und dass sie von vornherein sicher ist. Außerdem sollten sowohl Ihre Software als auch Ihre Prozesse so beschaffen sein, dass Sie mit häufigen Änderungen umgehen können. Schließlich ist Ihre ganze Mühe umsonst, wenn Ihre Anwendung nach fünf Releases unsicher wird, weil Sie keine Zeit haben, die Peripherie zu pflegen.

Und deshalb sollten wir die Sicherheit in jeder Phase unseres Entwicklungslebenszyklus berücksichtigen und die Sicherheit so weit wie möglich nach links verlagern.

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Möchten Sie lernen, wie Sie die Sicherheit in Ihrem Entwicklungsprozess nach links verschieben können, während Sie mit DevOps arbeiten? Dann ist das DevOps Bootcamp die richtige Veranstaltung für Sie! Sie werden lernen, wie Sie Software mit sofortigen Feedback-Schleifen entwickeln und sie mehrmals täglich ohne zu zögern in die Produktion bringen. Sie werden in der Lage sein, alles in Ihre täglichen Praktiken zu übertragen und Ihre DevSecOps-Transformation auf der Grundlage von Erfahrungen statt Lehrbüchern einzuleiten oder zu verbessern. Beispiele.

----------------------------------------

Definition eines sicheren und gesetzeskonformen Lieferprozesses

Mit dem Übergang zu DevOps und Continuous Delivery, bei denen die Bereitstellung mehrmals täglich erfolgt, ist es noch wichtiger, die Kontrolle über den Prozess zu haben. Wenn die "Sicherheitsabteilung" zahlenmäßig von der Anzahl der Produktteams und Ingenieure übertroffen wird, sind ihr die Hände gebunden. Ohne Automatisierung und die Integration der Sicherheit in die tägliche Arbeit der Ingenieure (Entwickler, IT-Operation, Testingenieure usw.) kann diese Abteilung nur die Einhaltung der Vorschriften überprüfen. Und wie Gene Kim im DevOps-Handbuch erwähnt: "Compliance-Prüfung ist das Gegenteil von Sicherheitstechnik" (Quelle: The DevOps Handbook - Gene Kim - Seite 313).

Im Hinblick auf die Einhaltung von Vorschriften läuft alles darauf hinaus, dass Sie nachweisen können, dass der erstellte Code nachvollziehbar ist (Audit Trail), überprüft wurde (4-Augen-Prinzip) und dass das Artefakt, das für die Produktion veröffentlicht wurde, unverändert ist gegenüber dem Code, aus dem es entstanden ist (Integrität). Aber macht all dies den Code sicher? Wahrscheinlich schon, aber es sind sicherlich nicht alle Aspekte abgedeckt.

Wenn wir uns vor Augen halten, dass wir sichere Software schreiben und bereitstellen wollen, sollten wir es den Teams ermöglichen, genau das zu tun. Wir sollten dafür sorgen, dass Code:

• wird überprüft
• auf bekannte Schwachstellen gescannt
• gibt Ihre Passwörter oder Schlüssel nicht preis
• auf häufige Fehler geprüft
• verwendet bewährte Standardbibliotheken
• und ist gut getestet.

Unser Prozess sollte:

• unveränderliche Artefakte produzieren
• Testen Sie die Anwendung
• überwachen Sie auf Anomalien.

All dies ist erforderlich, um sichere und zuverlässige Software zu entwickeln.

Durch die Konzentration auf die Sicherheit innerhalb des Entwicklungs- und Bereitstellungsprozesses verlagert sich der Informationsbedarf vom Prüfer auf die Teams selbst. Um ein Problem in der Produktion zu beheben, ist eine ausreichende Protokollierung erforderlich. Um sicherzustellen, dass in der Test- und in der Produktionsumgebung dieselbe Version eingesetzt wird, müssen Skripte vorhanden sein, und um eine Benachrichtigung zu erhalten, wenn ein Problem auftritt, muss eine ausreichende Überwachung implementiert werden. Wenn der Bedarf innerhalb des Teams selbst besteht, erhalten Sicherheit und nichtfunktionale Anforderungen (NFR) eine andere Priorität, und das Ergebnis ist, dass die Teams automatisch konform werden. Durch die Implementierung der Sicherheit und der notwendigen Gegenmaßnahmen werden die erforderlichen Kontrollen zur Einhaltung der Vorschriften automatisch erfüllt. Und das Beste daran? Es wird kontinuierlich durch eine automatisierte Pipeline überprüft und Beweise können jederzeit aus dem System abgerufen werden.

Wenn wir uns nicht mehr darauf konzentrieren, Software zu entwickeln und sie "sicher" zu machen, sondern "sichere" Software auf "sichere" Weise zu entwickeln, schaffen wir sichere Systeme. Und wenn wir sichere Systeme schaffen, können wir sie in jedem Schritt unseres Prozesses testen und validieren, und sie sind dann auch konforme Systeme. Wenn Sie sicher sind, ist es sehr wahrscheinlich, dass Sie auch die Vorschriften einhalten.

Es ist wichtig, dass die Teams die Sicherheit in ihre Prozesse und Pipelines integrieren können. Das heißt, in jeder Phase des so genannten Anwendungslebenszyklus, der aus den folgenden Phasen besteht:

• Anforderungen: Wie sammeln Sie die Anforderungen? Wie stellen Sie sicher, dass die Anforderungen die Sicherheitsanforderungen und die nicht-funktionalen Anforderungen (wie Verfügbarkeit, Backups, Datenschutz usw.) abdecken?
• Lokale Entwicklung: Was können Ingenieure in ihrer lokalen Umgebung tun, um einen sichereren Code zu entwickeln, zu erstellen, zu testen und auszuführen?
• Versionskontrolle: Sobald der Code den lokalen Rechner verlässt und in die Versionskontrolle eingecheckt wird, was können wir tun, um dies sicherer zu machen?
• Build: Was müssen wir beim Erstellen von Code, der aus einem Versionskontroll-Repository stammt, prüfen und validieren, sowohl im Code als auch im erzeugten Artefakt? Was können wir außerdem tun, um sicherzustellen, dass die Pipeline selbst sicher ist?
• Freigabe: Wenn das Artefakt für eine Nicht-Produktionsumgebung freigegeben wird, was können wir in Bezug auf die Sicherheit tun - des Artefakts (Integrität, sind wir sicher, dass es sich um denselben Code wie in der Versionskontrolle handelt), der Pipeline und der Zielumgebung?
• Überwachen: Was können wir tun, um sicherzustellen, dass die Infrastruktur und die installierte Anwendung intakt bleiben, und wie können wir alle unvorhergesehenen Umstände erkennen, darauf reagieren und uns davon erholen?

Im weiteren Verlauf dieses Artikels werden wir eine Reihe von GitHub-Funktionen untersuchen, die uns helfen können, einige Schritte in Richtung sichere Softwareentwicklung zu unternehmen.

Übertragen Sie Ihren Code in die Produktion

Wenn wir eine neue Funktion mit GitHub in die Produktion überführen wollen, können wir unsere Aufmerksamkeit auf die folgenden 5 Phasen verteilen:

• Kodierungsphase
• Speicherphase
• Bauphase
• Einsatzphase
• Release-Phase

In den folgenden Abschnitten werden wir jede dieser Phasen durchlaufen und die verschiedenen Praktiken erläutern, die Sie anwenden können, und wir werden zeigen, wie GitHub Ihnen bei der Umsetzung einiger dieser Schritte helfen kann.

Codierungsphase

In der Kodierungsphase wird der Code entwickelt. In den meisten Fällen geschieht dies lokal auf dem Rechner des Entwicklers. Dies ist wohl die wichtigste Phase, denn hier wird die Sicherheit letztendlich in den Code eingebaut. Es gibt eine Reihe von Techniken und Tools, die die Erstellung von sicherem Code unterstützen.

Statische Code-Analyse

Die statische Codeanalyse analysiert die Codebasis, ohne sie auszuführen. Einige Tools suchen nach Textmustern, fortgeschrittenere Tools analysieren den Code und erstellen manchmal sogar ein Modell, um zu analysieren, wie Daten durch Ihre Anwendung fließen.

Statische Analyse-Tools wenden dann Regeln an, um Probleme im Code zu erkennen. Die statische Analyse kann eine Vielzahl bekannter schlechter Codierungspraktiken aufdecken und schlägt oft sicherere Alternativen vor. Die meisten Tools für die statische Analyse sind universell einsetzbar, aber es gibt auch eine Reihe von sicherheitsspezifischen Analysetools.

Wenn diese Probleme bereits beim Schreiben des Codes erkannt werden, können sie in der Regel sofort behoben werden, und der Entwickler hat sofort die Möglichkeit, daraus zu lernen.

Scannen von Zugangsdaten und Geheimnissen

Während er die Anwendung lokal testet, muss ein Entwickler möglicherweise eine Verbindung zu externen Systemen herstellen, Daten entschlüsseln oder die Anmeldeinformationen für sein Dienstkonto speichern. Die Verschlüsselungsschlüssel - Anmeldeinformationen und API-Schlüssel - müssen sicher gespeichert werden, landen aber regelmäßig in Quell- oder Konfigurationsdateien.

Wenn solche Dateien den Arbeitsplatz des Entwicklers verlassen, können sie in die Hände anderer gelangen und diese können diese Anmeldedaten nutzen, um sich in Ihre Infrastruktur einzuhacken.

Um dies zu verhindern, kann eine spezielle Art von statischem Analysetool Ihr lokales Repository analysieren, um zu verhindern, dass Sie Ihre Geheimnisse versehentlich mit der Welt teilen.

Kuratierte Abhängigkeiten

In den modernen Anwendungen von heute importieren wir mehr Code von anderen Entwicklern und Unternehmen als wir selbst schreiben. Wir verlassen uns stark auf Artefakt-Repositories wie NPM, NuGet und Ruby Gems. Jüngste Sicherheitsforschungen haben gezeigt, dass diese öffentlichen Repositories interessante neue Möglichkeiten bieten, Ihre Teams dazu zu bringen, Code auszuführen, den sie nicht erwartet haben.

Jedes Mal, wenn eine neue Abhängigkeit hinzukommt, sollte sie überprüft werden, um sicherzustellen, dass sie sicher ist, und Sie wollen nicht, dass Ihr Build-System versehentlich neue, unerwartete Abhängigkeiten hinzufügt.

• 3 Wege zur Risikominimierung mit privaten Paket-Feeds
• 99 Prozent des Codes gehören Ihnen nicht
• Verwirrung der Abhängigkeiten

Mit Tools wie npm audit und snyk können Sie überprüfen, ob eine Abhängigkeit keine bekannten Sicherheitslücken aufweist. Visual Studio hat in den letzten Updates begonnen, problematische Pakete hervorzuheben:

GitHub Codespaces

Die Einrichtung all dieser Tools kann zeitaufwändig sein und es ist leicht, Fehler zu machen. Außerdem stellt es eine hohe Hürde für Personen außerhalb Ihres Teams dar, zu Ihren Projekten beizutragen, unabhängig davon, ob es sich um Open Source oder Inner Source handelt. Es ist sogar eine hohe Einstiegshürde für neue Mitarbeiter in Ihrem Team.

Die Fortschritte in Visual Studio und Visual Studio Code ermöglichen es Ihnen jetzt, leicht erweiterbare Standardkonfigurationen für Ihre Entwicklungsumgebungen zu erstellen[1]. Visual Studio ist im Grunde genommen in das Backend, das Ihren Code verwaltet, analysiert und kompiliert, und das Frontend, das für die Benutzerinteraktionen zuständig ist, aufgeteilt.

GitHub CodeSpaces nutzt diese Technologie, um eine vollständige IDE über Ihr Code-Repository auszuführen. Da GitHub CodeSpaces auf einer Cloud-VM außerhalb Ihrer internen Umgebung läuft, senkt es die Sicherheitsrisiken. Jeder, der einen Beitrag zum Repository leisten muss, wird sofort in eine fertige Umgebung transportiert, in der alle oben genannten Tools installiert und konfiguriert sind, um seinen Beitrag sicher zu gestalten.

Da CodeSpaces Visual Studio in einem Remote-Container ausführt, können Sie sogar von einem iPad aus arbeiten, das mit einem viel leistungsfähigeren Remote-Container verbunden ist, und zahlen nur für die tatsächliche Nutzung, während die IDE geöffnet ist. So können Sie sogar gelegentlich Änderungen vorschlagen und ihnen dabei helfen, es richtig zu machen.

Visual Studio Live-Freigabe

Da viele Entwickler gezwungen sind, aus der Ferne zu arbeiten, ist es viel schwieriger geworden, einfach zu Ihrem Coder-Kollegen am Schreibtisch neben Ihnen hinüberzugehen, um ihn um ein schnelles Feedback, ein Pairing oder Hilfe beim Debuggen zu bitten. Die regelmäßige Überprüfung Ihres Codes mit einer anderen Person ist eine der schnellsten Möglichkeiten, Ihr eigenes Verständnis zu erweitern und potenzielle Probleme zu finden, bevor sie in das gemeinsame Repository aufgenommen werden.

In der Vergangenheit haben wir oft die gemeinsame Nutzung des Bildschirms und die Fernsteuerung für die Zusammenarbeit verwendet, aber das hat seine Nachteile. Vor allem, wenn es um die Sicherheit geht und Sie der anderen Person die volle Kontrolle über Ihr System geben, indem Sie ihr die Fernsteuerung überlassen.

Visual Studio Live Share kann mit Google Docs für Ihren Code verglichen werden. Es ermöglicht Ihnen, mit mehreren Personen gleichzeitig in demselben lokalen Repository zu arbeiten, sogar mit mehreren Cursorn, die gleichzeitig dieselbe Codedatei ändern.

Alle Teilnehmer können die Liste der entdeckten Probleme im Code sowie den Status aller Unit-Tests sehen, und Sie können sogar gemeinsam Code debuggen. Mit Live Share können Sie im Wesentlichen aus der Ferne zusammenarbeiten und prüfen, ohne den Code festschreiben und in ein entferntes Repository verschieben zu müssen.

Es kann sogar registrieren, wer an dem Code mitgearbeitet hat, wenn Sie sich für einen Commit entscheiden. Wenn Sie die Funktion liveshare.populateGitCoAuthors aktivieren, wird auf der Registerkarte Versionsverwaltung in VS Code automatisch der Anhang "Co-authored-by" in der Commit-Nachricht generiert, so dass Hosts die Mitarbeiter zuordnen können, mit denen sie während einer Pair Programming-Sitzung zusammengearbeitet haben.

Mit wem Sie zusammenarbeiten können und was diese Personen tun dürfen, können Sie mit GateKeeper[2] verwalten.

Phase des Speicherns

In der Speicherphase schiebt der Ingenieur den Code von seinem lokalen Rechner in die Versionskontrolle. Wenn Sie GitHub verwenden, besteht die Speicherung des Quellcodes aus zwei Phasen. Das Commit des Codes in Ihr lokales Git-Repository und das Pushen des Codes in das Git-Repository, das auch vom Rest des Entwicklungsteams verwendet wird.

Um einen sicheren Prozess zu gewährleisten, können Sie eine Reihe von Dingen tun.

Erforderliche Codeüberprüfung

Um das 4 (6/8) Augen-Prinzip bei jeder Codeänderung zu gewährleisten, ist die erste Gelegenheit, bei der Sie dies tun können, in der Regel das Einstellen des Codes in das Git-Repository. Indem Sie eine einfache Verzweigungsstrategie definieren, bei der Personen kurzlebige Zweige für ihre Codeänderungen erstellen und den Hauptzweig mit einer Verzweigungsrichtlinie vor direkten Check-Ins schützen, können Sie leicht durchsetzen, dass jemand anderes als der Autor die Änderungen an der Codebasis überprüft und genehmigt. Mit GitHub können Sie die Registerkarte Einstellungen in Ihrem Repository verwenden, um diese Richtlinien für die Zweige festzulegen. Sie können verschiedene Richtlinien erstellen und sie auf verschiedene Zweige anwenden. Um die Richtlinie auf alle Zweige anzuwenden, geben Sie das "Zweignamensmuster" an. Wildcards sind erlaubt, so dass "*" die Richtlinie auf alle Zweige anwendet.

 

Validierung von Code-Phasenprüfungen anhand der Codebasis

Die Annahme, dass ein Ingenieur die in der Codephase beschriebenen Prüfungen auf seinem Arbeitsplatzrechner durchgeführt hat, ist in Ordnung, birgt aber Risiken. Um jedoch sicherzustellen, dass Ihnen nichts durch die Lappen geht, können Sie einen Continuous Integration (CI) Build einrichten. Durch die Ausführung eines CI-Builds nach jedem Push in den kurzlebigen Zweig werden die im kurzlebigen Zweig vorgenommenen Änderungen in Kombination mit der Codebasis, an der andere Ingenieure arbeiten, validiert. Diese Praxis bietet noch mehr Sicherheit. Dieser Build sollte (mindestens) die folgenden Codephasenprüfungen enthalten:

• Kompilieren/Syntaxprüfung
• statische Code-Analyse
• Einheitstests
• Scannen von Zugangsdaten und Geheimnissen.

Wenn Sie GitHub verwenden, können Sie GitHub Actions verwenden, um die Aktionen durchzuführen. GitHub bietet außerdem eine automatische Sicherheitsprüfung nach Anmeldeinformationen bei jedem Einchecken. Wenn Sie versehentlich einen Berechtigungsnachweis einchecken, werden Sie von GitHub darüber informiert.

Auf der Registerkarte "Aktion" können Sie eine neue Aktion (oder einen Workflow) erstellen. Abhängig von Ihrem Repository können Sie einen Standard-Workflow verwenden oder Ihren eigenen erstellen.

Die Workflow-Pipeline wird als Code erstellt und zu Ihrem Repository hinzugefügt. Eine Änderung dieses Workflows führt zu einer Codeänderung und ist somit Teil der Verzweigungsrichtlinien des Repositorys.

Scannen auf Schwachstellen und Abhängigkeiten

Das Scannen Ihrer eigenen Software ist eine Sache, aber in der modernen Softwareentwicklung werden über 70% der Software, die Sie ausliefern, nicht von Ihrem eigenen Entwicklungsteam geschrieben (lesen Sie in Version 9 unseres Magazins "99% des Codes ist nicht von Ihnen). Mit dem Aufkommen von Open Source Software und Paketmanagement-Tools, Artefakt-Repositories und Container-Registries wurde die Verwendung von Software, die von anderen geschrieben wurde, zum Mainstream.

Vom Konzept her ist das perfekt. Je weniger Sie selbst tun müssen, desto besser ist es. Es macht die Menschen produktiver und in vielen Fällen sind die Leute, die eine bestimmte Open-Source-Bibliothek geschrieben haben, besser mit dem Thema vertraut als Sie selbst. Die Verwendung der Software anderer, ob Open-Source oder von einem Anbieter gekauft, ist jedoch eine potenziell gefährliche Praxis. Die Software, die Sie als Teil Ihrer eigenen Software verwenden, kann gefährliche Schwachstellen enthalten, die ausgenutzt werden können.

GitHub hat Sicherheitsscans für Sicherheitslücken in seine Repositories integriert. Wenn sie eine Sicherheitslücke finden, die in einer neueren Version behoben ist, reichen sie einen Pull Request mit dem vorgeschlagenen Fix ein. Dies geschieht mit einem Tool namens Dependabot (dependabot.com).

Sie können Dependabot in Ihrem GitHub-Repository auf der Registerkarte "Sicherheit" aktivieren. Klicken Sie auf "Dependabot-Warnungen aktivieren" und wählen Sie die gewünschte Einstellung.

 

Eine Alternative für Dependabot ist NuKeeper, das ähnliche Funktionen bietet (github.com/NuKeeperDotNet/NuKeeper)

Wenn Sie mehr über die Integration von Schwachstellen-Scans in Ihre Pipeline erfahren möchten, können Sie die Übung "Verwalten von Open-Source-Sicherheit und -Lizenz mit WhiteSource" in den Azure DevOps Labs verfolgen (azuredevopslabs.com/labs/vstsextend/whitesource/)

Scannen von Zugangsdaten und Geheimnissen

Natürlich scannen Sie Ihr lokales Repository auf versehentlich übertragene Anmeldeinformationen, aber manchmal lernt Ihr Scanning-Tool auch nachträglich neue Muster. GitHub Advanced Security verfügt jetzt über automatische Scans, um durchgesickerte Anmeldeinformationen beim Push zu erkennen, und überwacht Ihr Repository auch danach weiter.

Wenn Sie nicht scannen, sollten Sie wissen, dass viele Bedrohungsakteure dies tun. Sie sehen sich eine Vielzahl interessanter Repositories an und bieten GitHub-weite Suchmuster an. Es kann nur fünf Minuten dauern, bis Ihr gemeinsam genutzter AWS-Schlüssel entdeckt und ausgenutzt wird, um Miner oder Ransomware in Ihren Cloud-Umgebungen einzusetzen. Wenn er von Ihnen unentdeckt bleibt, kann er innerhalb weniger Tage $60k kosten.[3]

Wenn Anmeldeinformationen von GitHub entdeckt werden, werden sie automatisch widerrufen, um andere daran zu hindern, den Schlüssel auszunutzen. GitHub arbeitet mit großen Cloud-Anbietern zusammen, um diesen Service anzubieten.

Bauphase

Wenn der Code auf der lokalen Workstation erstellt und sicher in der Versionskontrolle gespeichert wurde, kann der Auslieferungsprozess wirklich beginnen. Die Software muss "verpackt" werden. Vergleichen Sie das mit einem Fließband, wo Produkte vom Band rollen und in einer großen Schachtel verpackt werden. Dieser Karton wird unterschrieben, versiegelt und an das Lager geliefert, wo er zur weiteren Auslieferung abgeholt werden kann. Im Wesentlichen funktioniert die Build-Pipeline auf die gleiche Weise.

Während der Kodierungs- und Speicherphase haben wir bereits mehrere Prüfungen durchgeführt, die schnelles Feedback über die Qualität, Sicherheit und Stabilität des Codes lieferten. In der Build-Phase fügen wir weitere Prüfungen und Validierungen hinzu und verpacken das Produkt schließlich:

• Aktivitäten aus Speicherphasen aufbauen
• zweite Stufe - statische Code-Analyse
• Scannen auf Sicherheitslücken und Abhängigkeiten
• Lizenzprüfung
• sichere Speicherung des Build-Artefakts
• den Verlauf der Erstellung zu schützen.

Richten Sie eine Continuous Integration-Pipeline für alle Ihre Zweige ein. Wenn Ingenieure Code in einen Zweig in der Versionskontrolle einfügen, sollte die Validierung direkt beginnen. In vielen Fällen wird der vollständige Build erst nach dem Zusammenführen der Änderungen in den Hauptzweig ausgeführt.

Sicheres Speichern des Build-Artefakts

Einer der Hauptzwecke einer Build-Pipeline ist die Produktion:

• ein Artefakt, das schließlich in einer Umgebung eingesetzt werden kann;
• ein Artefakt, das eine Umgebung schafft;
• eine Reihe von Skripten, die die erforderliche Konfiguration festlegen.

In jedem Fall ist es wichtig, dass wir sicherstellen, dass das Artefakt eindeutig identifizierbar ist. So können wir sicherstellen, dass niemand ein Artefakt manipuliert hat, bevor es in die Produktion gelangt, und dass der von uns produzierte Code auch tatsächlich der Code ist, der läuft. Die Speicherung des Artefakts, das die Build-Pipeline produziert, ist daher eine wesentliche Aufgabe in einer sicheren Pipeline.

Innerhalb Ihrer Build-Pipeline können Sie zwei Arten von Artefakten erzeugen:

• Pakete oder Container, die von anderer Software genutzt werden und nicht von selbst laufen;
• Softwarepakete oder Container, die vom Endbenutzer konsumiert werden oder einen Prozess ausführen.

Wenn wir Softwarepakete erstellen, wie NuGet-Pakete, NPM-Pakete, PowerShell-Module oder sogar Container, sollten wir sofort an Artefakt-Repositories denken. Wir veröffentlichen unsere Pakete in einer Galerie oder einem Repository, damit andere sie nutzen können. Wir können sie entweder öffentlich zugänglich machen (Open Source) oder intern zur Verfügung stellen (Inner Source). Um das Artefakt speichern zu können, muss das Artefakt eine Reihe einfacher Regeln einhalten. Zum Beispiel muss es eine eindeutige Version und ein Manifest enthalten, das das Paket beschreibt. Um das Paket zu veröffentlichen, benötigt der Herausgeber eine Authentifizierung. Diese Kombination aus einem versionierten Paket und einer sicheren Verbindung gewährleistet die Integrität des Pakets.

Seltsamerweise gehen wir anders vor, wenn wir unsere Website oder Anwendung auf unseren Produktionsservern bereitstellen. Wir erstellen unsere Software in der Pipeline und kopieren die Dateien in die Produktion. Manchmal speichern wir ein Artefakt auf einer Netzwerkfreigabe oder einer Festplatte, bevor wir es freigeben. Aber die Speicherung auf einem Datenträger kann es anderen ermöglichen, das Paket zu verändern. Außerdem ist unsere Versionierung nicht immer einfach, wenn es um unsere eigenen Dateien geht.

Um die Integrität unserer Software zu gewährleisten, müssen auch die Build-Pipeline und der Speicherort der Artefakte sicher sein. Wenn Sie GitHub verwenden, können Sie die Build-Artefakte auf den Server hochladen. Es gibt keine Möglichkeit, dass jemand das Paket auf dem Server verändert. Indem Sie die Pipeline sichern und die Pakete versionieren, reduzieren Sie das Risiko unsicherer Software drastisch. Zusätzlich zum Hochladen der Artefakte können Sie mit GitHub auch das GitHub Package Repository verwenden, um Ihre internen Quellpakete zu speichern. Sie können sogar die aufbauende GitHub Container Registry verwenden, um Ihre Docker-Images direkt aus Ihrem Workflow zu speichern.

Bereitstellungsphase

Die Bereitstellungsphase ist die Phase, in der alle Aktivitäten der vorherigen Phasen zusammenlaufen. Der von einem oder mehreren Teams geprüfte Code wurde in Pakete oder einsatzfähige Artefakte umgewandelt. In der Bereitstellungsphase ist die Release-Pipeline der Mechanismus, mit dem die Dinge aus einer geschützten, privaten Umgebung an einen Ort gebracht werden, an dem sie von anderen genutzt werden können.

Normalerweise wird eine Release-Pipeline wie folgt aufgebaut:

• Artefakte aus einer oder mehreren Quellen sammeln
• Infrastruktur einsetzen
• Infrastruktur konfigurieren
• Infrastruktur validieren
• Anwendung bereitstellen
• Anwendung konfigurieren
• Anwendung validieren.

Wenn wir uns die oben genannten Aktivitäten ansehen, gibt es eine Reihe von Dingen, die wir sicherstellen müssen, wenn wir über eine sichere Pipeline sprechen.

Führen Sie dynamische Sicherheitstests für die Infrastruktur durch

Dynamic Application Security Testing (DAST) ist ein Prozess, bei dem eine Anwendung oder ein Softwareprodukt in einem Betriebszustand getestet wird. Diese Art von Tests ist hilfreich für die Einhaltung von Industriestandards und den allgemeinen Sicherheitsschutz für sich entwickelnde Projekte. Gute Beispiele sind Scans für SQL-Injections, Cross-Site Scripting usw. Wenn eine Anwendung mehrmals täglich eingesetzt wird, müssen die Sicherheitsprüfungen jedes Mal durchgeführt werden, anstatt sie nur einmal zu prüfen (wie früher). Mit den Tools von Automated Dynamics Security Testing können Sie diese Angriffe automatisieren.

Ein hervorragendes Tool zur Durchführung dynamischer Sicherheitstests ist OWASP ZAP. Sie finden die OWASP ZAP-Aufgabe entweder auf GitHub[4] oder im Azure DevOps Marketplace[5] .

Mit GitHub können Sie ganz einfach die Überprüfung auf häufige Sicherheitslücken und Programmierfehler aktivieren. Über die Registerkarte Sicherheit können Sie diesen Workflow erstellen, der für jeden von Ihnen erstellten Zweig ausgeführt wird. CodeQL ist ein semantisches Code-Analyse-Tool, mit dem Sie Ihren Code abfragen können, um Schwachstellen zu finden.

Führen Sie Tests aus, die eine installierte Anwendung erfordern

Obwohl die Software in der Build-Phase getestet wurde, vorzugsweise durch die Ausführung von Unit-Tests, müssen Sie auch Tests ausführen, die eine bereitgestellte Anwendung erfordern, d.h. Integrationstests oder End-to-End-Tests. GitHub bietet Ihnen die Möglichkeit, Ihre eigenen Test-Runner zu integrieren und diese als Teil des Deployment-Prozesses auszuführen

Überwachen Sie die wichtigsten Metriken nach der Bereitstellung

Wie stellen Sie nach der Bereitstellung Ihrer Anwendung sicher, dass sie korrekt ausgeführt wird? Natürlich müssen Sie einige grundlegende Dinge überprüfen, indem Sie einen Smoke-Test durchführen und prüfen, ob die Anwendung reagiert. Aber es ist auch ratsam, mit dem Sammeln von Metriken über die Grundlinien Ihrer Anwendung zu beginnen. Wie ist die Reaktionszeit, wie hoch ist die CPU-Auslastung? Wenn Sie diese Grunddaten kennen, können Sie sie nach einer neuen Bereitstellung überprüfen und feststellen, ob sie immer noch gleich sind oder sich zumindest nicht verschlechtert haben.

Sichere Endpunkte zur Zielumgebung einrichten

Natürlich müssen Sie Ihre eigene Software auf alle Arten von Sicherheitsproblemen überprüfen. Aber auch die Pipeline selbst und die Verbindung zur Zielumgebung müssen sicher sein. Wenn Sie eine neue Version einer Anwendung bereitstellen, benötigen Sie wahrscheinlich eine Art von Konfiguration in der Anwendung selbst. Möglicherweise benötigen Sie auch einige Geheimnisse wie Passwörter oder Zugriffstoken für die Bereitstellung der Anwendung. Innerhalb von Azure DevOps können Sie Service Connections verwenden, um einen sicheren Endpunkt zu erstellen. In GitHub können Sie die Anmeldeinformationen für die Veröffentlichung in einem GitHub Secret speichern. Auf diese Weise stellen Sie sicher, dass die Pipeline die einzige Möglichkeit zur Bereitstellung einer Anwendung ist. Dazu wird einfach ein Schlüssel-Wert-Paar verwendet, wobei Sie den Namen des Geheimnisses im Aktions-Workflow als Umgebungsvariable verwenden können.

Phase der Veröffentlichung

Im Gegensatz zu dem, was viele Menschen und Unternehmen denken, ist die Freigabephase nicht dasselbe wie die Bereitstellungsphase. In vielen Fällen ist es immer noch so, dass die Bereitstellung mit der Freigabe gleichzusetzen ist, aber durch diese Abhängigkeit besteht auch ein implizites Sicherheitsrisiko. Wenn die Freigabe mit der Bereitstellung gleichzusetzen ist, bedeutet dies, dass die Software in dem Moment, in dem Sie sie bereitstellen, für Ihre Endbenutzer verfügbar wird. Da Sie wahrscheinlich einige Dinge überprüfen müssen, bevor Sie Ihren Kunden erlauben, die Software zu nutzen, ist die einzige Möglichkeit, dies zu tun, die Planung einer Ausfallzeit. Ein Service-Fenster ist in der Regel der richtige Weg.

Aber die Beschränkung auf ein striktes Veröffentlichungsfenster schränkt auch die Möglichkeit ein, neue Funktionen oder - noch schlimmer - Sicherheitspatches bereitzustellen. Wir alle wissen, dass das Warten auf einen geeigneten Zeitpunkt für die Bereitstellung einer Sicherheitsbehebung ein viel größeres Risiko bedeuten kann.

Wenn Sie Ihre Software und Pipelines so aufbauen, dass die Software freigegeben werden kann, ohne die Zielumgebung zu beeinträchtigen, können Unternehmen nicht nur neue Funktionen schnell an ihre Kunden liefern, sondern auch die Sicherheitsrisiken drastisch reduzieren, da das Patchen der Funktionen nur eine Frage des Starts einer neuen Bereitstellung ist. Wenn Sie in Ihrem Code Feature-Toggles verwenden, können diese dazu beitragen, dies zu erleichtern. Mit Feature-Toggles können Sie Funktionen deaktivieren oder aktivieren. Wenn das Kippschalter aktiviert ist, können die Benutzer die neue Funktion nutzen. Ist das Kippschalter "aus", kann die Funktion nicht verwendet werden. Mit Funktionsumschaltungen können Sie das Verhalten der Anwendung ändern, ohne den Code zu verändern.

Fazit

Wenn Sie eine Anwendung entwickeln, sollten Sie dies standardmäßig auf sichere Weise tun. Es gibt viele Tools, die das Leben der Entwickler erleichtern und die Sicherheit erhöhen können. Es reicht nicht aus, die Tools nur zu implementieren. Sie müssen auch verstehen, warum diese Tools benötigt werden und sie unterstützen.

GitHub unterstützt von Haus aus eine Menge Sicherheitsfunktionen. Sie müssen die Infrastruktur, Ihre Software, aber auch Ihre Delivery Pipeline sichern. Konzentrieren Sie sich darauf, die Sicherheit in Ihrem Prozess nach links zu verschieben.

Lernen Sie, wie Sie Sicherheit in Ihren Entwicklungsprozess einbinden können

Möchten Sie lernen, wie Sie die Sicherheit in Ihrem Entwicklungsprozess nach links verschieben können, während Sie mit DevOps arbeiten? Dann ist das DevOps Bootcamp die richtige Veranstaltung für Sie! Sie werden lernen, wie Sie Software mit sofortigen Feedback-Schleifen entwickeln und diese mehrmals täglich ohne zu zögern in die Produktion überführen können. Sie werden in der Lage sein, alles in Ihre täglichen Praktiken zu übertragen und Ihre DevSecOps-Transformation auf der Grundlage von Erfahrungen statt auf der Grundlage von Lehrbuchbeispielen einzuleiten oder zu verbessern.

Autoren René van Osnabrugge, Michiel van Oudheusden, Jesse Houwing und Arjan van Bekkum (Berater bei Xpirit).

• Visual Studio Code: Entfernt - Container
• GitHub: Gatekeeper von Lostintangent
• The Register: DXC GitHub AWS-Schlüssel durchgesickert
• Visual Studio-Marktplatz: ZAP Scanner