Ohne einen Dependency Graph über Code, Container und Cloud hinweg sind Sie blind für echte Schwachstellen

Sie wissen, dass Ihre Anwendungen nicht in einer Blase existieren. Sie bestehen aus Open-Source-Paketen, Containern, Cloud-verwalteten Ressourcen, VMs, APIs und vielem mehr. Jeder Teil hat seine eigene Sicherheitsfläche und seinen eigenen Scanner: statische Codeanalyse (SAST) suchen nach Schwachstellen im Quellcode, Software-Kompositionsanalyse SCA) suchen nach Abhängigkeiten, Cloud-Sicherheit überwachen Konfigurationen und container suchen nach bekannten Exploits in Images.
‍
Wenn Sie also all diese Scanner eingerichtet haben, sind Sie sicher, oder?
‍
Irgendwie schon. Sie scannen definitiv jede Ebene.
‍
Aber zu welchem Preis?

Warum Sicherheitsscanner Sie mit Fehlalarmen überhäufen

Ein Scanner könnte Sie auf eine anfällige Funktion in Ihrem Code aufmerksam machen, ohne zu wissen, dass diese durch eine Upstream-API geschützt ist. Oder er könnte eine Gefahr durch eine CVE in einer container erkennen, ohne zu wissen, dass Ihre eigentliche Anwendung diesen Codepfad niemals erreicht. Ebenso könnte ein Cloud-Scanner eine IAM-Rolle markieren, die ihre Berechtigungen überschreitet, ohne zu erkennen, dass sie nur mit einer Staging-Workload verknüpft ist, die keinen Zugriff auf Produktionsdaten hat.

Das Ergebnis? Ihre Teams werden mit einer Flut von isolierten Erkenntnissen überschwemmt. Ja, diese sind technisch gesehen alle korrekt, aber sie enthalten kaum Kontextinformationen, anhand derer sich feststellen lässt, ob das Problem wirklich gefährlich ist.
‍
Oder wie es ein Sicherheitsingenieur eines großen Unternehmens kürzlich formulierte:„Können Sie sagen, ob eine Schwachstelle meine Kronjuwelen oder das virtuelle Mittagsmenü betrifft?“

Während falsch-positive und falsch-negative Ergebnisse für sich genommen ein Risiko darstellen, besteht das größere Risiko darin, Abhängigkeitsketten zu übersehen, die darüber entscheiden, ob scheinbar harmlose Probleme zu echten Exploit-Pfaden führen – oder ob viele scheinbar schädliche Probleme gar kein Problem darstellen.

Und wir hören es ständig von den Teams:

„Wir haben keine Kontrolle über unsere Abhängigkeiten.“

Der Grund? Die Verwaltung der Lieferkette ist zu anspruchsvoll; Open-Source-Pakete bringen indirekte Abhängigkeiten mit sich. Selbst mit container oder Cloud-nativen Tools können die meisten Unternehmen nicht mit Sicherheit feststellen, was wichtig ist. Infolgedessen reagieren sie nur reaktiv auf Schwachstellen.

Warum der Kontext der Schwachstellen für die Anwendungssicherheit und Cloud wichtig ist

Der typische SAST oder SCA -Tools verfolgen einen sehr simplen und wörtlichen Ansatz.

Wenn beispielsweise festgestellt wird, dass ein Paket in einer CVE aufgeführt ist, wird es als kritisch gekennzeichnet.

Auf dem Papier klingt das nach einer bewährten Vorgehensweise; schließlich ist es besser, Risiken zu vermeiden, könnte man meinen. In der Realität löst dies jedoch nur Fehlalarme aus, denn:

• Oftmals ruft Ihre Anwendung die anfällige Funktion gar nicht auf.
• Die Funktion könnte in einer transitiven Abhängigkeit verborgen sein, die Sie nie direkt berührt haben.
• Oder es steckt hinter einem Import, der nur für Entwickler gedacht ist und nie in die Produktion gelangt.

So erhalten Teams eine übermäßig ausführliche Liste „kritischer“ Probleme und müssen Stunden damit verbringen, diese zu bearbeiten, nur um dann festzustellen, dass sie gar nicht kritisch sind.

Gleichzeitig können die tatsächlich ausnutzbaren Pfade unbemerkt bleiben.

Erstellen eines vollständigen Abhängigkeitsgraphen für Code, Container und Cloud

Der Grund, warum viele Scanner verrauschte oder unvollständige Ergebnisse liefern, ist, dass ihnen der zusätzliche Kontext fehlt, der für Klarheit sorgt. Herkömmliche Tools behandeln jede Ebene – Quellcode, Open-Source-Pakete, Container, Cloud-Ressourcen – als separates Problem, das oft von separaten Produkten gelöst wird.

Das bedeutet, dass ihnen ein einziger Abhängigkeitsgraph fehlt, der sie alle vereint. Es gibt keine Sichtbarkeit der gegenseitigen Abhängigkeiten. Das bedeutet, dass Sie über nicht kritische Probleme benachrichtigt werden und möglicherweise die Probleme übersehen, die tatsächlich wichtig sind.

Bei der Sichtbarkeit geht es jedoch nicht nur um den Kontext, sondern auch um Konsistenz. Paketmanager verwalten transitive Schwachstellen unterschiedlich.

Zum Beispiel:

• npm/yarn in JavaScript bieten Abhängigkeitsbäume und ermöglichen es Ihnen, verschachtelte Pakete zu überschreiben/festzulegen.
• Maven in Java kann unerwartete Bibliotheksversionen einbinden, sodass zusätzliche Konfigurationen erforderlich sind, um riskante transitive Pakete fernzuhalten.

Ohne einen einheitlichen Überblick greifen Teams letztendlich auf immer mehr Tools zurück, nur um einen Überblick über das zu bekommen, was sie ausgeliefert haben.

Einige Entwickler denken: „Wenn wir es nicht direkt installiert haben, kann es uns auch nicht schaden“, was das Problem noch verschärft. Schwachstellen befinden sich in mehreren Ebenen. 

Was sollten Teams also tun?

Verwenden Sie Erreichbarkeitsanalyse Fehlalarme in Abhängigkeiten zu vermeiden.

Erreichbarkeitsanalyse echte Erreichbarkeitsanalyse bedeuten, dass Ihre Plattform nicht nur darauf hinweist, dass „Sie ein anfälliges Paket im Diagramm haben“, sondern auch herausfinden kann, ob Ihr Code:

• Tatsächlich die vulnerable Funktion aufrufen oder
• Beteiligt an einem Fehler, der Benutzereingaben ausgesetzt ist, oder
• Ausführung in einem container über das Internet zugänglich container

Wenn die Antwort auf alle diese Fragen „Nein“ lautet, wird sie ignoriert. Wenn „Ja“, wird sie eskaliert.

Es ist auch wichtig, transitive Schwachstellen hinter Entwicklerabhängigkeiten oder Testpaketen herauszufiltern, die niemals in die Produktion gelangen. Dadurch lassen sich viele Störsignale reduzieren, was weniger Fehlalarme und mehr Zeit für Entwickler bedeutet, sich auf die Softwareentwicklung zu konzentrieren.

Die meisten Scanner überprüfen möglicherweise, ob ein Paket in einer CVE aufgeführt ist. Aber nur sehr wenige können nachverfolgen, ob Ihr tatsächlicher Code die anfällige Funktion aufruft, ob sie in einem container gebündelt ist, der dem Internet container , und ob sie auf einer Cloud-Ressource mit riskantem IAM ausgeführt wird – alles in einer Ansicht.

Korrelation von Schwachstellen in Code, Containern und Cloud

Das ist das Wichtigste. Zu verstehen, was überall passiert, ist entscheidend, um Ihrem Team viel Zeit zu sparen und das Risiko zu verringern, in Schwierigkeiten zu geraten.

Das bedeutet, dass dieser Abhängigkeitsgraph über die Paketebene hinaus auf Container,Infrastructure as Code und Cloud-Konfigurationen ausgeweitet und die Erreichbarkeit über diese hinweg überlagert werden muss.

Beispielsweise könnte es fragen:

• Betrifft diese Schwachstelle Ihre Abhängigkeiten? Ja
• Wird es tatsächlich von Ihrer App aufgerufen? Nein
• Ist es in einem bereitgestellten container öffentlichem Ingress gebündelt? Nein
  → Ignorieren
• Muss für diese Schwachstelle ein bestimmter Port geöffnet sein? Ja
• Ist die Schwachstelle in einer virtuellen Cloud-Maschine vorhanden? Ja
• Ist der erforderliche Port auf der VM geöffnet? Nein
  → Ignorieren

automatische Behebung: Echte Schwachstellen schneller beheben

Sobald eine echte, erreichbare Schwachstelle bestätigt wurde, besteht das ideale Szenario darin, das minimal sichere Upgrade zu ermitteln und es automatisch zu beheben.

Einige Tools können:

• Automatisch das minimal sichere Upgrade ermitteln
• Überprüfen Sie, ob Ihre Semver-Einschränkungen nicht verletzt werden.
• Automatische Korrektur ohne Regressionen

Das bedeutet keine manuelle Abhängigkeitsverfolgung und weitaus weniger schlaflose Nächte.

Verwalten Sie Abhängigkeiten als Teil einer einheitlichen Sicherheitsstrategie

Indem Sie Ihren Code, Ihre Container und Ihre Cloud-Konfigurationen in einem Diagramm zusammenfassen, reduzieren Sie Störfaktoren und sehen, was tatsächlich offengelegt wird. Keine Jagd nach Fehlalarmen mehr.

Und wenn es ein echtes Problem gibt, wird es nicht nur gemeldet, sondern auch behoben. So verbringt Ihr Team weniger Zeit damit, sich durch sinnlose Warnmeldungen zu wühlen, und hat mehr Zeit für die Auslieferung.
‍
Erfahren Sie in unserer Dokumentation, wie Aikido Entwicklungsabhängigkeiten auf CVEs Aikido . Informieren Sie sich hier über unser Schwachstellenmanagement.

​