Warum „Schwachstellenmanagement“ in der modernen Anwendungssicherheit zu kurz greift

Angesichts der wachsenden Komplexität von Softwareentwicklungsumgebungen sowie zunehmender Cyberbedrohungen und regulatorischer Anforderungen sehen sich AppSec-Teams mit einer Vielzahl herausfordernder Aufgaben konfrontiert.

Die Einführung und anschließende Verbreitung von „Shift Left“-Methoden war zwar ein bedeutender und notwendiger Schritt nach vorn, doch inzwischen ist klar, dass dieser Ansatz auch einen Wandel der Denkweise erfordert. Selbst mit „Shift Left“ gibt es in AppSec-Programmen zu viele blinde Flecken, um eine wirksame Zusammenarbeit zwischen Sicherheits- und Entwicklungsteams bei der Reduzierung von Anwendungsrisiken sicherzustellen.

Den Erfolg des AppSec-Programms zu bestimmen, Entwicklerinnen und Entwicklern bei der Priorisierung von Fehlerbehebungen zu helfen und ungesicherte Anwendungen zu erkennen – das sind nur einige der Herausforderungen, die den Weg für neue AppSec-Ansätze ebnen.

„Schwachstellenmanagement“ für AppSec einsetzen

Einer dieser Ansätze ist stark vom Schwachstellenmanagement inspiriert – einer etablierten, breit angelegten Methodik und Lösungskategorie der Cybersicherheit. Ihr Schwerpunkt liegt darauf, Sicherheitsprobleme in verschiedenen Bereichen eines Unternehmens zu identifizieren, zu bewerten, zu dokumentieren, zu überwachen und zu beheben, etwa bei Endgeräten, Netzwerken, Systemen und – besonders wichtig – Anwendungen.

Die Bezeichnung für diesen neuen Ansatz hat sich im Laufe der Zeit weiterentwickelt: von Application Security Orchestration and Correlation (ASOC) über Application Security Posture Management (ASPM), um sich an Markttrends anzupassen. Die zugrunde liegenden Prinzipien sind jedoch gleich geblieben.

Dieser Ansatz, der von immer mehr Anbietern unterstützt wird, soll einen „Single Pane of Glass“ bieten, der Sicherheitsprobleme im gesamten AppSec-Programm zusammenführt und miteinander in Beziehung setzt. Durch die Integration verschiedener Quellen erhalten AppSec-Teams einen einheitlichen Überblick über den Sicherheitsstatus ihrer Anwendungen. Die Einbindung von Tools für das Vorfallmanagement und die Reaktion auf Sicherheitsvorfälle soll zudem die Automatisierung und operative Umsetzung von Priorisierungs- und Behebungsprozessen verbessern.

Fallstricke von „Schwachstellenmanagement“ für AppSec

Ein auf Schwachstellenmanagement basierender Ansatz für AppSec bietet durchaus Vorteile und unterstützt bestimmte Ergebnisse für bestimmte Rollen innerhalb eines Unternehmens. Ein SecOps-Team kann beispielsweise von einer vereinfachten Übersicht der Sicherheitsprobleme und automatisierten Workflows für das Reaktionsmanagement profitieren. Wie gut sich damit jedoch moderne Anwendungssicherheit verwalten und skalieren lässt, ist fraglich, denn der Ansatz greift in zwei entscheidenden Punkten zu kurz.

1. Fehlender Anwendungskontext

Wie bereits erwähnt, sollen auf Schwachstellenmanagement basierende AppSec-Ansätze eine zentrale Übersicht über alle Sicherheitsprobleme bieten, die von den im Programm eingesetzten Application-Security-Testing-Tools (AST) erkannt wurden, etwa SAST, SCA, DAST, IaC und weitere.

Das zentrale Problem (Wortspiel beabsichtigt!) besteht darin, dass diese einheitliche Übersicht von den zusammengeführten Daten abhängt, die hauptsächlich aus den zahlreichen integrierten AST-Tools von Drittanbietern stammen. Diese Daten werden über öffentliche APIs der Anbieter abgerufen und unterscheiden sich je nach Quelle in Format und Struktur. Daher müssen sie zunächst mit hohem manuellem Aufwand normalisiert und standardisiert werden, bevor sie miteinander in Beziehung gesetzt werden können. Das bringt eine entscheidende Herausforderung mit sich: Der daraus entstehende Überblick bietet oft zu wenig Kontext zur Anwendung – etwa zu ihrer Bedeutung für das Unternehmen, ihrer Architektur, ihren Assets und ihrem Laufzeitverhalten. Dadurch fällt es AppSec-Teams schwer, Risiken richtig einzuschätzen und gemeinsam mit Entwicklerinnen und Entwicklern die Behebungsmaßnahmen dort zu konzentrieren, wo sie wirklich gebraucht werden.

Die starke Abhängigkeit von Daten Dritter führt zu einem fragmentierten oder unvollständigen Bild des Sicherheitsstatus einer Anwendung. Dadurch wird es für AppSec-Teams schwieriger, fundierte Entscheidungen zu treffen und Entwicklerinnen und Entwickler gezielt zu den passenden Fehlerbehebungen anzuleiten. Trotz der vermeintlichen Vorteile einer zentralen Übersicht über Sicherheitsprobleme stellen die inhärenten Einschränkungen eines auf Schwachstellenmanagement basierenden Ansatzes erhebliche Hürden für eine robuste Anwendungssicherheit dar.

2. Schlechte Developer Experience

Damit AppSec- und Entwicklungsteams Einblicke in Anwendungsrisiken erhalten, müssen Entwicklerinnen und Entwickler die ihnen bereitgestellten AST-Tools aktiv nutzen. Sobald Probleme erkannt, bewertet und priorisiert wurden, müssen sie außerdem zeitnah Korrekturen in ihrer Codebasis umsetzen. Werden die Sicherheitstools nicht angenommen, bleibt dieser Kreislauf unterbrochen – ein wahrscheinliches Ergebnis, wenn die Tools Sicherheitsprozesse nicht nahtlos in den Entwicklungsworkflow integrieren, sondern Hindernisse schaffen und zusätzliche Reibung verursachen.

Lösungen für Anwendungssicherheit, die den Prinzipien des Schwachstellenmanagements folgen, sind in der Regel tool-unabhängig. Sie konzentrieren sich vor allem darauf, Probleme aus verschiedenen AST-Tools in einer zentralen Übersicht zusammenzuführen, und sind oft nicht in die Workflows der Entwicklerinnen und Entwickler eingebunden. Das führt zu zusammenhanglosen und ineffektiven Prozessen für Priorisierung und Behebung. Die Developer Experience leidet, und die ohnehin angespannte Zusammenarbeit zwischen AppSec- und Entwicklungsteams verschlechtert sich weiter. Ohne die aktive Beteiligung und Unterstützung der Entwicklerinnen und Entwickler wird jedes AppSec-Programm Schwierigkeiten haben, denn die AppSec-Funktion läuft Gefahr, als Gegenspielerin statt als Verbündete wahrgenommen zu werden.

So unterstützt Snyk AppRisk

Snyk war Vorreiter bei Entwickler-zentrierten AST-Tools, um Anwendungssicherheit frühzeitig und durchgängig in den SDLC zu integrieren. Seit der Gründung hat das Unternehmen entwicklerzentrierte Anwendungssicherheit in großen Organisationen weltweit etabliert. Um die verbleibenden Herausforderungen bei der erfolgreichen Verwaltung und Skalierung eines modernen „Shift Left“-Ansatzes für Anwendungssicherheit anzugehen, wurde Snyk AppRisk als zusätzliche Ebene der Developer-Security-Plattform von Snyk eingeführt. Die Lösung unterstützt AppSec-Teams bei der Erkennung und Übersicht von Anwendungen, dem Management der Testabdeckung und der risikobasierten Priorisierung.

Snyk AppRisk verlagert den Schwerpunkt von AppSec-Programmen: weg von der Verwaltung einzelner Sicherheitsprobleme und hin zu einer umfassenderen Betrachtung des Anwendungsrisikos. Statt nur Schwachstellen und Sicherheitslücken zu behandeln, berücksichtigt dieser anwendungszentrierte Ansatz auch die Architektur, Assets und das Laufzeitverhalten einer Anwendung. So entsteht ein möglichst umfassendes Verständnis ihrer Sicherheitsrisiken. Unternehmen können Sicherheitsmaßnahmen dadurch nach der Bedeutung der Anwendung für das Geschäft und ihren potenziellen Auswirkungen auf Nutzer und Daten priorisieren.

Snyk AppRisk ergänzt die entwicklerzentrierten AST-Produkte von Snyk – Snyk Code, Snyk Open Source, Snyk Container und Snyk IaC – um eine Ebene für AppSec-Übersicht, Governance und Priorisierung. Diese nahtlose Integration und Interoperabilität ermöglicht zwei entscheidende Ergebnisse. Erstens werden Anwendungsrisiken frühzeitig im Entwicklungszyklus erkannt und verhindert, während präzise und zeitnahe Sicherheitsanalysen in Snyk AppRisk einfließen. Zweitens werden neue Risiken effektiv priorisiert und von Entwicklerinnen und Entwicklern mit Unterstützung durch Sicherheitsleitlinien behoben – mit konkreten Handlungsempfehlungen und nur dort, wo es nötig ist.

Weitere Informationen zu Snyk AppRisk finden Sie auf unserer Website oder in unserer Produktdokumentation.