SBOM Vulnerability Scanner

Fügen Sie eine Lockfile oder SBOM ein und prüfen Sie jede gepinnte Version auf bekannte Schwachstellen — lokal geparst, abgeglichen mit der OSV-Datenbank.

Eine Lockfile ist die genaue Liste der Versionen, die Ihr Build tatsächlich installiert — und jede gepinnte Version ist eine Wette darauf, dass seitdem niemand ein Loch darin gefunden hat. Dieser Scanner liest diese Liste (package-lock.json, requirements.txt, go.mod oder eine CycloneDX- / SPDX-SBOM), sendet nur die Name-und-Version-Paare an die öffentliche OSV.dev-Schwachstellendatenbank und meldet, welche Pakete bekannte Schwachstellen haben, wie schwerwiegend sie sind, welche Version jede einzelne behebt und ob eine der CVEs auf der Liste bekannter ausgenutzter Schwachstellen (Known Exploited Vulnerabilities) der CISA steht. Der begleitende Leitfaden is your lockfile hiding vulnerabilities? erklärt, was die Ergebnisse beweisen — und was nicht. Wenn der Scan eine CVE meldet, setzt das Bulk CVE Triage-Desk sie in den Ausnutzungskontext.

Zuletzt aktualisiert:

Ihre Lockfile oder SBOM

Akzeptiert: package-lock.json, requirements.txt, go.mod, CycloneDX JSON, SPDX JSON. Maximale Dateigröße 5 MB.

Das Format wird anhand des Dateinamens und des Inhalts erkannt; Sie können es unten auch selbst auswählen.

🔒 Ihre Lockfile wird in Ihrem Browser geparst und niemals hochgeladen. Nur Paketnamen und Versionen gehen an OSV.dev; nur CVE-IDs gehen an unseren eigenen Checker für KEV-Kennzeichnungen.

Scan-Ergebnisse

Noch kein Scan. Laden Sie oben eine Lockfile oder SBOM hoch oder fügen Sie sie ein und klicken Sie auf „Auf Schwachstellen scannen“.

Ihre Lockfile verlässt diese Seite nie

Das Parsen geschieht vollständig in Ihrem Browser: Die Datei, die Sie ablegen — oder der Text, den Sie einfügen — wird lokal gelesen und nirgendwo hochgeladen. Nur die extrahierten Paketnamen und Versionen werden nach außen gesendet, an die öffentliche OSV.dev-Schwachstellendatenbank (kein Konto, kein Schlüssel), damit sie sie mit bekannten Schwachstellen abgleichen kann. CVE-IDs aus den Treffern werden dann an den eigenen Checker dieser Website für eine CISA-KEV-Abfrage gesendet. Nichts anderes verlässt die Seite: keine Dateiinhalte, keine Pfade, keine Projektnamen.

Scan-Limits

Pro Durchlauf werden höchstens 500 Pakete gescannt — alle weiteren werden als nicht gescannt aufgeführt. Höchstens 200 Schwachstellendetails werden abgerufen. Die Ergebnisse stammen aus der OSV-Datenbank für die genauen Versionen in Ihrer Datei; eine Paketversion, die die Datenbank noch nie gesehen hat, liefert keinen Treffer — das ist nicht dasselbe wie eine Unbedenklichkeitsbescheinigung.

Die ehrlichen Grenzen

„Keine Schwachstellen gefunden“ bedeutet: keine in der OSV-Datenbank für diese genauen Versionen. Es bedeutet nicht, dass der Code sicher ist: Schwachstellen, die noch niemand gemeldet hat, bösartige Pakete, Typosquat-Namen und kompromittierte Releases sind für eine Prüfung per Versionsabgleich alle unsichtbar.

Ein Treffer ist versionsexakt. Wenn Ihre Datei einen Bereich statt einer genauen Version pinnt, wird sie übersprungen und als solche aufgeführt — der Scanner rät nicht, welche Version Sie tatsächlich installiert haben. Dasselbe gilt für Pakete, deren Ökosystem der Scanner nicht zuordnen kann: Sie werden als übersprungen aufgeführt, niemals stillschweigend verworfen.

KEV-Kennzeichnungen stammen aus einer einzigen Abfrage beim eigenen Checker dieser Website (CISA-KEV-Daten, täglich aktualisiert). Wenn diese Abfrage fehlschlägt oder ratenbegrenzt wird, wird der Scan trotzdem abgeschlossen — die KEV-Spalte sagt dann einfach „unbekannt“, statt Ihre Ergebnisse zu blockieren.

Warum die gepinnte Version die Angriffsfläche ist

Eine Lockfile existiert, weil „latest“ keine Version ist. Sie zeichnet den genauen Baum auf, den Ihr Build installiert hat, damit jede Maschine und jedes Deployment denselben Code erhält. Diese Determiniertheit macht die Lockfile auch scannbar: Eine Schwachstellendatenbank ist nach exaktem Paket und exakter Version indiziert, sodass eine gepinnte Version mit einer einzigen Abfrage beurteilt werden kann, während ein schwebender Bereich das nicht kann. Der Scan ist daher nur so gut wie die Datei — committen Sie die Lockfile, halten Sie sie aktuell, und der Scanner kann Ihnen die Wahrheit über das sagen, was Sie ausliefern.

Die Prüfung selbst ist bewusst eng gefasst. OSV.dev aggregiert Schwachstellenmeldungen aus GitHub Advisories, der NVD und den Sprach-Ökosystemen und gleicht sie mit Ihren Versionen ab. Was es nicht kann, ist den Code zu beurteilen: Ein Paket ohne bekannte CVE kann trotzdem bösartig, verlassen oder ein Lookalike eines Pakets sein, das Sie installieren wollten. Versionsabgleich ist ein schneller, billiger erster Filter — derjenige, der das lodash erwischt, das Sie zu aktualisieren vergessen haben — keine Sicherheitsprüfung.

Warum eine KEV-Kennzeichnung mehr zählt als ein hoher CVSS-Score

Ein CVSS-Score misst, wie schlimm eine Schwachstelle wäre, wenn sie ausgenutzt würde. Der Katalog bekannter ausgenutzter Schwachstellen (Known Exploited Vulnerabilities) der CISA misst etwas anderes: ob sie tatsächlich ausgenutzt wird, in freier Wildbahn, genau jetzt. Eine CVE mittlerer Schwere auf der KEV-Liste verdient einen Patch noch diese Woche; eine kritische CVE, die niemand weaponisiert hat, kann oft bis zum nächsten geplanten Upgrade warten. Darum kennzeichnet dieser Scanner KEV-Zeilen separat und darum sortieren die Ergebnisse zuerst nach der schlimmsten Schwere — aber die KEV-Kennzeichnung ist die, auf die Sie zuerst reagieren sollten.

Behobene Versionen bergen ihr eigenes Risiko. Die Behebung einer Schwachstelle ist in der Regel ein Minor- oder Patch-Release, aber „behoben in 4.17.21“ kann auch eine Verhaltensänderung bedeuten, die Ihren Build bricht, und manche Schwachstellen haben überhaupt keine behobene Version — der Scanner sagt das offen, statt eine zu erfinden. Patchen Sie zuerst die KEV-Einträge, dann die kritischen mit einer veröffentlichten Behebung, und planen Sie den Rest; pinnen Sie die neuen Versionen, committen Sie die Lockfile und scannen Sie erneut. Dieselbe Schleife gehört in die CI, wo sie bei jedem Pull Request läuft statt einmal im Quartal.

Lizenzen in dieser SBOM

Die hier aufgeführten Lizenzen stammen nur aus Lizenzfeldern, die in der SBOM selbst enthalten sind. Lockfiles (package-lock.json, requirements.txt, go.mod) enthalten keine Lizenzdaten, daher wird für sie nichts angezeigt — diese Seite schlägt Lizenzen nicht pro Paket nach, weil keine öffentliche Datenbank sie zuverlässig bereitstellt.

Lockfile- und SBOM-Begriffe, festgehalten

Lockfile. Eine Datei, die die genaue Version jedes Pakets festhält, das ein Build installiert — package-lock.json für npm, requirements.txt mit ==-Pins für Python, go.mod/go.sum für Go — damit Installationen reproduzierbar sind.

SBOM. Software Bill of Materials: ein maschinenlesbares Verzeichnis aller Komponenten einer Software, üblicherweise im CycloneDX- oder SPDX-Format. Sie ist die Lockfile, verallgemeinert auf die gesamte Lieferkette.

OSV.dev. Googles öffentliche Schwachstellendatenbank, die Advisories von GitHub, der NVD und den Sprach-Ökosystemen aggregiert und nach exaktem Paketnamen, Ökosystem und Version abfragbar ist.

GHSA. Eine GitHub-Security-Advisory-ID (GHSA-xxxx-xxxx-xxxx). Die meisten npm-, PyPI- und Go-Schwachstellen in OSV tragen eine, meist zusammen mit einer CVE-ID.

CVE. Common Vulnerabilities and Exposures: das gemeinsame Nummerierungsschema (CVE-YYYY-NNNNN), mit dem jede Datenbank, jeder Scanner und jeder Anbieter über dieselbe Schwachstelle sprechen kann.

CVSS. Common Vulnerability Scoring System: ein Score von 0–10 dafür, wie schwerwiegend eine Schwachstelle wäre, wenn sie ausgenutzt würde. 9,0+ ist CRITICAL, 7,0+ HIGH, 4,0+ MEDIUM, unter 4,0 LOW.

KEV. Der Katalog bekannter ausgenutzter Schwachstellen (Known Exploited Vulnerabilities) der CISA: Schwachstellen, deren Ausnutzung in freier Wildbahn bestätigt ist, jede mit einem Fälligkeitsdatum für die Behebung. Eine KEV-Kennzeichnung bedeutet „jetzt patchen“, was auch immer der CVSS sagt.

Fixed version. Die erste Version eines Pakets, in der eine Schwachstelle nicht mehr vorhanden ist, entnommen aus den Affected-Range-Ereignissen des Advisorys. Für manche Schwachstellen ist noch keine veröffentlicht.

Purl. Package URL (pkg:npm/[email protected]): eine standardisierte Art, ein Paket mit seinem Ökosystem und seiner Version zu benennen. SBOMs enthalten Purls, und so weiß der Scanner, zu welchem Ökosystem eine Komponente gehört.

Häufig gestellte Fragen

Verlässt meine Lockfile meinen Browser?

Nein. Die Datei wird lokal geparst und niemals hochgeladen. Nur die extrahierten Paketnamen und Versionen werden an OSV.dev, eine öffentliche Schwachstellendatenbank, gesendet, und nur die CVE-IDs aus den Treffern werden an den eigenen Checker dieser Website für die KEV-Abfrage gesendet. Dateiinhalte, Pfade und Projektnamen verlassen die Seite nie.

Warum wird ein Paket als „übersprungen“ aufgeführt?

Aus drei Gründen: Die Zeile ist kein exakter Pin (ein Bereich wie ~= oder >=, ein -r-Include, eine replace-Direktive), das Ökosystem lässt sich nicht auf eines abbilden, das OSV.dev unterstützt, oder der Scan hat die Obergrenze von 500 Paketen erreicht. Übersprungene Einträge werden immer mit ihrem Grund aufgeführt — nichts wird stillschweigend verworfen.

„Keine Schwachstellen gefunden“ — bin ich sicher?

Nicht unbedingt. Es bedeutet, dass für diese genauen Versionen keine Schwachstelle in der OSV-Datenbank gemeldet wurde. Nicht gemeldete Schwachstellen, bösartige oder Typosquat-Pakete und kompromittierte Releases erscheinen in keiner Schwachstellendatenbank. Betrachten Sie den Scan als ersten Filter, nicht als Unbedenklichkeitsbescheinigung.

Was sollte ich zuerst beheben?

Beginnen Sie mit allem, das eine KEV-Kennzeichnung trägt — diese Schwachstellen werden gerade jetzt ausgenutzt, und die CISA setzt für jede ein Fälligkeitsdatum. Dann die CRITICAL- und HIGH-Zeilen, die eine veröffentlichte behobene Version haben, beginnend mit den Paketen, die Ihre Anwendung tatsächlich importiert. Nutzen Sie das Bulk CVE Triage-Desk für den Ausnutzungskontext hinter jeder CVE.

Eine Schwachstelle hat keine behobene Version. Was nun?

Prüfen Sie zuerst, ob eine neuere Version existiert, die das Advisory noch nicht verzeichnet hat — Advisories hinken Releases hinterher. Wenn es wirklich keine Behebung gibt, bleiben Ihnen drei Optionen: die Abhängigkeit entfernen, sie ersetzen oder den anfälligen Codepfad entschärfen (zum Beispiel keine nicht vertrauenswürdigen Eingaben mehr an die betroffene Funktion übergeben) und das Advisory auf ein Update beobachten. Scannen Sie nach jeder Änderung erneut.