Eine kritische Schwachstelle wird veröffentlicht, die Sicherheitsmeldung verbreitet sich, und innerhalb einer Stunde fragt jemand im Firmenchat: Sind wir betroffen? Log4Shell hat diese Frage berühmt gemacht. CVE-2021-44228 betraf Log4j Core von 2.0-beta9 bis 2.15.0, eine Bibliothek, die mehrere Ebenen tief im Abhängigkeitsbaum unzähliger Java-Produkte steckte, und die meisten Teams mussten mühsam herausfinden, wo sie war.

Die Frage klingt einfach. Tatsächlich sind es drei Fragen:

  1. Ist die verwundbare Komponente in irgendetwas enthalten, das wir bauen oder ausliefern?
  2. Falls ja: Lässt sie sich in unserem Produkt ausnutzen?
  3. Seit wann und in welchen Releases?

Die meisten Prozesse beantworten die ersten beiden. Die dritte stellen Kunden, Auditoren und Aufsichtsbehörden als Nächstes, und sie ist im Nachhinein am schwersten zu beantworten.

Schritt 1: Herausfinden, ob die Komponente vorhanden ist

Unternehmen kommen meist auf einem von vier Wegen zu einer Antwort, grob nach Reifegrad geordnet.

Herumfragen und suchen. Jemand schreibt in Slack, Entwickler durchsuchen ihre Repositories und Lockfiles nach dem Paketnamen, und eine Tabelle sammelt die Antworten. Das ist immer noch die häufigste Methode. Sie ist langsam, hängt davon ab, wer antwortet, und übersieht alles, was nicht in einer Datei deklariert ist: Abhängigkeiten von Abhängigkeiten, Vendored-Bibliotheken, Basis-Images, während des Builds installierte Tools.

Die Scanner-Dashboards prüfen. Abhängigkeitsscanner melden die CVE innerhalb weniger Stunden pro Repository. Das geht schneller, aber ein Scanner berichtet über den Code, der ihm heute vorliegt, meist den Default-Branch. Er sagt Ihnen nicht, welche Releases Ihre Kunden einsetzen oder was ein Build vor drei Monaten tatsächlich geladen hat.

Ein SBOM-Inventar abfragen. Teams, die für jedes Release eine Software Bill of Materials führen, können eine Frage über alle hinweg stellen: Welche Produkte und Versionen enthalten die betroffenen Versionen dieses Pakets? Das ist die erste Methode, die für ausgelieferte Software antwortet und nicht nur für Software im Repository.

Kontinuierlich abgleichen. Werden SBOMs laufend gegen Schwachstellendaten überwacht, liegt die Liste der betroffenen Produkte vor, bevor jemand fragt. Der Chatverlauf beginnt mit der Antwort statt mit der Frage.

Die Qualität jeder Methode hängt davon ab, was das Inventar tatsächlich enthält. Die üblichen blinden Flecken sind:

  • Transitive Abhängigkeiten. Das verwundbare Paket ist selten eines, das Sie selbst hinzugefügt haben. Es kommt drei oder vier Ebenen tiefer ins Spiel.
  • Alles, was das Manifest nicht deklariert. Von Build-Skripten installierte Pakete, npx-Tools, Dockerfile-Schritte, wiederhergestellte Caches und Vendored-C- und C++-Code.
  • Alte Releases. Ein Branch, der sich nicht mehr bauen lässt, kann nicht erneut gescannt werden, aber das daraus gebaute Produkt ist womöglich noch im Einsatz.

Schritt 2: Entscheiden, ob es relevant ist

Eine Komponente kann vorhanden sein, ohne ein echtes Risiko darzustellen. Der nächste Schritt ist deshalb die Triage:

  • Version und Konfiguration. Liegt die Version genau im betroffenen Bereich? Ist die verwundbare Funktion einkompiliert und aktiviert?
  • Erreichbarkeit. Ruft Ihr Code die verwundbare Funktion überhaupt auf?
  • Exposition. Ist die Komponente aus dem Netzwerk oder über nicht vertrauenswürdige Eingaben erreichbar, oder wird sie nur zur Build-Zeit verwendet?
  • Gegenmaßnahmen. Gibt es Sandboxing, eine Netzwerkbeschränkung oder eine Konfiguration, die den Exploit blockiert?
  • Hinweise auf Ausnutzung. CVSS gibt den Schweregrad an, EPSS schätzt die Wahrscheinlichkeit, dass eine CVE in den nächsten 30 Tagen ausgenutzt wird, und der Known Exploited Vulnerabilities Catalog der CISA listet die bereits aktiv ausgenutzten auf. Zusammen entscheiden sie, was zuerst geprüft wird.

Schritt 3: Die Entscheidung festhalten

Das Ergebnis wird pro Produkt und Version festgehalten, zunehmend als VEX-Aussage (Vulnerability Exploitability eXchange). Die Mindestanforderungen der CISA an VEX definieren vier Status: not affected, affected, fixed und under investigation. Eine Aussage mit dem Status not affected muss begründen, warum, zum Beispiel weil der verwundbare Code nicht vorhanden ist oder ein Angreifer ihn nicht erreichen kann.

Diese Aufzeichnung fließt in alles Weitere ein: den Fix und die Releases, die ihn enthalten, den Sicherheitshinweis für Kunden und jede Meldung, die eine Aufsichtsbehörde erwartet. Nach dem EU Cyber Resilience Act zum Beispiel muss ein Hersteller innerhalb von 24 Stunden, nachdem er davon Kenntnis erlangt hat, eine Frühwarnung zu einer aktiv ausgenutzten Schwachstelle in seinem Produkt abgeben.

Schritt 4: Das Expositionsfenster bestimmen

„Sind wir betroffen?“ hat eine zweite Hälfte, die oft übersprungen wird: Wie lange waren wir betroffen?

Die Schwachstelle bestand lange, bevor die CVE veröffentlicht wurde. Log4Shell steckte seit Version 2.0-beta9 in Log4j, die Jahre vor der Offenlegung erschienen war. Ihre Exposition begann an dem Tag, an dem ein Build zum ersten Mal eine verwundbare Version geladen hat, und sie endete an dem Tag, an dem der letzte Build ersetzt wurde, der sie enthielt. Dieses Fenster brauchen Sie, um:

  • Kunden zu sagen, welche der von ihnen eingesetzten Releases betroffen sind, nicht nur das neueste
  • eine Vorfallsuntersuchung auf den richtigen Zeitraum einzugrenzen, falls die Schwachstelle ausgenutzt worden sein könnte
  • einem Auditor oder einer Aufsichtsbehörde zu zeigen, wann das Problem ins Produkt gelangt ist und wann der Fix ausgeliefert wurde

Ein Scan des heutigen Codes kann Ihnen das nicht liefern. Das aktuelle Lockfile sagt, was das Repository jetzt will, nicht, was jeder frühere Build installiert hat. Die einzige verlässliche Quelle ist eine Aufzeichnung jedes Builds, die während seiner Ausführung entsteht und danach aufbewahrt wird.

Wie CRACI die Frage beantwortet

CRACI führt Ihre GitHub-Actions-Jobs auf eigenen Runnern aus und zeichnet jedes Paket auf, das jeder Build tatsächlich lädt, direkt und transitiv, einschließlich der von Skripten installierten und aus Caches wiederhergestellten Pakete. Die SBOM jedes Builds wird aufbewahrt, sodass die Historie bereits vorliegt, wenn eine CVE veröffentlicht wird.

Erscheint eine neue CVE, liegt die Antwort bereits vor: jeder frühere Build und seine SBOM, welche davon die verwundbare Abhängigkeit enthielten, direkt oder transitiv, und der Zeitraum, in dem Sie betroffen waren. Keine Tabelle, kein erneutes Scannen, keine Rekonstruktion aus Lockfiles. Der erste Build, der sie enthielt, und der Build, der sie entfernte, ergeben Ihr Expositionsfenster, so weit Ihre Aufbewahrungsfrist zurückreicht (standardmäßig 180 Tage, individuelle Aufbewahrung im Enterprise-Plan).

Sobald Sie Bescheid wissen, kann ein Policy Gate Builds blockieren, die diese CVE enthalten, sodass ein späteres Abhängigkeits-Update oder ein wiederhergestellter Cache die verwundbare Version nicht unbemerkt in ein Release zurückbringen kann.

Von da an hat der restliche Prozess eine Grundlage:

  • CRACI überwacht die SBOMs kontinuierlich, sodass neue CVEs mit Ihren Builds abgeglichen werden, ohne dass jemand danach fragt.
  • Sicherheitsteams sichten die Befunde und geben sie an die Teams weiter, die für die Behebung zuständig sind, und CRACI unterstützt VEX, um das Ergebnis festzuhalten.
  • Das Inventar von CRACI zeigt, welche Softwareversionen in welchen Produkten eingesetzt sind.
  • Für den CRA übermittelt CRACI die Frühwarnung, die Meldung und den Abschlussbericht in Ihrem Auftrag.

Buchen Sie eine Demo, um die Build-Historie eines Ihrer eigenen Repositories zu sehen.