Über „Shift Left“ hinaus: AppSec in alle Richtungen erweitern

Eine Woche vor der RSA 2024 sagte Forrester voraus, welche Themen und Schwerpunkte auf der Konferenz im Mittelpunkt stehen würden. Das Unternehmen betonte, dass proaktive Sicherheit im Fokus stehen werde. Darunter versteht es „einen strategischen Ansatz, um die Sicherheitslage zu kontrollieren und Sicherheitsverletzungen durch umfassende Transparenz, Priorisierung und Behebung zu reduzieren“.

Mit dieser Prognose im Hinterkopf ging ich auf die Konferenz. Doch ich war überrascht von dem, was ich vorfand. Leider sah ich weiterhin viele Anbieter, die sich fast ausschließlich auf die Sichtbarkeit von Schwachstellen konzentrierten und andere Aspekte proaktiver Sicherheit, die Forrester in der obigen Definition nennt, außer Acht ließen.

Ein proaktiver Sicherheitsansatz ist jedoch für die heutigen Sicherheits- und Entwicklungsteams unverzichtbar. Viele dieser Teams sind bereits von der Reaktivität bestehender Prozesse überfordert und müssen mit blinden Flecken im gesamten SDLC umgehen. Sicherheitsteams konzentrieren sich dadurch auf die falschen Probleme und übersehen die kritischsten. Zudem können sie Entwicklungsprozesse behindern und gleichzeitig Lücken für unbekannte Risiken offenlassen. Ein reaktiver Ansatz zwingt Entwickler außerdem dazu, lange Listen nicht priorisierter Warnmeldungen und übermäßig starre Sicherheitsmaßnahmen zu bewältigen. Der wachsende Fokus der Branche auf Apps und die zunehmende Nutzung von KI werden all diese Probleme noch verschärfen.

Teams benötigen heute wirksame proaktive Sicherheit, die auf fundierte Priorisierung und Behebung setzt, statt sich ausschließlich auf Transparenz zu konzentrieren. Außerdem muss die Transparenz selbst auf der richtigen Ebene ansetzen – stärker bei Assets wie Anwendungen und nicht nur bei einer zusammengefassten Sicht auf Schwachstellen.

Doch wie können wir als Branche diesen Ansatz überwinden, der sich „nur auf Transparenz“ konzentriert? Vielleicht müssen wir unsere Vorstellung davon ändern, was „Shift Left“ bedeutet. Es geht nicht nur darum, Sicherheit innerhalb eines zweidimensionalen Kontinuums der Softwareentwicklung früher umzusetzen, sondern vielmehr um einen multidirektionalen Sicherheitsansatz. Auf der RSA begann ich, über dieses Konzept anhand eines metaphorischen Kompasses nachzudenken. Was wäre, wenn wir uns statt auf eine Bewegung nach links darauf konzentrierten, Sicherheit in alle Richtungen zu erweitern: nach Norden, Süden, Osten und Westen?

Multidirektionale Anwendungssicherheit

Wenn wir unsere Anwendungssicherheit auf all diese metaphorischen Bereiche ausdehnen, erhalten wir bessere Transparenz und mehr Kontext zu allem, was im gesamten SDLC geschieht. So könnte dieser Ansatz funktionieren:

Norden

Sicherheitsteams nutzen in ihren AppSec-Programmen verschiedene Tools für Application Security Testing (AST), etwa statische Anwendungssicherheitstests (SAST) und die Software Composition Analysis (SCA). Üblicherweise verlassen sie sich auf eine Drittanbieterlösung, die sämtliche Schwachstellendaten aus diesen separaten Tools zusammenführt und analysiert und so den Erfolg des Programms bewertet.

Viele Aggregationstools konzentrieren sich jedoch ausschließlich auf die Anzahl der Schwachstellen und übersehen dadurch wichtige Kontextinformationen, etwa den ganzheitlichen Anwendungs- und Geschäftskontext. Um die Leistung ihrer Anwendungssicherheitsprogramme im Zeitverlauf zu verstehen, müssen Teams über gängige Messwerte wie die Anzahl der Schwachstellen und die Zeit bis zu ihrer Behebung hinausgehen. Stattdessen sollten sie wertvolle Analysen zu den Problemen, der Abdeckung und geschäftsspezifischen Assets heranziehen. Nach Norden zu blicken bedeutet, die gesamte Anwendung und ihren Kontext aus der Vogelperspektive zu betrachten, statt jede Schwachstelle als isoliertes Problem zu sehen.

Süden

Entwicklungs- und Sicherheitsteams benötigen außerdem einen besseren Kontext zu jeder Sicherheitswarnung. Dies lässt sich als die Richtung „Süden“ unseres multidirektionalen Ansatzes verstehen: In jeder Entwicklungsphase geht es darum, tiefer in den Sicherheitskontext einzutauchen. Herkömmliche Risikobewertungen wie das Common Vulnerability Scoring System (CVSS) berücksichtigen nicht alle Daten, die nötig sind, um wirklich zu verstehen, wie groß oder gering das Risiko einer bestimmten Schwachstelle für das Unternehmen ist und wer für die Behebung der dringendsten Probleme verantwortlich ist.

Stattdessen müssen Teams bei jeder Warnung die folgenden Faktoren berücksichtigen:

• Wie geschäftskritisch ist die Anwendung, in der sich die Schwachstelle befindet?

• Gibt es weitere Faktoren, die die Kritikalität der Schwachstellen beeinflussen (z. B. Cloud-Infrastruktur-Sicherheit, die den betreffenden Code zusätzlich schützt)?

• Wer hat den betreffenden Code erstellt und kann Fehler am besten beheben?

• Welcher Asset-Typ enthält die Schwachstelle? Diese Information kann Entwicklungsteams dabei helfen, den besten Weg zur Behebung des Problems zu finden.

Osten

Um sich ein besseres Bild vom Risiko zu machen, müssen Unternehmen auch die Runtime-Sicherheit in den Blick nehmen – die Richtung „Osten“ unseres Ansatzes. Dieser Kontext hilft Sicherheitsteams zu verstehen, welcher Code zur Laufzeit von der Anwendung verwendet wird und welche Assets kaum oder gar kein Risiko darstellen, weil sie im laufenden Betrieb der App nicht zum Einsatz kommen. Mithilfe dieses Runtime-Kontexts können Teams die Liste der Schwachstellen weiter eingrenzen, da er Fehlalarme zu Schwachstellen ausschließt, die keine Gefahr für die laufende Anwendung darstellen.

Westen (d. h. links)

Die Branche diskutiert den Shift-Left-Sicherheitsansatz schon seit einiger Zeit. Das Ziel, Probleme früh im Entwicklungslebenszyklus zu beheben, muss sich jedoch mit den sich wandelnden Entwicklungsprozessen weiterentwickeln. Die Bedeutung von „links“ wird sich weiter verändern. Sicherheitsteams müssen ihre Tools und Prozesse daher an die Arbeitsweisen der Entwicklungsteams anpassen.

Sicherheitsteams stellen beispielsweise heute fest, dass sie schneller arbeiten müssen, weil Entwickler KI-Codeassistenten einsetzen, um Code in nie dagewesener Geschwindigkeit zu generieren. Damit Shift Left mit diesen Veränderungen in der Entwicklung Schritt hält, setzen viele Sicherheitsteams auf KI-Sicherheitstools, um diese rasante Flut neuen Codes abzusichern, ohne die Innovationskraft der Entwickler zu bremsen.

Der multidirektionale Sicherheitsansatz von Snyk

Wir bei Snyk haben einen Ansatz für Anwendungssicherheit entwickelt, der alle vier Richtungen abdeckt. Diese multidirektionale Strategie hat unseren Kunden bereits Erfolge beschert, etwa eine höhere Produktivität der Entwickler und eine allgemeine Risikoreduzierung.

Unser neuestes Angebot für Application Security Posture Management (ASPM), Snyk AppRisk Pro, bietet eine verbesserte Risikoerkennung und Priorisierung mit erweiterten Runtime-Analysen, zusätzlichen Integrationen in Entwicklungsplattformen, neuer Kompatibilität mit Tools zur Erkennung von Secrets und umfassenden Datenanalysefunktionen.

Erfahren Sie noch heute mehr über Snyk AppRisk Pro.