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“.1
Phasen der Pipeline
Folgende Abbildung zeigt den Ablauf der erstellten CI/CD-Pipeline, sowie die integrierten Funktionalitäten der einzelnen Phasen:
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“3 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“4 verwendet. Das Authentifizieren zum Abrufen der Images erfolgt durch eine rollenbasierte Zugriffskontrolle. Eine Verwaltung und Konfiguration des Repositorys wird durch ein Webinterface realisiert.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.Quellen
Seminarempfehlungen
CONTINUOUS INTEGRATION (CI) WORKSHOP P-CI-01
Zum SeminarDOCKER DEVOPS WORKSHOP E-DOCK-01
Zum Seminar