6 Minuten Lesezeit (1137 Worte)

Konzeptionelle Entwicklung einer sicheren CI/CD-Pipeline mit DevSecOps

Mittwoch, 07. September 2022

Softwareprojekte werden häufig ohne eine festgelegte Struktur durchgeführt. Die Entwicklungen werden ohne Richtlinien oder festgelegte Standards bearbeitet, wodurch der Programmcode nicht einheitlich ist. Durch fehlende Automatismen im Projekt finden keine Überprüfungen der Entwicklungen statt. Des Weiteren ist meistens kein definierter Workflow vorhanden. Dies führt zu unstrukturiertem Arbeiten in Projekten. Somit verlangt es viel Zeit, bis eine Software geforderte Qualitätsstandards erreicht, wodurch die Kosten erhöht werden. Außerdem finden keine Sicherheitsüberprüfungen statt, wodurch Sicherheitslücken in den Entwicklungen nicht erkannt werden. Diese werden ggf. auf einer Arbeitsumgebung veröffentlicht, was das Risiko eines Angriffes erhöht. Daraus entsteht die Motivation, eine Lösung zu finden, die die Prozesse der Entwicklungsarbeiten verbessert. Entwicklungsarbeiten müssen nach einer festgelegten Struktur durchgeführt werden, wodurch der Programmcode schneller, sicherer und qualitativ hochwertiger, produktiv veröffentlicht wird.

Entwicklungsarbeiten sicherer und effizienter durch DevSecOps?

In diesem Kapitel wird eine CI/CD-Pipeline nach dem im Blogartikel erläuterten DevSecOps-Paradigma erstellt. Die Methode zur kontinuierlichen Integration von Softwareänderungen, sowie der fortlaufenden Veröffentlichung der neuesten Features bzw. des neu entstandenen Produkts wird als CI/CD bezeichnet. Dies ermöglicht es dem Entwickler, den Entwicklungsstand nach Code-Analysen gesichert, in kleinen Abständen auf ein Repository hochzuladen und ggf. automatisiert auf der Arbeitsumgebung zu veröffentlichen.

Für die Realisierung der Pipeline werden Konfigurationsdateien der Versionsverwaltungssoftware verwendet. „GitLab“ ermöglicht dies z. B. mit der Konfigurationsdatei „gitlab-ci.yml“.¹

Phasen der Pipeline

Folgende Abbildung zeigt den Ablauf der erstellten CI/CD-Pipeline, sowie die integrierten Funktionalitäten der einzelnen Phasen:

Test

Durch eine aufgesetzte und in die Pipeline integrierte Linting-Software können Richtlinien zur Einhaltung der Compliance festgelegt werden. Damit ist es möglich, die Entwicklung auf Compliance zu überprüfen, wodurch einheitlich definierte Entwicklungsarbeiten eingeführt werden. Das führt zur Minimierung von Code-Smells und erhöht somit die Nachvollziehbarkeit des Codes. Dies ermöglicht eine gute Wartbarkeit des Codes, was bei dem Ansatz von CI/CD, in kleinen Schritten Entwicklungen zu integrieren und zu veröffentlichen, zielführend ist, da es den Zeitfaktor bei z. B. einem Review minimiert.

Für das Ausführen und Erstellen von Unit-Tests, um eine Überprüfung der technischen Lauffähigkeit von Entwicklungen zu ermöglichen, wird eine Software, in Abhängigkeit zu der genutzten Programmiersprache verwendet.

Das frühzeitige Prüfen der Entwicklungen durch Unit-Tests, wodurch Funktionen auf ihre Ergebnisse getestet werden, führt dazu, dass Fehler im produktiven Betrieb minimiert werden. Somit werden nachträgliche Überarbeitungen reduziert, wodurch Entwicklungsarbeiten auf neue Features oder Optimierung konzentriert werden können. Des Weiteren werden Ausfallzeiten der veröffentlichten Entwicklungen minimiert, da wie zuvor beschrieben, die Lauffähigkeit gewährleistet wird.

Um dem Ansatz „Shift-Left“ nachzugehen, werden multiple Sicherheitsanalysen in die Pipeline integriert. Eine Software, die dies ermöglicht, wäre z. B. der „ShiftLeft-Scanner“.² Sensitive Daten im Klartext, wie z. B. Passwörter oder Zertifikatsschlüssel innerhalb der Entwicklung, können dadurch detektiert werden. Des Weiteren werden verwendete Module mit bekannten CVEs verglichen. Zusätzlich ermöglicht die Software das Testen der Entwicklung nach SAST, wodurch Schwachstellen von Objekten erkannt und mögliche Risiken reduziert werden können. Durch die Berücksichtigung und Behebung von detektierten Schwachstellen werden die Entwicklungen sicherer. Mögliche Schwachstellen, die durch einen Angreifer ausgenutzt werden können, sind somit weitestgehend auszuschließen. Einer Behebung von Schwachstellen, die zur Laufzeit einer Software mit meistens großem Aufwand verbunden ist, wird somit entgegengewirkt.

Report

Um es den Entwicklern zu ermöglichen, eine Fehlerbehebung durch die Ergebnisse der Analysen durchzuführen, wird für die zentrale Verwaltung der Analyse-Reports eine Software wie z. B. „SonarQube“³ verwendet. Das umfangreiche Code-Review-Tool ermöglicht es, zusätzlich Code-Analysen zur Aufdeckung von Schwachstellen und Code-Smells durchzuführen. Dies führt zur Minimierung möglicher Gefährdungen, wodurch ein sicherer Code erstellt wird. Durch „SonarQube“ wird ebenfalls die Integration eines Quality Gates zur Einhaltung der Compliance ermöglicht, der von einer zentralen Stelle konfiguriert und anschließend auf alle Projekte angewendet wird. Somit kann das Entwickeln nach festgelegten Standards und Richtlinien erfolgen, ohne diese projektspezifisch anzulegen. Zum Einsehen der Analyse-Reports oder Konfigurieren des Quality Gates bietet die Software ein Webinterface an.

Wenn Tests in der Phase „Tests“ oder „Report“ fehlschlagen, wird die Pipeline unterbrochen. Erst nachdem keine Fehler oder risikoreiche Zeilen detektiert wurden, folgt die nächste Phase.

Build

In dieser Phase wird der Entwicklungsstand durch z. B. „Docker“ zu einem Image paketiert. Das Image stellt ein Speicherabbild des Entwicklungsstandes sowie sämtliche zur Laufzeit benötigten Abhängigkeiten wie z. B. Bibliotheken, Konfigurationen etc. dar.

Als Repository für erstellte oder in der Pipeline verwendete Images wird eine Software wie z. B. „Harbor“⁴ verwendet. Das Authentifizieren zum Abrufen der Images erfolgt durch eine rollenbasierte Zugriffskontrolle. Eine Verwaltung und Konfiguration des Repositorys wird durch ein Webinterface realisiert.

Durch die in „Harbor“ integrierte Analysesoftware „Trivy“⁵ ist eine Überprüfung der Images auf Schwachstellen möglich. Somit kann der Entwickler detektierte Schwachstellen beheben, wodurch die Sicherheit in Images gewährleistet wird. Die ebenfalls in „Harbor“ integrierte Software „Notary“⁶ ermöglicht das Signieren von Images, sowie deren Überprüfung. Sie stellt fest, ob das Image vertrauenswürdig ist, um somit die Datenintegrität sicherzustellen.

Deploy

Die Phase Deploy führt zur Bereitstellung des Entwicklungsstandes auf die entsprechende Umgebung. Hierzu wird das Image, welches in der vorherigen Phase auf das Repository hochgeladen wurde, auf die entsprechende Entwicklungs- bzw. Pre-/Produktionsumgebung veröffentlicht.

Mailing

In der letzten Phase der Pipeline wird dem Entwickler eine E-Mail über den Status der Pipeline gesendet, was eine augenblickliche Einsicht der Informationen ermöglicht, wodurch ersichtlich wird, ob weitere Änderungen an der Entwicklung vorgenommen werden müssen.

Die Balance zwischen Bedienbarkeit und Funktionsumfang

Bei der Einführung von DevSecOps erweist sich die Benutzerakzeptanz als besonders wichtig. Neue Tools, die in die Pipeline integriert werden, bringen neue Features mit sich. Dies führt zu einem größeren Umfang an benötigtem Know-how. Bei dem Vermitteln des benötigten Know-hows wird deutlich, dass die Erwartungen an den Entwickler meist zu hoch angesetzt werden. Dies führt dazu, dass Themengebiete oft von Grund auf neu erklärt werden müssen. Somit ist es für den Erfolg der entwickelten Pipeline entscheidend, eine geeignete Balance zwischen Bedienbarkeit und Funktionsumfang zu finden und den Nutzern das benötigte Know-how frühzeitig in kleinen Abständen zu vermitteln, um einer falschen oder eine Nichtnutzung der Pipeline entgegenzuwirken.

Fazit

Die Pipeline ermöglicht einen Automatismus, der Entwicklungen auf Schwachstellen, Sicherheitslücken, Bugs, Code-Smells, sensitive Daten und definierte Richtlinien analysiert, wodurch eine schnellere, sichere und qualitativ hochwertigere Veröffentlichung der Entwicklungsstände möglich wird.

Des Weiteren wird ein einheitliches Arbeiten innerhalb der Projekte ermöglicht, da einzuhaltende Richtlinien und Standards durch eine Software wie „SonarQube“ definiert werden können.

Die Komponenten der Pipeline können beliebig auf den Anwendungsfall erweitert oder verändert werden. Daraus resultierend ist die Einführung einer solchen Pipeline für eine Projektbearbeitung mit dem Ziel, Entwicklungen mit einem hohen Qualitätsstandard zu veröffentlichten, empfehlenswert.