MegaRepo NVD Firewall: Log4Shell automatisch blockieren

MegaRepo bekommt heute ein Feature, das in Nexus Pro 2.000 EUR pro Nutzer und Jahr kostet: eine NVD Firewall. Jeder Artefakt-Download wird gegen die NIST National Vulnerability Database geprüft. Komponenten mit bekannter Schwachstelle oberhalb einer konfigurierbaren CVSS-Schwelle werden blockiert – mit HTTP 403, einer Liste der betroffenen CVEs und Eintrag im Block-Log.

Warum das wichtig ist

Log4Shell (CVE-2021-44228) war weltweit in Logs zu finden, weil Entwickler nicht wussten, welche Version sie gerade gezogen haben. Text4Shell (CVE-2022-42889) ebenso. Die Industrie redet seit Jahren über Software Supply Chain Security – aber am konkreten Punkt, wo ein Maven-Client ein JAR aus dem Internet holt, ist in vielen Unternehmen keine einzige Kontrolle aktiv.

Eine Firewall, die vor der produktiven Integration greift, ist kein Luxus. Sie ist der Unterschied zwischen „wir wissen, dass wir Log4Shell nicht mehr ziehen“ und „wir hoffen, dass niemand 2.14.1 erwischt hat“.

So funktioniert’s

Der Admin hinterlegt im Backend einen NVD-API-Key (kostenlos, ratenlimit-befreit) und einen CVSS-Schwellwert – typisch 7.0 (HIGH) oder 9.0 (CRITICAL). MegaRepo zieht daraufhin die gesamte NVD-Datenbank einmalig in eine lokale Postgres-Tabelle. Das dauert mit Key etwa drei Minuten für rund 345.000 CVEs. Die Web-Oberfläche zeigt einen Live-Fortschrittsbalken – kein silent background loading.

Ab dann ist jeder Lookup offline und dauert unter 20 Millisekunden. Einmal täglich läuft ein inkrementeller Sync, der nur die seit dem letzten Lauf geänderten CVEs nachzieht. Keine Abhängigkeit von NVD-Verfügbarkeit im Download-Pfad.

Ein Beispiel

Ein Maven-Client fordert org.apache.logging.log4j:log4j-core:2.14.1 über den MegaRepo-Proxy an. Ablauf:

1. MegaRepo identifiziert die Komponente (maven2:org.apache.logging.log4j:log4j-core:2.14.1).
2. Die Firewall mappt den Artifact-Namen auf CPE-Kandidaten, u.a. log4j, und findet in der lokalen Datenbank CVE-2021-44228 mit CVSS 10.0 und versionsbereich 2.0-beta9 <= v < 2.15.0.
3. Version 2.14.1 fällt in den Bereich. Max-Score 10.0 >= Schwellwert 7.0.
4. Die Antwort ist HTTP 403 mit JSON-Body, der die betroffenen CVEs, ihre Scores, Severity und offizielle Beschreibung enthält. Der Block wird geloggt.

Ein Pull von log4j-core:2.17.2 geht dagegen HTTP 200 durch – die Version liegt außerhalb des Schwachstellenbereichs.

Whitelist für Realität

Kein ehrliches Security-Tool ist ohne Bypass brauchbar. Zwei Fälle kommen in der Praxis vor:

• Komponenten-Whitelist: Eine einzelne Version oder alle Versionen eines Artefakts dürfen trotz CVE durch – zum Beispiel weil das CVE in Ihrem Kontext nicht ausnutzbar ist oder ein Upgrade noch blockiert wird.
• CVE-Whitelist: Ein bestimmtes CVE wird global ignoriert, falls es für Ihre Nutzung irrelevant ist oder als False Positive klassifiziert wurde.

Beide Whitelist-Arten lassen sich mit Begründung und Audit-Trail (wer, wann) pflegen. Kein Bypass ohne Spur.

Was noch nicht kann

Dies ist eine erste Version. Bewusst draussen gelassen: Echtzeit-Benachrichtigung bei neu bekannten CVEs für bereits gecachte Artefakte (Retroactive Scanning). Reports per Email. Integration mit externen SBOM-Tools. Alles auf der Roadmap, aber nicht im ersten Wurf.

Was funktioniert: Blockieren, Logging, Whitelist, Sync-Status in der UI – und 22 Unit-Tests, die den Pfad von NVD-API-Response über Versionsvergleich bis zur 403-Entscheidung absichern. Log4Shell und Text4Shell wurden am realen MegaRepo gegen Maven Central getestet und korrekt geblockt.

Ab sofort verfügbar

Die NVD Firewall ist Teil der MegaRepo Beta und – wie der Rest – komplett kostenlos. Auch nach dem 1.0-Release bleibt sie in der Free-Tier enthalten. Wer sonst etwas Vergleichbares will, zahlt bei den großen Anbietern schnell vierstellig pro Jahr.

Sie finden die neue Funktion in der Admin-Oberfläche unter Security → NVD Firewall. Nach dem Initial-Sync ist nichts weiter zu tun: Die Regel greift automatisch bei jedem Pull aus einem Proxy- oder Hosted-Repository.