Anwendungssicherheit heißt mehr als nur „Shift Left“ DevSecOps – den Code knacken

Cyberkriminelle entwickeln immer neue Angriffsstrategien. In agilen Development-Prozessen dienen deshalb DevSecOps-Methoden wie das Shift-Left-Testing dazu, potenzielle Schwachstellen möglichst früh zu eliminieren. Doch warum sind solche Strategien nicht immer von Erfolg gekrönt?

Die Praxis der Anwendungsentwicklung hat sich stetig weiterentwickelt. Heute liefern Entwicklungsteams Anwendungen in schnellerem Tempo ab als jemals zuvor. Parallel dazu haben Cyberkriminelle neuartige Angriffsstrategien entwickelt und ihren Fokus intensiviert. Entwicklungs- und Sicherheitsteams haben mit dem sogenannten „Shift Left“ reagiert – das heißt, sie bauen Sicherheit zu einem früheren Zeitpunkt im Entwicklungsprozess ein. Und sie investieren in entsprechende Testtools.

The Enterprise Strategy Group (ESG) hat jüngst im Auftrag von Synopsys eine Studie zu DevSecOpsdurchgeführt. Demnach gehen viele der Befragten davon aus, dass verbesserte DevOps-Integrationen die Antwort auf das Problem sind. Für 43 Prozent ist dies eines der wichtigsten Dinge, um AppSec-Programme zu verbessern. 58 Prozent der Unternehmen wiederum räumen der Applikationssicherheit bei den Investitionen in die Sicherheit höchste Priorität ein.

E-Book zum Thema

Das eBook „DevOps und Security“ erläutert die Unterschiede von DevSecOps, SecDevOps und DevOpsSec und befasst sich mit dem Warum und Wie.

eBook herunterladen

Doch trotz dieser nicht unbeträcht­lichen Investi­tionen kämpfen Firmen auch weiterhin mit einer Reihe von Heraus­forderungen. Entwicklern fehlt an dieser Stelle oft das nötige Wissen – und auch die Integration zwischen verschiedenen AppSec-Tools ist alles andere als trivial. Dazu kommen Reibungsverluste, welche die Entwicklungs­geschwindigkeit verlangsamen.

Das Tempo, mit dem die digitale Transformation voranschreitet, bringt Entwicklungsteams in eine Zwickmühle: Sie sind gezwungen, zwischen Time-to-Market-Anforderungen und Risikominderung zu entscheiden. Trotz laufender Investitionen in AppSec-Programme räumen acht von zehn Unternehmen ein, Änderungen an Anwendungen mitsamt der bekannten Schwachstellen voranzutreiben.

Neue Methoden, neue Herausforderungen

Software-Anwendungen sind inzwischen zu einem Anker für die Interaktionen zwischen Kunden und Handel geworden. Um in einer schnelllebigen, digitalen Wirtschaft wettbewerbsfähig zu bleiben, brauchen Unternehmen ein hohes Maß an Geschwindigkeit und Agilität. Das hat den Druck auf die Entwicklungsteams enorm erhöht.

Um die Entwicklungsgeschwindigkeit zu erhöhen, wird auch hier investiert: in Cloud-native Architekturen, agile Entwicklungspraktiken und DevOps-/GitOps-Automatisierung. Alles Strategien, die eine schnellere Bereitstellung erlauben. Die Sache hat aber einen Preis, denn Software wird immer komplexer. Und das bringt für AppSec-Teams neue Herausforderungen mit sich.

Moderne AppSec-Programme sind denn auch ein unübersichtlicher Mix aus manuellen und automatisierten Tools und Praktiken. Applikationsschwachstellen sind bekanntermaßen ein großes Cybersicherheitsrisiko. Dieser Fakt motiviert Investitionen in AppSec-spezifische Sicherheitsressourcen, automatisierte Testtools zur Schwachstellenbewertung und Sicherheitsschulungen für Entwickler. Tatsächlich geben 71 Prozent der Befragten an, AppSec-Tools für über 50 Prozent ihrer Codebasis zu verwenden. 69 Prozent der Befragten bewerten die Effektivität ihres Programms mit acht oder höher auf einer Skala von eins bis zehn.

Um mit den sich beschleunigenden Entwicklungszyklen Schritt zu halten, arbeiten Sicherheitsteams daran, Sicherheit vorzuziehen (Shift left) und Probleme früher im Entwicklungsprozess aufzudecken. Die DevOps-Integration automatisiert einen Großteil des Bewertungsprozesses und sorgt für mehr Konsistenz. Ohne eine manuelle Triage und Priorisierung durch Entwicklungs- und Sicherheitsanalytiker kommt man aber dennoch nicht aus.

Trotz laufender Aufwendungen haben viele Unternehmen, Schwierigkeiten, AppSec-Programme effektiv zu implementieren und zu betreiben. Das gilt insbesondere für Firmen, die große Anwendungsportfolios managen. Sicherheitstests in Entwicklungs-Toolchains und Workflows zu integrieren und zu automatisieren ist unerlässlich. Dem werden wohl die meisten zustimmen. Die Diskrepanz zwischen der Geschwindigkeit von Build- und Testaktivitäten führt aber in der Praxis nicht selten dazu, dass sich die Entwicklungsgeschwindigkeit verlangsamt.

Entwicklungsstrategien schreiten schnell voran, AppSec-Strategien hinken hinterher. Die ESG-Untersuchung hat einige der zentralen Knackpunkte aktueller AppSec-Strategien identifiziert:

Zu viele Ergebnisse

Ein einzelner Scan durch ein „Application Security Testing“- oder kurz AST-Tool fördert Hunderte oder sogar Tausende von Ergebnissen zutage. Teams, die vollständige AST-Scans in ihre CI-Pipelines integriert und automatisiert haben, stehen oft vor dem Problem, die schiere Menge und Duplizität von Ergebnissen aus verschiedenen Stadien des SDLC zu bewältigen. Zwar stellt nur kleiner Prozentsatz ein so hohes Risiko dar, dass es sofort behoben werden muss. Aber schon allein die Schwachstellen mit hoher Priorität zu identifizieren und zu priorisieren ist Belastung genug.

Starke Ausbreitung von Tools und Scans

Drei von zehn Befragten gaben an, dass sie von der Anzahl der verwendeten Test-Tools regelrecht erschlagen werden. 26 Prozent der Unternehmen sagen, dass die Gesamtheit der verwendeten AppSec-Tools Entwicklungsprozesse behindert und die Entwicklungsgeschwindigkeit beeinträchtigt.

Lange Scanzyklen

Die Geschwindigkeit bei der Anwendungsentwicklung ist inzwischen so hoch, dass herkömmliche AppSec-Ansätze nicht mehr mithalten können. Build-Pipelines sollen nicht selten in einem Takt von Sekunden bis zu wenigen Minuten laufen. Scans mit AppSec-Tools beanspruchen mindestens mehrere Minuten bis hin zu Stunden. Das Problem verschärft sich weiter, weil oftmals unterschiedliche Formen der Analyse (z.B. SAST, SCA, etc.) durchgeführt werden müssen. Entwicklungsteams stehen dann vor dem Problem, dass die Applikationssicherheit die Geschwindigkeit der Pipeline beeinträchtigt.

Schlecht abgestimmte Risikomodelle

Sicherheitstools werden nicht selten auf sämtliche Anwendungsänderungen angewendet, unabhängig vom Risikoprofil. Wenn klare Richtlinien fehlen, welche Bewertungstools für unterschiedliche Risikoszenarien zum Einsatz kommen sollen, wird meist pauschal verfahren. Das hat gleich mehrere unerwünschte Folgen.

Bei Anwendungen mit einem hohen Risiko sind die Tests unzureichend, während man gleichzeitig Zeit und Ressourcen für Änderungen verschwendet, mit denen lediglich ein geringes Risiko verbunden ist. AST-Tools enthalten zwar häufig Funktionen, um Richtlinien durchzusetzen und Schwachstellen zu melden. In der Regel handelt es sich dabei aber um isolierte Implementierungen, die typischerweise an verschiedenen Stellen im SDLC eingesetzt werden.

Zu viele Exploits

Obwohl sie mehrere AppSec-Tools einsetzen, räumen 81 Prozent der Unternehmen ein, dass bereits Schwachstellen in ihren Anwendungen ausgenutzt wurden, 60 Prozent davon in den letzten 12 Monaten aufgrund von OWASP-Top-10 Schwachstellen.

Eine simple Integration und Automatisierung von Sicherheitstest-Tools in CI-Pipelines, um kontinuierliche Tests zu gewährleisten, wird den Anforderungen der modernen Anwendungsentwicklung nicht gerecht. Wir brauchen offensichtlich ein neues AppSec-Modell. Anders ausgedrückt: Software-Sicherheit behindert die DevOps-Geschwindigkeit. Also sollten Unternehmen genau diesen Ansatz modernisieren.

AppSec-Strategien sollten einem risiko- und bedarfsorientierten Sicherheitsansatz folgen. Anwendungsänderungen mit einem höherem Risiko werden strenger kontrolliert, während Sicherheitstests in Bereichen mit geringerem Risiko zurückgestellt werden. Diese risikobasierten Kontrollen sollten sich intelligent und nahtlos in den DevOps-Kern integrieren, ohne die Entwicklungsgeschwindigkeit zu beeinträchtigen.

E-Book zum Thema

Das eBook „DevOps und Security“ erläutert die Unterschiede von DevSecOps, SecDevOps und DevOpsSec und befasst sich mit dem Warum und Wie.

eBook herunterladen

Sowohl Sicherheits­abteilung als auch Entwicklungs­team müssen die Möglich­keit haben, sich an den Sicherheits­zielen auszurichten und sie zu erreichen. Die Lösung sollte individuelle Risiko­profile berück­sichtigen und sie mit Sicherheits­richtlinien und -profilen abgleichen. Danach entscheidet sich, welche automatisierten und manuellen Kontrollen angewendet werden und auch wann.

Sicherheitsteams stehen mit dem Shift-Left-Ansatz unter hohem Druck, ihre Tools und Prozesse in die zunehmend automatisierte Welt der Softwareentwicklung zu integrieren. Traditionelle AppSec-Strategien können mit modernen Entwicklungspraktiken nicht mithalten. Geschwindigkeit spielt bei der Anwendungsentwicklung in einer digitalen Wettbewerbslandschaft eine immer wichtigere Rolle. Es gilt einen Weg zu finden, Änderungen schnell zu implementieren, damit Entwicklungsteam keinen Kompromiss zwischen Lieferdatum und Sicherheitsanforderungen eingehen müssen.

Ohne die Möglichkeit schneller Änderungen wird das Risiko schnell eskalieren. DevOps muss sich von den Reibungsverlusten der Applikationssicherheit befreien, damit Entwickler ihrerseits Fortschritte nutzen können, die ihrerseits höhere Geschwindigkeiten und Skalierung erlauben.

Wer trägt die Verantwortung?

Einen entscheidenden Teil des Puzzles haben wir bislang noch unberührt gelassen: Das Thema Verantwortung. Wer ist für die Implementierung von DevSecOps verantwortlich, und wer stellt sicher, dass alle Beteiligten bei jedem Schritt mitziehen? Man muss dazu den Begriff des „Shift Left“ richtig verstehen. Es reicht nicht, sich für ein Tool zu entscheiden und es auf der linken Seite des SDLC einzusetzen.

Die Idee des Shift Left ist es, so früh wie möglich auf den Status der Sicherheit Einfluss zu nehmen, und das nicht nur auf der äußersten linken Seite, sondern im gesamten SDLC. Die weitaus zutreffendere Bezeichnung lautet daher „Shift Everywhere“. Das bedeutet, so früh wie möglich auf den Stand der Sicherheit zuzugreifen und Sicherheitsprüfungen über den gesamten SDLC hinweg durchführen. Diese Überprüfungen funktionieren wie ein Durchgang. Ohne ordnungsgemäße Freigabe kann man nicht von einer Stufe des SDLC auf die nächste übergehen.

Nach dieser Lesart sollten weder Entwickler noch Sicherheitsteams allein für den Sicherheitsstatus einer Software verantwortlich sein. Üblicherweise ist es der Verantwortungsbereich des Sicherheitsteams, der innerhalb des Entwicklungszyklus zum Flaschenhals wird. Schlicht, weil sämtliche Tests der Anwendungssicherheit auf die Sicherheitsabteilung entfallen. Und die sind personell deutlich schlechter bestückt als die Entwicklerseite.

Das Modell kommt spätestens in der DevSecOps-Welt an seine Grenzen. Die Verantwortung für die Implementierung der Prozesse, aber auch dafür, dass sie verständlich sind und befolgt werden, sollte in der Managementkette deshalb so weit oben angesiedelt sein wie möglich – also beim CISO oder CTO. Er oder sie zeichnet für die gesamte Operation verantwortlich, auch für eine funktionierende Umsetzung.

Die technischen Möglichkeiten

Auf dieser Basis kann man dann die richtigen Werkzeuge in den entsprechenden Phasen einsetzen, um Bedrohungen zu erkennen und zu entschärfen. Ein Entwickler, der beispielsweise ein, in seine IDE integriertes SAST-Tool (Static Application Security Tool) nutzt, erkennt Schwachstellen bereits während des Programmierens und kann Bedrohungen frühzeitig beseitigen.

Die Verwendung eines SCA-Tools (Software Composition Analysis) in der Build-Kette identifiziert alle anfälligen Komponenten innerhalb einer Software, einschließlich ihrer direkten oder transitiven Abhängigkeiten. Dann beseitigt man die gefundenen Bedrohungen oder sogar die anfälligen Komponenten, bevor man das Produkt freigibt.

Funktionale Tests mit einem IAST-Tool (Interactive Application Security) ermitteln, ob die Software so arbeitet wie sie sollte oder ob eine gerade getestete Funktion vielleicht möglichen Angriffen die Tür öffnet. Ein Schwachstellen-Management-System schließlich hilft Ihnen, alle Risiken zu konsolidieren und die Schwachstellen effektiv zu sortieren, um sich zuerst auf die wichtigsten Bedrohungen konzentrieren zu können.

Wer sich mit dieser Aufgabe überfordert fühlt, sollte sich nicht scheuen, Prozessdefinition und -implementierung an externe Dienstleister auslagern. Deren Sicherheitsexperten übernehmen in der Regel auch die Schulung der internen Teams und entwickeln mit ihnen gemeinsam Entwicklungsprozesse und -verfahren die zukünftig eine sichere Softwareentwicklung gewährleisten.

* Boris Cipot ist Senior Security Engineer bei der Synopsys Software Integrity Group.

E-Book zum Thema

DevOps und Security

Sicherheit sollte eng mit den DevOps-Prozessen integriert und gleich zu Beginn der Entwicklung berücksichtigt werden. Die Frage lautet, wie man eine Veränderung am besten umsetzt, die Organisation und die Unternehmenskultur betrifft.

Dieses eBook umfasst die folgenden Themen:

• Wozu DevOps um Security erweitern?
• DevSecOps, SecDevOps und DevOpsSec
• DevSecOps: So geht es in der Praxis

eBook „DevOps und Security“ herunterladen

(ID:47551658)