Eine sicherheitsbewusste CI/CD-Pipeline aufbauen

Kontinuierliche Integration (CI) und kontinuierliche Bereitstellung (CD) sind für DevOps-Teams mittlerweile gängige Praxis. Im CI/CD-Prozess geht es darum, neue Anwendungen zu erstellen und bereitzustellen oder Updates für bereits bereitgestellte Workloads zu veröffentlichen. Daher konzentrieren sich die meisten CI/CD-Bemühungen darauf, die Entwicklung zu beschleunigen.

CI/CD-Praktiken können jedoch weit mehr leisten, als die Bereitstellung von Workloads zu ermöglichen. So lässt sich CI/CD auch als sicherheitsbewusste Pipeline einsetzen, die Code sicherheitsorientierten Tests unterzieht, den Quellcode auf Schwachstellen scannt und weitere wichtige Prüfungen durchführt, bevor die Anwendungskomponenten bereitgestellt werden.

So sieht eine sicherheitsbewusste CI/CD-Pipeline aus

Stellen wir uns die CI/CD-Pipeline zunächst als linearen Weg vor, der von der Entwicklung zum Betrieb führt.

Entwickler starten mit dem Build-Prozess und checken anschließend ihren Code in ein Versionskontrollsystem wie Git ein. Der Code wird validiert und paketiert. Danach wird die Paketdatei – etwa eine Webdeploy.zip-Datei für .NET oder ein Docker-Container-Image – in der vorgesehenen Laufzeitumgebung veröffentlicht, zum Beispiel auf einem Docker-Host oder in einer Kubernetes-Umgebung. Anschließend übernehmen die Betriebsteams die Kontrolle und verwalten die Umgebung.

Sehen wir uns vor diesem Hintergrund an, wie das Konzept „Security nach links verschieben“ zur Optimierung der CI/CD-Sicherheit den Prozess verändern kann, indem Sicherheitspraktiken entlang der gesamten Zeitachse integriert werden. Im Sicherheitskontext bedeutet „nach links verschieben“, Sicherheitsbewusstsein so früh wie möglich im DevOps-Zyklus zu integrieren und dann in jeder Phase des Prozesses aufrechtzuerhalten.

Wichtig ist jedoch, dass die meisten Empfehlungen zum Verschieben nach links ein allgemeines Konzept beschreiben: Es geht darum, beliebige DevOps-Themen (Tests, Betriebsautomatisierung und Sicherheit) näher an die implementierende Person heranzurücken. Ziel ist es, Feedbackschleifen zu schließen und schneller über die Auswirkungen von Änderungen in diesen Bereichen zu informieren.

Die meisten Unternehmen verschieben andere DevOps-Prozesszyklen bereits auf diese Weise, scheitern aber daran, dasselbe mit der Sicherheit zu tun. Deshalb wurde der Begriff DevSecOps geprägt, um auf die Bedeutung von Sicherheit in DevOps-Praktiken aufmerksam zu machen.

Sehen wir uns einige gängige Sicherheitsfunktionen an, die sich in die Struktur jeder CI/CD-Pipeline integrieren lassen.

Wie dieses Diagramm zeigt, lässt sich ein sicherheitsbewusster CI/CD-Ablauf einrichten, ohne den CI/CD-Prozess selbst zu verändern. Mit einem solchen sicherheitsorientierten Ablauf können DevOps-Teams Sicherheitsfunktionen in jeden CI/CD-Zyklus integrieren.

Sehen wir uns einige der im Diagramm genannten wichtigen Sicherheitsaspekte genauer an: welche Komponenten sich in eine CI/CD-Pipeline integrieren lassen und welche Sicherheitsvorteile sie bieten.

Automatisiertes Threat Modeling

Threat-Modeling-Tools analysieren Anwendungen auf bekannte Sicherheitslücken, Schwachstellen und andere Sicherheitsrisiken. Sie helfen Unternehmen dabei, Bedrohungen zu identifizieren, zu erkennen und vorherzusagen und unterstützen proaktive Entscheidungen, um Sicherheitsbedrohungen zu vermeiden oder einzudämmen.

In unserem CI/CD-Pipeline-Diagramm steht Threat Modeling an erster Stelle, findet jedoch häufig schon vor Beginn der Entwicklung statt. Idealerweise wird es in verschiedenen Phasen von CI/CD wiederholt – hier bietet sich ein automatisierter Threat-Modeling-Ansatz an.

Software-Stückliste

Immer mehr Quellcodeentwickler verwenden Code, der von anderen stammt. Deshalb kann es schwierig sein, Ressourcen wie Open-Source-Codeausschnitte, Softwarepakete oder Docker-Container während des Entwicklungszyklus einer Anwendung nachzuverfolgen. In solchen Fällen ist eine Software-Stückliste (SBOM) hilfreich.

Mit einer SBOM können Entwicklungsteams Aspekte von Softwarekomponenten katalogisieren, etwa den Speicherort von Paketen und Abhängigkeiten. Außerdem schafft sie Transparenz über die Komponenten einer Anwendung. Diese Informationen ermöglichen es auch, die Pakete in einer Anwendung mit bekannten Sicherheitslücken abzugleichen. So lässt sich erkennen, wo und wie böswillige Akteure den Code ausnutzen könnten. Deshalb sind SBOMs zu einem wichtigen Bestandteil sicherheitsbewusster CI/CD-Pipelines geworden.

Artefaktsignierung

Entwickler verwenden Artefakte häufig in mehreren Anwendungen wieder, um den Prozess zu beschleunigen. In der Softwareentwicklung bezeichnet ein Artefakt beliebige Software oder softwarebezogene Artefakte – etwa die bereits erwähnten SBOMs –, die Funktionen und Möglichkeiten für einen umfassenderen Softwareanwendungslebenszyklus bereitstellen.

Das Ergebnis eines Builds oder der Kompilierung von Entwicklungscode (also das Resultat von CI) lässt sich als Artefakt betrachten. Weitere gängige Artefakte sind NuGet-Pakete für .NET, npm für die Node.js-Entwicklung und Maven für Java. Auch PowerShell- oder Bash-Skripte können als Artefakte gelten.

Um Ressourcen zu schützen und ihre Authentizität sicherzustellen, können DevOps-Engineers den von ihnen erstellten Quellcode digital signieren. Eine digitale Signatur ist Voraussetzung für App-Entwickler, die Vertriebsplattformen wie Apples App Store und den Google Play Store nutzen. Anhand einer mit einem Zertifikat verknüpften digitalen Signatur kann der Empfänger des Quellcodes feststellen, von welcher Organisation das Artefakt stammt. Die Signatur garantiert außerdem, dass keine unbefugte Partei den Code manipuliert hat.

Der Prozess der digitalen Signierung ist jedoch komplex und erfordert den Umgang mit Zertifikaten einer Public-Key-Infrastruktur. Zum Glück lässt sich ein Automatisierungstool in die CI/CD-Pipeline integrieren, um digitale Signaturen zu erstellen.

Unit-Tests zur Sicherheitsvalidierung

Mit Unit-Tests können Entwickler die Qualität und das Ergebnis einer kleinen funktionalen Softwareeinheit überprüfen. So wird sichergestellt, dass jeder Teil des Codes wie erwartet ausgeführt wird. Unit-Tests werden vor allem verwendet, um die Integrität und Funktionalität des Codes zu testen. Sie lassen sich aber auch gezielt zur Sicherheitsvalidierung einsetzen.

Unit-Tests können jeden Codeausschnitt auf bekannte Schwachstellen prüfen, die bei der Threat-Modeling-Analyse erkannt wurden. Dadurch eignen sie sich als Ergänzung des Threat-Modeling-Prozesses.

Infrastructure as Code (IaC) analysieren

Mit Infrastructure as Code (IaC) können DevOps-Teams den angestrebten Endzustand der erforderlichen Infrastruktur definieren und ihn mithilfe eines vorlagenbasierten Ansatzes bereitstellen. Jede Public-Cloud-Plattform bietet proprietäre IaC-Tools, etwa Azure (ARM Templates und Bicep), AWS (CloudFormation) und GCP (Deployment Manager).

Für Multi-Cloud-Umgebungen können Unternehmen eine plattformübergreifende Lösung wie HashiCorp Terraform in Betracht ziehen. Damit entfällt die Komplexität, mehrere Vorlagensprachen erlernen zu müssen. Wenn die meisten Mitglieder Ihres DevOps-Teams aus der Entwicklung kommen, könnte Pulumi eine hervorragende Alternative sein. Statt Vorlagen zu verwenden, arbeitet Pulumi mit Codebibliotheken und tatsächlichem Programmcode. Dabei werden verschiedene verbreitete Sprachen wie JavaScript, Python und DotNet unterstützt. Außerdem werden mehrere Cloud-Plattformen unterstützt.

IaC-Vorlagendateien ähneln dem Quellcode einer Anwendung: Sie enthalten Definitionskomponenten, Variablen und Verknüpfungen zu anderen Artefakten. Deshalb sollten wir auch auf IaC alle sicherheitsorientierten Optimierungen anwenden. Auch hier ist die Automatisierung dieser Sicherheitsprozesse effektiv. So automatisiert Snyk die Analyse von Sicherheitslücken in IaC, damit DevOps-Teams Sicherheitslücken schnell und effizient untersuchen können.

Automatisiertes Scannen auf Schwachstellen

Mit dem Scannen auf Schwachstellen können DevOps-Engineers Sicherheitsprüfungen als Teil des CI/CD-Prozesses integrieren. In diesem Zusammenhang erfolgt das Scannen in der Regel in Form von Static Application Security Testing (SAST) oder Dynamic Application Security Testing (DAST).

Zunächst scannt SAST den ruhenden Quellcode und überprüft ihn im Rahmen der Quellcodeverwaltung detailliert. Anschließend kann ein weiterer Scan auf Schwachstellen erfolgen, sobald der Code kompiliert und mit Softwarepaketen verknüpft wurde. Dabei wird der Quellcode auf Sicherheitsbedrohungen untersucht und es werden zusätzliche Pakete wie Docker-Container oder Softwarebibliotheken gründlich gescannt. Schließlich kommt DAST zum Einsatz, sobald eine Anwendung veröffentlicht wurde. Dabei wird die Sicherheit der laufenden Anwendung getestet, ohne den Quellcode zu scannen. So werden die Aktionen eines Hackers oder böswilligen Akteurs nachgeahmt und die Schutzmaßnahmen des Codes überprüft.

Eine Vielzahl von Tools kann beim Scannen von Code oder bei der Automatisierung von Scans helfen. So bietet Snyk leistungsstarke Funktionen für Codesicherheit und Code-Scanning für die heute verfügbaren gängigen DevOps-Tools und -Plattformen.

Kontinuierliche Sicherheit

Dies sind einige wichtige Aspekte, wenn es darum geht, Sicherheitskontrollen in jeden DevOps-Zyklus zu integrieren. Sie entsprechen dem branchenweit etablierten Konzept, Sicherheit „nach links zu verschieben“, also Sicherheitskontrollen so früh wie möglich im DevOps-Prozess einzuführen.

Das Ergebnis ist eine Praxis der kontinuierlichen Sicherheit, die jeden Teil des Entwicklungszyklus schützt. Mit Strategien wie diesen können DevOps-Teams Sicherheitspraktiken weiterentwickeln und Development und Operations (DevOps) zu Development, Security und Operations (DevSecOps) erweitern.

DevSecOps betont, dass Sicherheitsvalidierungsmechanismen früh in der Entwicklung und in jeder Phase von DevOps integriert werden sollten. So kann Threat Modeling bereits in der Architekturphase beginnen. Sicherheitsscans können in die Quellcodeverwaltung und den Build-Prozess einfließen, und die Sicherheit lässt sich während der Veröffentlichung sowie zur Laufzeit der operativen Workloads validieren.

Kontinuierliche Sicherheit kann und sollte ein fester Bestandteil des Softwareentwicklungslebenszyklus sein.

CI/CD-Praktiken optimieren – und die Sicherheit

CI/CD-Prozesse dienten traditionell dazu, die Geschwindigkeit von Software-Releases zu optimieren. Sie können jedoch auch äußerst nützlich sein, wenn sie in Sicherheitspraktiken integriert und zu einer vollständig sicherheitsbewussten CI/CD-Pipeline ausgebaut werden. Angesichts der sich ständig weiterentwickelnden Cyberbedrohungen und Cyberangriffe erfordert der Schutz des Softwarelebenszyklus heute mehr denn je einen aktiven Sicherheitsansatz.

Zu den hilfreichen Sicherheitsrichtlinien für DevSecOps-Engineering-Teams gehören automatisiertes Threat Modeling, SBOMs, Artefaktsignierung und automatisiertes Scannen auf Schwachstellen. Mit solchen Strategien können Sie sich der kontinuierlichen Sicherheitsüberwachung annähern. So profitiert Ihr Unternehmen nicht nur von schnelleren Software-Releases, sondern auch von Releases, bei denen Best Practices für Sicherheit berücksichtigt werden.