Vor über zehn Jahren prägte Sicherheitsexpertin Shannon Lietz den Begriff DevSecOps. Das Ziel: die IT-Sicherheit stärker in die Softwareentwicklung zu integrieren. Dabei stellt sich die Frage, ob DevSecOps-Teams inzwischen über die kulturellen und praktischen Tools verfügen, um Technologien schneller und dabei zuverlässig und sicher in die Produktion zu überführen.

Eine aktuelle SANS-Umfrage zum Thema zeigt, dass die Entwicklung diesbezüglich Fahrt aufgenommen hat:

• 50 Prozent geben an, kritische Sicherheitsrisiken und Schwachstellen innerhalb von sieben Tagen oder schneller zu beheben.

• Fast 30 Prozent der Befragten geben an, wöchentlich zu deployen - allerdings evaluieren oder testen lediglich 20 Prozent Schwachstellen mit ähnlich hoher Geschwindigkeit.

• Die Akzeptanzrate für DevSecOps-Praktiken liegt bei 61 Prozent mit Blick auf Automatisierung und bei 50 Prozent, wenn es um Continuous Integration (CI) geht.

Die Ergebnisse zeigen: Immer mehr Unternehmen streben danach, die Sicherheit nach links zu verlagern. Mit ersten positiven Resultaten unter den Befragten. Allerdings gibt es auf dem Weg zu Security-Reife und Continuous Deployment noch einige Herausforderungen zu meisten. Insbesondere wenn es darum geht, Sicherheitspraktiken zu priorisieren.

3 Best Practices für DevSecOps-Teams

Bei der Entscheidung darüber, welche Sicherheitspraktiken bei Shift-Left-Initiativen priorisiert werden sollten, gilt es, diverse Faktoren zu berücksichtigen. Beispielsweise:

• Geschäftsziele,

• Risiken,

• Entwicklungsgeschwindigkeit,

• Tech-Stack sowie

• Compliance-Anforderungen.

Die folgenden drei Best Practices sollten DevSecOps-Teams und -Initiativen entscheidend weiterbringen.

1. Sichere API-First-Strategien entwickeln

Spätestens seit dem berüchtigten API-Mandat von Amazon-Boss Jeff Bezos haben Entwicklungsteams erkannt, wie wichtig API-First-Strategien sind. Schnittstellen sind insbesondere von grundlegender Bedeutung, wenn es darum geht, Datenprodukte und datengetriebene Geschäftsmodelle aufzubauen. Darüber hinaus eröffnen sie auch neue Möglichkeiten, speziell mit Blick auf Open Machine Learning und Large Language Models (LLMs).

Wie wichtig es dabei ist, die APIs auch abzusichern, zeigt eine aktuelle Analyse des Sicherheitsanbieters Wallarm. Demnach wurden im dritten Quartal 2023 insgesamt 239 API-Schwachstellen identifiziert - von denen 33 Prozent mit Autorisierung, Authentifizierung und Access Control in Verbindung stehen. "Dieser Trend unterstreicht die zunehmende Relevanz der API-Sicherheit bei DevOps. Dieser Aspekt muss unbedingt angegangen werden, wenn robuste und sichere Softwareentwicklungsprozesse gewährleistet und die gewünschten Geschäftsergebnisse erzielt werden sollen", kommentiert Ivan Novikov, CEO bei Wallarm, die Ergebnisse.

Der Umfang und die Geschwindigkeit, mit der große DevSecOps-Teams APIs und Microservices entwickeln, legt nahe, dass vielen Unternehmen eine Umstellung auf sicherheitsorientierte API-Strategien gut tun würde.

2. Code-Scans automatisieren

Code auf Schwachstellen zu scannen, war früher ein manueller Prozess, der im Rahmen von Pair-Programming-Disziplinen ablief oder zu einem späteren Zeitpunkt im Entwicklungsprozess stattfand. Heutzutage stehen DevSecOps-Teams zahlreiche Tools für statische Codeanalysen zur Verfügung - auch bekannt als SAST (Static Application Security Testing)-Tools.

Diese Tools können viele gängige Entwicklerfehler aufdecken, die unter Umständen hohe Sicherheitsrisiken bergen, wie Kyle Tobener, Head of Security und Information Technology beim DevOps-Spezialisten Copado, unterstreicht: "Geheime Informationen, die versehentlich im Quellcode offengelegt wurden, waren in den letzten Jahren häufig eine Ursache für Sicherheitsvorfälle. Indem Sie entsprechende Tools in Ihre DevOps-Pipeline integrieren, können Sie Passwörter und API-Keys im Quellcode identifizieren und verhindern, dass diese kompromittiert werden."

Dan Garcia, CISO beim Softwareanbieter EDB, empfiehlt DevSecOps-Teams, neben SAST- auch DAST (Dynamic Application Security Testing)-Tools einzusetzen: "Diese Tools unterstützen Sie dabei, automatisierte Bedrohungstechniken gegen die Laufzeitumgebung zu fahren und ermöglichen Ihnen, ihre Testabdeckung zu skalieren, wenn Ihre Plattform erweitert wird."

Wenn Sie in Softwareentwicklung, Cloud-Native-Architektur und CI/CD-Pipelines investieren, gibt es keine Entschuldigung dafür, nicht auch Code-Scanning-Funktionen zu integrieren.

3. Data-Observability-Praktiken standardisieren

Anwendungsprotokollierung war lange Zeit der einfachste Weg, um Observability-Daten zu erhalten. Inzwischen stehen dafür eine Vielzahl von Tools und noch mehr Datenquellen zur Verfügung, die Entwickler und Site Reliability Engineers dabei unterstützen, Einblick in die Performance von Anwendungen in produktiven Umgebungen zu erhalten.

Worin dabei die wesentliche Herausforderung liegt, weiß Jeremy Burton, CEO beim Monitoring-Spezialisten Observe, Inc.: "Die meisten Tools, die zur Fehlerbehebung in modernen, verteilten Applikationen eingesetzt werden, arbeiten isoliert und sind ursprünglich eher für die Analyse von Protokollen, die Überwachung von Metriken oder die Visualisierung von Traces konzipiert. Für die Datenmengen, die heutzutage üblich sind, sind sie nicht ausgelegt."

Abhilfe schaffen an dieser Stelle spezielle Observability-Lösungen oder -Plattformen, beispielsweise:

• Application Monitoring Tools,

• AIOps-Plattformen oder

• SRE-Werkzeuge.

DevSecOps-Teams sollten darüber hinaus den Scope der Observability ganz gezielt um zwei Bereiche erweitern:

1. Das betrifft zum einen die Security Observability, die den gesamten Tech-Stack abdecken sollte - inklusive Applikationen, Integrationen und Cloud-Infrastruktur.

2. Zum anderen sollten Observability-Methoden auch in den Bereichen Dataops und MLops Anwendung finden, da sich Probleme in diesen Bereichen auch auf Zuverlässigkeit, Performance und Security auswirken können.

Angesichts der Vielzahl von Methoden, Tools und Risiken, die sich durch Observability-Optimierungen adressieren lassen, ist die entscheidende Frage für DevSecOps-Teams: Wo sollen Standards geschaffen werden?

Wenn jede Anwendung, jede Daten-Pipeline und jedes ML-Modell unterschiedliche Benennungskonventionen, Praktiken und Tools in Sachen Observability verwendet, wird es für SREs und Security Operations Center (SOCs) deutlich schwieriger, Sicherheitsprobleme schnell zu erkennen und zu lösen. (fm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.