Abhängigkeits-Audit und SBOM aus Ihrer Lock-Datei
Laden Sie package-lock.json, yarn.lock, requirements.txt, pom.xml oder Gradle-Dateien hoch. Sie sehen bekannte Schwachstellen mit Fix-Versionen, Lizenzklassen und veraltete Pakete — und laden eine Software-Stückliste (SBOM) im CycloneDX-Format herunter.
Wenn Sie Dependabot, Renovate, Snyk, OSV-Scanner oder Dependency-Track bereits in der CI nutzen, brauchen Sie das hier meist nicht. Es ist eine einmalige Prüfung für Übergaben, Due Diligence und eine erste SBOM.
YuSMP ist ein Softwareunternehmen; die Prüfung ist kostenlos und automatisiert. Auf Wunsch bieten wir eine manuelle Prüfung der Abhängigkeiten und Updates an.
1Abhängigkeitsdateien hinzufügen
Ihre Dateien bleiben in Ihrem Browser. Lock-Dateien werden lokal ausgewertet. Im nächsten Schritt sehen Sie, welche paket@version-Paare an unseren Server und von dort an die öffentliche Schwachstellen-Datenbank OSV.dev und eine Paket-Registry gehen würden; interne Pakete können Sie ausschließen. Wir speichern diese Liste nicht und schreiben sie nicht in Logs.
Dateien
| Datei | Format | Pakete | Status |
|---|
2Kontext (optional)
3Was gesendet wird
| Senden | Paket | Version | Bereich |
|---|
Prüfung läuft
- Bekannte Schwachstellen werden gesucht
- Release-Daten und Lizenzen werden geprüft
- Korrekturen werden priorisiert
Große Projekte dauern bis zu einer Minute.
Ergebnis
Zuerst beheben
CycloneDX-SBOM herunterladen
Die SBOM wird in Ihrem Browser aus den Komponenten oben erstellt (ausgeschlossene und private Pakete fehlen und werden in der Datei gezählt). Format: CycloneDX 1.5 JSON.
Was die Datei abdeckt (NTIA-Mindestelemente)
- ✓Name, Version und eindeutige Kennung (purl) der Komponente
- ◐Abhängigkeitsbeziehungen: nur Wurzel → direkte Abhängigkeiten
- ✓Ersteller der SBOM-Daten und Zeitstempel
- ✕Name des Lieferanten — fehlt, Registries liefern ihn nicht zuverlässig
- ✕Hashwerte der Komponenten — noch nicht enthalten
Der CRA erwartet von Herstellern, die Komponenten ihrer Produkte zu dokumentieren, unter anderem mit einer Software-Stückliste (SBOM) in einem gängigen, maschinenlesbaren Format, die mindestens die direkten Abhängigkeiten abdeckt (Anhang I, Teil II, Nr. 1).
Das Tool hilft, eine Komponentenliste zu beginnen und bekannte Meldungen zu sehen. Es ist keine Rechtsberatung und keine Konformitätsbewertung.
PDF-Bericht anfordern
Ein PDF mit der Prioritätenliste, dem Aufwand in Stunden, den Tabellen zu Schwachstellen, Lizenzen und veralteten Paketen sowie der Methodik — per E-Mail. Wir sehen dadurch auch, dass Sie die Prüfung genutzt haben, und bieten bei Bedarf eine manuelle Prüfung an.
Manuelle Prüfung von Abhängigkeiten und Updates
Ein Engineer geht Ihren Stack durch: was tatsächlich erreichbar ist, welche Updates sicher sind, was zu ersetzen ist, und ein Plan, dem Ihr Team folgen kann. Erstes Gespräch kostenlos, NDA auf Wunsch.
Was dieses Tool nicht tut
- Es analysiert Ihren Quellcode nicht (kein SAST) und prüft nicht, ob eine verwundbare Funktion tatsächlich aufgerufen wird.
- Es scannt keine Container-Images, Betriebssystempakete oder privaten Registries.
- Es behebt nichts und erstellt keine Pull-Requests.
- Es speichert weder Ihre Dateien noch die Paketliste.
- Es ist kein Zertifikat, kein Prüfurteil, keine Rechtsberatung und keine Konformitätsbewertung.
Wenn Sie bereits SCA in der CI haben
Behalten Sie es. Kontinuierliche Tools wie Dependabot, Renovate, OSV-Scanner oder Dependency-Track prüfen jeden Commit; diese Seite ist für einen einmaligen Blick: eine Übergabe durch einen Dienstleister, Due Diligence, eine erste SBOM für einen Kunden oder eine Codebasis, die lange niemand geprüft hat.
So funktioniert es
Ihr Browser liest die Dateien und ermittelt jedes Paket mit seiner exakten Version. Pakete ohne exakte Version (ein Bereich in package.json, eine nicht festgelegte Anforderung, eine Maven-Property, die sich nicht auflösen lässt) erscheinen als „Version nicht festgelegt“ und werden nicht nachgeschlagen: Ein Bereich liefert keine ehrliche Antwort. Fügen Sie für ein vollständiges Ergebnis eine Lock-Datei hinzu.
Interne Pakete werden automatisch ausgeschlossen: file:, link:, workspace:, Git- und URL-Quellen sowie alles aus einer nicht öffentlichen Registry. Weitere Pakete können Sie von Hand ausschließen, bevor etwas gesendet wird.
Erst nach „Abhängigkeiten prüfen“ geht nur die paket@version-Liste an unsere Serverless-Funktion. Sie fragt OSV.dev, die offene Schwachstellen-Datenbank mit Meldungen aus GitHub, PyPI, npm und weiteren Quellen, und deps.dev (Open Source Insights) nach Lizenzen, Release-Daten und Abkündigungen. Der Schweregrad stammt aus dem CVSS-v3-Vektor oder der Bewertung der Meldung; Dubletten (GHSA, CVE, PYSEC) werden zusammengeführt.
Prioritäten gewichten den Schweregrad nach Reichweite (direkte Produktionsabhängigkeit, transitiv, dev) und danach, ob es einen Fix gibt. Der Aufwand ist eine grobe Planungszahl in Stunden, kein Angebot. Abhängigkeiten festlegen und eine SBOM führen: siehe unsere Checkliste zur Web-App-Sicherheit.
Schwachstellendaten: OSV.dev und seine Quellen (CC-BY 4.0). Paket-Metadaten: deps.dev (Open Source Insights, CC-BY 4.0). Technische Richtlinie BSI TR-03183-2 zu SBOMs: bsi.bund.de.
CRA, SBOM und Ihr Produkt
- Der Cyber Resilience Act (Verordnung (EU) 2024/2847) ist am 10. Dezember 2024 in Kraft getreten. Die Meldepflicht für aktiv ausgenutzte Schwachstellen und schwere Vorfälle gilt seit dem 11. September 2026; die meisten übrigen Pflichten ab dem 11. Dezember 2027.
- Der CRA erwartet von Herstellern, die Komponenten ihrer Produkte zu dokumentieren, unter anderem mit einer Software-Stückliste (SBOM) in einem gängigen, maschinenlesbaren Format, die mindestens die direkten Abhängigkeiten abdeckt (Anhang I, Teil II, Nr. 1).
- Die Pflichten treffen Hersteller von Produkten mit digitalen Elementen, die in der EU in Verkehr gebracht werden. Ob sie für Ihr Produkt gelten, hängt vom Produkt ab — das entscheidet dieses Tool nicht.
Das Tool hilft, eine Komponentenliste zu beginnen und bekannte Meldungen zu sehen. Es ist keine Rechtsberatung und keine Konformitätsbewertung.
FAQ
Werden meine Dateien hochgeladen?
Nein. Die Dateien liest Ihr Browser, sie verlassen ihn nicht. Gesendet wird nur die Liste öffentlicher Paketnamen mit exakten Versionen, die Sie in der Vorschau bestätigen — und jedes Paket können Sie vorher ausschließen.
Was genau geht an externe Dienste?
Paare wie lodash@4.17.15 mit dem Ökosystem (npm, PyPI, Maven), ob das Paket direkt oder dev ist, und die Lizenzangabe aus der Lock-Datei. Unsere Funktion gibt Namen und Versionen an OSV.dev und deps.dev weiter (beide werden in den USA betrieben). Dateinamen, Pfade, URLs privater Registries und Ihr Quellcode werden nicht gesendet. Wir speichern die Liste nicht und protokollieren sie nicht.
Was ist eine SBOM und wer braucht sie?
Eine Software-Stückliste (SBOM) ist eine maschinenlesbare Liste der Komponenten eines Produkts: Namen, Versionen, Kennungen, Lizenzen. Kunden, Investoren und Behörden fragen immer öfter danach, und der Cyber Resilience Act erwartet sie von Herstellern von Produkten mit digitalen Elementen.
Heißt „Schwachstelle gefunden“, dass mein Produkt angreifbar ist?
Nein. Es heißt, dass eine veröffentlichte Meldung diese Paketversion betrifft. Ob Ihr Code die verwundbare Funktion aufruft, in welcher Konfiguration und mit welchen Eingaben, wird hier nicht bewertet — dafür gibt es die manuelle Prüfung.
Heißt „nichts gefunden“, dass alles sicher ist?
Nein. Es heißt, dass keine bekannte Meldung zu den geprüften exakten Versionen passt. Nicht festgelegte, ausgeschlossene Pakete und alles außerhalb der unterstützten Formate wurden nicht geprüft, und neue Meldungen erscheinen täglich.
Prüft das Tool die Konformität mit dem CRA?
Nein. Es hilft, eine Komponentenliste zu beginnen und bekannte Meldungen zu sehen. Es ist keine Rechtsberatung und keine Konformitätsbewertung, und ob der CRA gilt, hängt von Ihrem Produkt ab.
Welche Formate werden unterstützt und was nicht?
npm (package-lock.json, npm-shrinkwrap.json, yarn.lock, package.json), PyPI (requirements*.txt / .in) und Maven/Gradle (pom.xml, build.gradle, build.gradle.kts). Maven- und Gradle-Dateien enthalten nur deklarierte Abhängigkeiten, ohne transitiven Baum und oft ohne aufgelöste Versionen. Noch nicht abgedeckt: pnpm, Poetry, Pipenv, Go, Rust, Ruby, PHP, .NET, Container-Images und private Registries.
Was ist der Unterschied zu Dependabot, Snyk oder OSV-Scanner?
Diese Tools laufen dauerhaft in Ihrem Repository und Ihrer CI und können Fixes vorschlagen. Diese Seite ist eine einmalige Prüfung ohne Installation: nützlich für eine Übergabe, Due Diligence oder eine erste SBOM. Wenn Sie eines davon nutzen, behalten Sie es.
Passende Leistungen
Sicherheitsaudits
Penetrationstests und Sicherheitsprüfungen, auch eine manuelle Prüfung von Abhängigkeiten und Updates.
Software-Modernisierung
Frameworks aktualisieren und nicht gepflegte Pakete ersetzen, ohne das Produkt anzuhalten.
Fractional CTO
Erfahrene technische Leitung für Übergaben, Due Diligence und Entscheidungen zur Lieferkette.