Ausnutzbarkeit ist nicht die Antwort. Entscheidend ist die Behebbarkeit.

Das AppSec-Paradoxon: Warum beheben wir nicht mehr Schwachstellen?

Warum beheben Entwickler nicht jede AppSec-Schwachstelle sofort nach ihrer Entdeckung? Die häufigste Antwort lautet: Zeit. Moderne Sicherheitstools können Tausende Schwachstellen in einer Codebasis aufdecken. Alle zu beheben, würde die gesamte Kapazität eines Entwicklungsteams beanspruchen und stünde oft in Konkurrenz zur Entwicklung neuer Funktionen und anderen Prioritäten.

Doch der Zeitaufwand für die Behebung von Schwachstellen hat sich in den letzten Jahren verändert. Früher waren die Untersuchung eines Befunds, das Erlernen der erforderlichen Abhilfe und die manuelle Codeänderung oft Aufgaben für den ganzen Tag. Heute übernehmen Automatisierung und KI-gestützte Tools einen Großteil dieser Arbeit und bereiten Codeänderungen innerhalb der Zeit vor, die für eine Tasse Kaffee benötigt wird. Bei SCA-Schwachstellen besteht die Behebung oft lediglich darin, Pakete von bekanntermaßen anfälligen Versionen auf neuere Versionen zu aktualisieren, in denen die CVEs behoben sind.

Wenn also Zeit nicht mehr der Engpass ist, was dann? Vertrauen. Entwickler ignorieren Fixes nicht, weil sie Sicherheitsprobleme nicht beheben wollen. Häufig zögern sie, weil sie Angst haben, ihren Code zu beschädigen.

Breakability: das fehlende Glied bei der Priorisierung

Damit Teams mit größerer Sicherheit Prioritäten setzen können, führen wir eine neue Funktion für Snyk Open Source ein: Breakability Risk.

In der ersten Phase von Breakability stand eine Frage im Mittelpunkt, die sich Entwickler täglich stellen: Wird meine App beeinträchtigt, wenn ich den von Snyk empfohlenen Fix anwende? Jedes Dependency-Update birgt ein gewisses Risiko. Ein scheinbar einfaches Update einer Paketversion kann API-Änderungen mit sich bringen, durch die Ihr Code nicht mehr kompiliert. Schlimmer noch: Die Methodensignaturen der API bleiben möglicherweise gleich, doch subtile Verhaltensänderungen führen dazu, dass Ihr Code zwar weiterhin kompiliert, aber zur Laufzeit fehlschlägt.

Häufig verwenden zwei oder mehr direkte Dependencies dieselbe transitive Dependency. Wenn mehrere direkte Dependencies auf dasselbe zugrunde liegende Paket angewiesen sind, kann die Aktualisierung eines Teils Ihres Dependency-Graphen zur Behebung einer CVE zu einem neuen Inkompatibilitätsproblem mit einer anderen Gruppe Ihrer Dependencies führen. Das gefürchtete Problem der „Dependency-Hölle“.

Breakability Risk zeigt, welche Updates Sie sofort gefahrlos anwenden können und bei welchen eine genauere Prüfung erforderlich ist.

Vertrauen stärkt die Sicherheit

Wir haben Experimente zur Breakability-Analyse durchgeführt und die Ergebnisse sind eindeutig. Wenn Entwickler wissen, dass das Risiko, ihre Anwendungen zu beeinträchtigen, gering ist, führen sie einen Fix deutlich häufiger zusammen. In unseren Experimenten wurden Updates mit geringem Breakability-Risiko viermal so häufig zusammengeführt wie Änderungen mit höherem Risiko.

Unsere Analyse zeigt, dass etwa ein Drittel aller Fixes in die Kategorie mit geringem Breakability-Risiko fällt. Für den durchschnittlichen Snyk-Kunden könnte die Priorisierung dieser Updates mit geringerem Risiko bedeuten, dass jedes Jahr Tausende zusätzliche Schwachstellen behoben werden.

Breakability in der Praxis: geringes und hohes Risiko

Snyk zeigt jetzt direkt in Ihren Pull Requests ein Merge-Risiko-Label an, damit Sie Prioritäten setzen und die Behebung beschleunigen können. Snyk Open Source stellt Details und kontextbezogene Risikobewertungen bereit und unterstützt die Weiterbildung von Entwicklern mit Lernressourcen von Snyk Learn.

Szenario 1: Der „schnelle Erfolg“

In diesem Szenario hat Snyk Open Source einen Pull Request erstellt, der ein Team auf eine neuere Version von [libxmljs2] umstellen soll, um mehrere ReDoS-Schwachstellen (Regular Expression Denial of Service) zu beheben.

• Analyse: Das Upgrade entfernt hauptsächlich die Unterstützung für veraltete Node.js-Versionen

• Breakability Risk: Snyk kennzeichnet dieses Update als Merge-Risiko: niedrig, da es keine wesentlichen Verhaltensänderungen gibt

• Fazit: Klicken Sie auf die Schaltfläche. Sichern Sie den Code. Weiter geht’s.

Szenario 2: „Mit Vorsicht fortfahren“

Hier behebt ein Update für [i18n] Prototype Pollution, bringt jedoch einen Architekturwechsel von einem globalen Singleton zu einem instanzbasierten Setup mit sich.

• Analyse: Das grundlegende Nutzungsmuster der Bibliothek hat sich geändert.

• Breakability Risk: Snyk kennzeichnet dieses Update aufgrund der grundlegenden Architekturänderungen in der Bibliothek als Merge-Risiko: hoch.

• Fazit: Führen Sie den Merge erst durch, nachdem Sie Ihren eigenen Code überprüft und die erforderlichen Änderungen vorgenommen haben.

Eine neue Hierarchie für die Behebung

Die erste Frage in jedem Behebungs-Workflow sollte unserer Meinung nach einfach sein: Kann ich dieses Problem mit minimalem Aufwand und minimalem Risiko beheben?

Wenn ja, beheben Sie das Problem. Breakability ermöglicht es Teams, zuerst Updates mit geringem Risiko umzusetzen. So können sie mit einem einzigen Klick ein Drittel oder sogar bis zur Hälfte ihres CVE-Rückstands beheben. Wenn die Angst, „etwas zu beschädigen“, wegfällt, können Teams einen erheblichen Teil ihres Rückstands selbstbewusst abbauen und seit Jahren bestehende Sicherheitsdefizite beheben – ohne ihren Entwicklungsaufwand zu erhöhen und bei gleichzeitig reduziertem Sicherheitsrisiko.

Snyk verzichtet weder auf Reachability noch auf den Risk Score.

So wertvoll Reachability als Perspektive für die Priorisierung auch ist, es macht einen großen Unterschied, ob man sagt: „Diese Schwachstelle ist definitiv und zweifelsfrei nicht erreichbar“ oder „Es wurde kein erreichbarer Pfad für diese Schwachstelle gefunden“. Der zweite Fall ist weitaus häufiger als der erste. Sie sollten keinesfalls davon ausgehen, dass „kein erreichbarer Pfad gefunden“ bedeutet, dass es keinen erreichbaren Pfad gibt – insbesondere in einer Welt, in der Angreifer KI-Hacking-Tools einsetzen, um Schwachstellen schneller als je zuvor zu finden und auszunutzen. Statt das Risiko von Paketen aufgrund möglicherweise nicht erreichbarer Schwachstellen hinzunehmen, machen wir es Ihnen leichter, sie einfach zu beheben – auch hier ohne das Risiko negativer Nebenwirkungen.

Breakability und die Snyk AI Security Fabric

Dieses neue Behebungsparadigma ist entscheidend für die Weiterentwicklung der AI Security Fabric. Wie im Prescriptive Path to Operationalizing AI Security beschrieben, hilft Breakability Ihnen, die Risikoreduzierung zu optimieren, indem es Vertrauen in vorgeschlagene Fixes schafft. So gehen Sie über reine Priorisierungskriterien hinaus und etablieren einen vorhersehbaren, vertrauensbasierten Prozess. Teams können dadurch schneller mehr Fixes zusammenführen und müssen weniger Angst vor Änderungen haben, die etwas beeinträchtigen könnten.

Starten Sie mit Breakability

Die erste Phase von Breakability ist jetzt als Snyk Preview-Funktion für alle Snyk Open Source-Kunden verfügbar. Aktivieren Sie die Funktion, um ab sofort Risikobewertungen zu Breaking Changes in Ihren von Snyk generierten Pull Requests zu sehen. Wir freuen uns, wenn Sie die Funktion ausprobieren und uns Ihre Meinung mitteilen!

Möchten Sie überdenken, wie Sie Schwachstellen mit größerer Sicherheit priorisieren und beheben? Erfahren Sie, wie KI-gestützte Erkenntnisse Teams dabei helfen, über die Erkennung hinauszugehen und Risiken planbar und skalierbar zu reduzieren. Laden Sie noch heute unser E-Book From Shift Left to Secure at Inception herunter.