DevSecOps: Integration von Entwicklung, Betrieb und Sicherheit

DevSecOps ist ein neues Kunstwort, das die Begriffe DevOps und Sec (als Abkürzung für Security) miteinander verbindet. DevOps selbst kombiniert die Bereiche Development (Entwicklung) und Operations (Betrieb).

Der Begriff DevSecOps beschreibt die enge Integration von Sicherheitsaspekten in den gesamten Entwicklungs- und Betriebsprozess moderner IT-Systeme. Durch die Automatisierung im Build-Management, die Software-Versionierung und die Bereitstellung (Deployment) auf verschiedenen Plattformen und Umgebungen entstand eine wichtige Rolle: die Verbindung von Programmierung, Konfigurationsmanagement und dem Übergang in den produktiven Betrieb.

Im klassischen Entwicklungsprozess waren Entwicklung (Development) und Betrieb (Operations) oft voneinander getrennt. Dies führte zu Ineffizienzen, besonders in der Kommunikation und Zusammenarbeit. Entwickler mussten sich häufig über die Verfügbarkeit und Konfiguration der Infrastruktur informieren, während Betriebssystems tiefere Einblicke in die Programmierlogik benötigten, um Fehler zu beheben oder Deployments durchzuführen.

Die Evolution von DevOps zu DevSecOps

Die Einführung von DevOps zielte darauf ab, diese Lücke zu schließen. Durch die Automatisierung von CI/CD-Prozessen (Continuous Integration und Continuous Delivery) wurden Entwicklungs- und Betriebsprozesse enger verzahnt. Die DevOps-Rolle ermöglicht es, Aufgaben wie Softwareversionierung, Paketierung, Qualitätssicherung (z. B. mit Tools wie SonarQube) und die Bereitstellung auf verschiedenen Plattformen in einer einzigen Rolle zu bündeln. Entwickler und Betriebs- Teams wurden so entlastet.

Mit der zunehmenden Verbreitung von verteilten Systemen und Cloud-Umgebungen wurde jedoch klar, dass Sicherheit (Security) ebenfalls ein integraler Bestandteil dieser Prozesse sein muss. Software birgt immer potenzielle Schwachstellen – von den verwendeten Tools und Schnittstellen bis hin zu statischen und dynamischen Komponenten. Deshalb wurde die Rolle von DevOps durch DevSecOps erweitert, um IT-Sicherheitsaspekte nahtlos in den gesamten Entwicklungsprozess zu integrieren.

Warum DevSecOps?

Die Integration von Sicherheit in die DevOps-Prozesse bietet entscheidende Vorteile:

• Reduzierung von Sicherheitsrisiken: Sicherheitsüberprüfungen sind von Anfang an Teil des Entwicklungsprozesses.
• Schnellere Reaktionszeiten: Intrusion-Detection-Systeme und andere Sicherheitsvorfälle können schneller erkannt und bearbeitet werden.
• Effizientere Kommunikation: DevSecOps-Teams arbeiten interdisziplinär und reduzieren Reibungsverluste zwischen Entwicklung, Betrieb und Sicherheit.

Durch den Einsatz von automatisierten Sicherheitstools (z. B. Snyk, OWASP, ZAP, HashiCorp Vault) können potenzielle Schwachstellen frühzeitig identifiziert und behoben werden. Dies umfasst die Überprüfung von Codequalität, Abhängigkeiten und Konfigurationen.

Die ideale DevSecOps-Rolle

Die Anforderungen an eine DevSecOps-Rolle sind vielfältig:

• Tiefgehende Kenntnisse in Software Architektur und Programmierung.
• Erfahrung im Konfigurationsmanagement und in der Infrastruktur Automatisierung.
• Affinität zu IT-Sicherheit und ein Verständnis für Sicherheitsrisiken in modernen IT-Systemen.

Diese Rolle vereint die Kompetenzen von Architekten, Programmierern, Konfigurationsmanagern und Sicherheitsexperten in einer interdisziplinären Funktion.

DevSecOps ist die logische Weiterentwicklung von DevOps in einer Welt, die zunehmend von Sicherheit und Automatisierung geprägt ist. Mit der richtigen Kombination aus technischem Wissen und Sicherheitsbewusstsein kann DevSecOps die Effizienz steigern, Sicherheitslücken reduzieren und eine reibungslose Zusammenarbeit zwischen Entwicklung, Betrieb und Sicherheit gewährleisten.
 

Der Lieferketten-Angriff: LiteLLM Python Library Showcase

 Um es nicht zu abstrakt zu lassen, wird es etwas ausführlicher beschrieben und erklärt. Man spricht nicht nur von einzelnen Schwachstellen, sondern von einem „Attack Vector“, also einer Kette von Angriffen, die für sich genommen jeweils nur ein geringes Schadenspotenzial haben, deren Wirkung sich jedoch vervielfacht, wenn sie aufeinander abgestimmt sind.

Ein aktuelles gutes Beispiel für einen solchen Vektor ergibt sich im Bereich der Tooling. Intuitiv denkt man zunächst an die Haupteingänge, auf die die stärkste Abwehr konzentriert ist. Wenn es sich um ein Schloss handeln würde, gäbe es vorne ein massives Tor sowie eine Zugbrücke über den umliegenden Wassergraben. Diese dienen dazu, Angriffsversuche leichter zu erkennen, insbesondere wenn beispielsweise nachts mit großer Gewalt versucht wird, das Tor zu durchbrechen.

Der Eingang für Bedienstete und Lebensmittellieferanten, der sich weiter unten befindet, ist hingegen weniger stark geschützt, obwohl er aufgrund seiner geringeren Größe eigentlich leichter zu sichern wäre. Genau hier liegt jedoch ein Denkfehler: Der Angreifer weiß das ebenfalls und wird seinen Angriffsvektor so konstruieren, dass diese Schwachstelle gezielt ausgenutzt wird, um das stark gesicherte Haupttor zu umgehen.

Der Eingang unten in der Mauer, nahe am Wasser, zu dem kleine Boote gelangen können, ist vergleichsweise leicht zugänglich. Dennoch wagt sich meist niemand dorthin oder man geht davon aus, dass ein Eindringen mit nur wenigen Personen kaum Wirkung hätte. Das stimmt jedoch nicht, wenn diese Personen den richtigen Zeitpunkt abpassen und beispielsweise das Tor von innen öffnen, sodass die zuvor auf dem Feld versammelte Armee ungehindert eindringen kann.

Ein klassisches Beispiel dafür ist die Geschichte vom Trojanischen Pferd: Die Stadt Troja fiel letztlich nicht durch einen direkten Angriff auf ihre starken Verteidigungsanlagen, sondern durch eine List. Mehrere Soldaten versteckten sich in einem riesigen Holzpferd, das in die Stadt gebracht wurde, und überwanden so die starke erste Verteidigungslinie von innen heraus.

Stellen wir uns vor, die Tools, die im CI/CD-Prozess verwendet werden, entsprechen diesen kleinen Versorgungseingängen unten in der Mauer. Sie sind für den laufenden Betrieb essenziell, stellen jedoch nicht das primäre Angriffsziel dar. Über sie erfolgen kontinuierlich Lieferungen – zu festen Zeiten ebenso wie sporadisch nach Bedarf.

Ein Teil dieser Abläufe geschieht automatisiert, ein anderer wird bei Bedarf manuell angestoßen. Es gibt reguläre Deployments, größere Release-Rollouts und kurzfristige Hotfixes. Ähnlich verhält es sich mit der Versorgung einer Burg: Regelmäßige Lieferungen von Gemüse, Eiern und Mehl sichern den Alltag, während zu besonderen Anlässen zusätzliche Lieferungen organisiert werden.

Gerade diese Routine und Vorhersehbarkeit machen solche „Nebeneingänge“ zu einem potenziell attraktiven Angriffspunkt – insbesondere dann, wenn ihre Absicherung im Vergleich zum Haupttor weniger streng ausfällt.

Nennen wir das einen „Lieferkettenangriff“ – was es in der Realität tatsächlich ist. Innerhalb dieser Kette lassen sich beispielsweise Personen in Lieferkörben verstecken, etwa unter Kartoffeln oder Äpfeln. Vertraute Helfer sorgen dafür, dass diese Körbe unauffällig transportiert werden, sodass selbst ein erhöhtes Gewicht nicht weiter auffällt. Wer genau die Lieferung veranlasst hat, spielt dabei oft keine entscheidende Rolle mehr – der Angriff ist zu diesem Zeitpunkt bereits im Gange.

Ein solcher Angriff ist keineswegs nur theoretisch. Ähnliche Vorfälle haben sich bereits ereignet: Im Kontext von Python-Paketdownloads, die für den Bau von KI-Anwendungen – etwa mit LiteLLM – erforderlich sind, wurde ein manipuliertes Paket in die Lieferkette eingeschleust. Dieses wurde automatisch im Build-Prozess heruntergeladen und in die Anwendung integriert, ohne dass es sofort bemerkt wurde.

Zum jetzigen Zeitpunkt spricht man von mindestens 94 Million Downloads dieses manipulierten Pakets, die zudem im Rahmen automatischer Aktualisierungen erfolgt sind. Solche Updates geschehen in der Regel automatisch, sobald die Umgebung über neue Release-Versionen informiert wird – vorausgesetzt, entsprechende Einstellungen sind aktiv.

Die eingeschleuste Manipulation zielte darauf ab, sensible Informationen zu stehlen, darunter SSH-Schlüssel, Passwörter, AWS-Credentials etc. und weitere vertrauliche Daten. Die Tragweite eines solchen Vorfalls ist erheblich, da Teile der Entwicklungsprozesse, die auf bestimmten Python-Versionen und CI/CD-Pipelines basieren, sowohl in der Industrie als auch möglicherweise in Behörden im Einsatz sind.

Das tatsächliche Schadensausmaß hängt letztlich davon ab, ob und in welchem Umfang die gestohlenen Artefakte weiterverwendet wurden. Doch bereits die Möglichkeit eines solchen Zugriffs stellt einen schwerwiegenden Sicherheitsvorfall dar.

Der eigentliche Angriff erfolgt bereits beim scheinbar harmlosen Aufruf des Paketmanagers von Python, etwa durch den Befehl „pip install …“. In diesem Moment wird nicht nur das manipulierte Paket heruntergeladen und installiert – gleichzeitig wird auch der eigentliche Diebstahlprozess initiiert.

Das bedeutet: Der Angriff setzt genau dort an, wo Entwickler üblicherweise Vertrauen haben und Routine herrscht. Ein einzelner, alltäglicher Befehl genügt, um sowohl die kompromittierte Software in das System zu integrieren als auch sensible Daten unbemerkt abfließen zu lassen.

Noch gravierender wird die Situation, wenn man die möglichen Auswirkungen in Abhängigkeit von den im System vorhandenen Privilegien und Berechtigungen betrachtet. In solchen Fällen könnten Angreifer nicht nur Daten exfiltrieren, sondern auch weitergehende Aktionen durchführen – etwa das Hinterlassen von Backdoors oder Manipulationen an Servern und Netzwerkkomponenten.

Ob dies im konkreten Fall tatsächlich geschehen ist oder technisch möglich gewesen wäre, wurde bislang nicht öffentlich gemacht. Dennoch zeigt dieses Szenario deutlich das potenzielle Ausmaß: Anstelle eines „reinen“ Datendiebstahls hätte ebenso gut eine Lösch- oder Ransomware-Aktion ausgelöst werden können.

Für große Unternehmen hätte ein solcher Angriff verheerende Folgen – es sei denn, es wurden bereits im Vorfeld gezielte Investitionen in Sicherheitsmaßnahmen getätigt, um genau solche Szenarien zu verhindern oder zumindest einzudämmen.

Risiken und Verantwortlichkeiten bei CI/CD-Pipelines

Wenn man konzeptionell und organisatorisch vorsieht, dass das Installieren und Aktualisieren von Bibliotheken und Paketen – sei es in Python oder in anderen Komponenten aus externen Quellen – ausschließlich zentral, isoliert und kontrolliert erfolgt, lässt sich das Risiko deutlich reduzieren, auch wenn es sich nicht vollständig ausschließen lässt. In einem solchen Modell würden diese Vorgänge zunächst geprüft und getestet, und nur autorisierte Operatoren dürften sie nachvollziehbar und protokolliert ausführen.

Gerade in komplexen, agilen Entwicklungsumgebungen mit vielen Entwicklern sowie heterogenen System- und Toollandschaften – verteilt über mehrere Umgebungen wie Development, Test und Produktion – würde dies bedeuten, dass potenziell manipulierter Code im Idealfall nur einmal zentral ausgeführt und erkannt werden kann, anstatt sich unkontrolliert zu vervielfältigen.

Hinzu kommt, dass solche Vorfälle oft nur subtile Hinweise hinterlassen. Beispielsweise kann ein Deployment formal erfolgreich abgeschlossen sein, während im Stacktrace Warnungen erscheinen. Solche Hinweise sind etwa in Ausführungslogs sichtbar, beispielsweise in Tools wie SonarQube, werden jedoch aufgrund der schieren Menge an Logdaten nicht immer manuell geprüft – es sei denn, es existieren geeignete Filter- oder Alerting-Mechanismen, die beispielsweise automatisierte Benachrichtigungen auslösen.

Letztlich hängen diese Szenarien stark davon ab, wie DevOps- und CI/CD-Prozesse konkret umgesetzt sind. Die beschriebenen Ereignisse könnten beispielsweise innerhalb von Pipelines in GitLab, Jenkins oder vergleichbaren Systemen auftreten.

Wer kann in solchen komplexen Szenarien noch den Überblick behalten? Idealerweise sollte der DevOps-Verantwortliche in der Lage sein, die Quelle von Problemen zu identifizieren und die Erkenntnisse an die zuständigen Stellen weiterzugeben. Dabei spielt es keine Rolle, ob ein Vorfall in der Entwicklungs-, Test- oder Produktionsumgebung auftritt. Manchmal liegen die Ursachen auch zwischen den Bereichen Technik und Fachabteilung – beispielsweise wenn Testergebnisse aus einem Durchlauf auf Datenebene zunächst nicht eindeutig zugeordnet werden können.

Zum Schluss möchte ich eine solche Landschaft in Überschriften darstellen, wie man sie auch realistisch in der Wirtschaft vorfindet. Ich halte es überschaubar, damit der Fokus nicht verloren geht.

Der Architekt kennt das gesamte System und dessen Aufbau, denkt auch an die Sicherheit und tauscht sich regelmäßig mit IT-Security-Fachkollegen aus. Der DevSecOps-Mitarbeiter kennt die Build-Management-Prozesse, weiß aber auch genau, wo welche Komponenten auf Projektseite und in den Entwicklungsumgebungen laufen – kategorisiert und spezifisch.

Präsentationsfall – Systemübersicht:

• Entwicklung: Frontend-Anwendung mit Angular, Backend mit Java Spring Boot, wobei Microservices in eigenen Servlet-Engines innerhalb von Docker-Containern laufen und von Kubernetes orchestriert werden, verwaltet über OpenShift.
• Deployment: OpenShift verwendet Helm, um Anwendungen logisch und deskriptiv zusammenzufassen. Microservices laufen in einer AWS-Cloud-Umgebung für die Produktion; Entwicklung und Test erfolgen in getrennten On-Premise-Umgebungen.
• Daten und Caches: Oracle-Datenbanken, REDIS-Caches.
• Entwicklungsumgebungen: Visual Studio Code, Eclipse, IntelliJ IDEA, Visual Studio, zusätzlich Legacy-Code über JNLP und C++.
• Bibliotheken und Frameworks: Frameworks für Bildbearbeitung, semantische Verarbeitung wie Apache Jena, Bibliotheken zur Verarbeitung von Microsoft-Dateien aus Java-Code wie Apache POI.
• Updates und Versionierung: Alle Daten und Artefakte haben Release-Versionen und erhalten regelmäßig Updates; viele liegen sowohl als Quellcode als auch als Binärdateien vor.
• Konfigurationen und Schnittstellen: Zahlreiche Konfigurationsdateien, Schnittstellen und Integrationen.

Wer behält hier noch den Überblick? Genau an dieser Komplexität zeigt sich, wie wichtig ein strukturiertes Vorgehen, klare Rollen und Sicherheitsbewusstsein in DevOps/DevSecOps-Teams sind.

Integration von DevSecOps-Praktiken

Ein DevSecOps-Mitarbeiter integriert in den Pipelines und CI/CD-Prozessen Mechanismen und Programme, die konfigurierte QA-Tools enthalten, welche auch Sicherheitsaspekte prüfen. Außerdem bewertet er, ob andere Tools hilfreich sein könnten.

Die Fülle und Menge an Log-Output sollte automatisiert geparst werden, um zwischen normalen Warnungen und Fehlern potenzielle Angriffe erkennen zu können. Schon öfter zeigt sich, dass der Einsatz von statischen und dynamischen Code-Analyzern, automatisierten Unit-Tests und Systemen wie SonarQube als Beispiel sehr hilfreich ist, um Anomalien frühzeitig zu erkennen. Solche Tools liefern Hinweise auf Schwachstellen oder unerwartetes Verhalten, die sonst im Rauschen der Logs untergehen würden. In Kombination mit automatisierten Parsing- und Alert-Mechanismen lassen sich so potenzielle Sicherheitsvorfälle oder Fehlerquellen effizient identifizieren, bevor sie im produktiven Betrieb kritisch werden.

Darüber hinaus könnte KI zur Hilfe gerufen werden, beispielsweise über OpenAI, um komplexe Sachverhalte besser zu analysieren. Aufgaben, die manuell stündlich oder täglich aufgrund des Aufwands nicht möglich wären, können so effizient unterstützt und priorisiert werden.

Hier zeigt sich deutlich, dass eine ständige Interaktion zwischen Architektur, Netzwerk, Infrastruktur, Entwicklung, Test und Produktion stattfindet. Die Verantwortung hängt jedoch immer von der Rollendefinition und den konkreten Aufgaben ab.

Dabei passiert nicht alles auf einmal, und niemand erledigt alles allein von Grund auf. Vielmehr sollte die Arbeit systematisch, geplant und kontinuierlich erfolgen.

Ziel dieses Abschnitts ist nicht, jeden Aspekt abzudecken, sondern einen Eindruck davon zu vermitteln, wie komplex große Systeme sein können und welche kritische Rolle ein DevSecOps-Verantwortlicher innehat – auch wenn sein Titel zunächst harmlos erscheint.

Der Showcase, den ich behandelt habe, greift ein bekanntes neues Problem im KI-Bereich auf, bei dem Python eingesetzt wird – ein Thema, das vielen Unternehmen aktuell bewusst ist. Die Beispiele zeigen, wie sensibel DevOps-Prozesse sein können und welche Konzepte sinnvoll sind.