SBOM für npm-, pnpm- und Yarn-Projekte nach dem CRA

Der Cyber Resilience Act verlangt von jedem Hersteller eine Software-Stückliste in einem gängigen, maschinenlesbaren Format, die mindestens die Abhängigkeiten der obersten Ebene des Produkts erfasst (Anhang I Teil II Nummer 1). Bei einem JavaScript- oder TypeScript-Produkt steht fast alles, was Sie brauchen, bereits in Ihrer Lock-Datei. Schwierig ist die Entscheidung, welche der Hunderte Pakete in node_modules tatsächlich ausgeliefert werden. Dieser Leitfaden behandelt das, und die Befehle, die daraus eine CycloneDX- oder SPDX-Datei machen.

Zur Verordnung selbst siehe SBOM für den Cyber Resilience Act.

Die Lock-Datei ist die Quelle der Wahrheit

package.json sagt, was Sie verlangt haben, mit Bereichen (^4.19.0). Nur die Lock-Datei sagt, was installiert wurde: die genaue Version jedes Pakets, direkt und transitiv, und meist seinen Integritäts-Hash.

Paketmanager	Lock-Datei	Direkte Abhängigkeiten stehen in
npm	`package-lock.json` (oder `npm-shrinkwrap.json`)	der Lock-Datei selbst
pnpm	`pnpm-lock.yaml`	der Lock-Datei selbst
Yarn (classic und Berry)	`yarn.lock`	nur `package.json`

Committen Sie die Lock-Datei und installieren Sie im Build mit npm ci, pnpm install --frozen-lockfile oder yarn install --immutable. Sonst beschreibt die SBOM eine Installation und das Produkt enthält eine andere.

Die SBOM erzeugen

npm hat seit Version 9.5 einen eingebauten Befehl:

npm sbom --sbom-format cyclonedx --sbom-type application --omit dev > sbom.cdx.json

Er liest standardmäßig node_modules; mit --package-lock-only arbeitet er nur mit der Lock-Datei, zum Beispiel vor der Installation. --sbom-format spdx schreibt stattdessen SPDX 2.3. Die CycloneDX-Ausgabe ist Version 1.5.

pnpm hat in Version 11 einen eigenen Befehl ergänzt, der CycloneDX 1.7 oder SPDX 2.3 schreibt:

pnpm sbom --sbom-format cyclonedx --sbom-type application --prod > sbom.cdx.json

Für Yarn oder für ein Monorepo mit mehreren Paketmanagern liest cdxgen, der Generator des CycloneDX-Projekts, alle davon:

npx @cyclonedx/cdxgen -t js -o sbom.cdx.json

Setzen Sie, egal mit welchem Werkzeug, --sbom-type application (oder die Entsprechung), wenn das Produkt eine Anwendung und keine Bibliothek ist, und benennen und versionieren Sie die Wurzelkomponente nach dem Produkt, das Sie in Verkehr bringen, nicht nach dem Repository.

Was tatsächlich ausgeliefert wird

Beim CRA geht es um das Produkt, wie es geliefert wird. Die Frage ist also nicht „Was ist in node_modules?“, sondern „Was erreicht den Kunden?“. Die Antwort hängt von der Art des Produkts ab.

Ein Node.js-Dienst oder eine CLI, die Sie verteilen. Ausgeliefert wird der Produktionsbaum: dependencies und deren Abhängigkeiten. devDependencies wegzulassen (--omit dev, --prod) ergibt die richtige Liste, solange Ihr Team Test- und Build-Werkzeuge aus dependencies heraushält.
Ein Frontend-Bundle (eine mit Vite, webpack, esbuild oder Ähnlichem gebaute App). Der Bundler kopiert Code aus Paketen in die ausgelieferten Dateien, und viele Projekte führen diese Pakete als devDependencies, weil zur Laufzeit nichts installiert wird. Hier würde --omit dev React oder Vue aus der SBOM streichen. Behalten Sie entweder alles, was im Bundle landet, unter dependencies, oder beschreiben Sie das Bundle selbst mit einem Werkzeug, das es liest, und lassen Sie die Entwicklungsabhängigkeiten als solche markiert statt gelöscht.
Eine Electron- oder Desktop-App. Sie liefert die Electron-Laufzeit aus, mit eigenem Chromium und Node.js. Die Electron-Version gehört in die SBOM, und ihre Sicherheitskorrekturen zählen ebenso wie die Ihrer npm-Pakete. Electron ist meist eine devDependency, daher streicht --omit dev es: Fügen Sie es wieder hinzu, oder erzeugen Sie die SBOM, ohne Entwicklungsabhängigkeiten wegzulassen.

Entwicklungsabhängigkeiten festzuhalten lohnt sich trotzdem. Ein kompromittiertes Build-Werkzeug kann manipulieren, was Sie ausliefern, und CycloneDX erlaubt, sie in der Datei zu behalten, als nicht zum Produkt gehörend markiert.

Stolperfallen speziell bei npm

Installationsskripte führen Code aus. Jedes Paket mit einem preinstall- oder postinstall-Skript läuft bei npm install, auf Entwicklerrechnern und in der CI. Der Wurm Shai-Hulud hat sich 2025 genau so über npm verbreitet und Token von den Rechnern gestohlen, die infizierte Pakete installierten. npm ci --ignore-scripts in der CI, oder pnpm, das die Build-Skripte von Abhängigkeiten nur mit Ihrer Erlaubnis ausführt, begrenzt das Risiko.
Mehrere Versionen eines Pakets. npm kann lodash dreimal in drei Versionen installieren. Alle drei gehören in die SBOM, und jede muss auf Schwachstellen geprüft werden.
Workspaces. Erzeugen Sie in einem Monorepo eine SBOM pro Produkt, das Sie in Verkehr bringen, nicht eine für das ganze Repository.
Git- und Datei-Abhängigkeiten (github:org/repo#commit, file:../lib) haben keine Registry-Version. Geben Sie ihnen eine Version und eine Quelle, die die SBOM tragen kann, sonst finden Schwachstellendatenbanken sie nie.

Von der SBOM zu den Schwachstellen

npm audit gleicht die Lock-Datei mit der GitHub Advisory Database ab, und jeder CycloneDX-fähige Scanner liest die SBOM. Für den CRA zählen über die reine Liste hinaus zwei Dinge:

Ausgenutzte zuerst. Eine im Katalog Known Exploited Vulnerabilities der CISA oder in der Europäischen Schwachstellendatenbank aufgeführte Schwachstelle ist ein starkes Indiz für eine aktive Ausnutzung; sobald Sie wissen, dass eine davon in Ihrem Produkt steckt, gibt Ihnen Artikel 14 24 Stunden für eine Frühwarnung. Siehe CVSS, EPSS und KEV.
Erreichbar oder nicht. Die meisten verwundbaren Funktionen in einem node_modules-Baum werden von Ihrem Code nie aufgerufen. Halten Sie Ihre Bewertung in einer VEX-Aussage fest, mit Begründung, statt den Befund offen zu lassen.

Wie Provetry hilft

Provetry liest package-lock.json, npm-shrinkwrap.json, pnpm-lock.yaml (Lock-Datei-Versionen 6 und 9) und yarn.lock (classic und Berry) aus Ihrer CI oder aus den hochgeladenen Dateien, unterscheidet direkte von transitiven Abhängigkeiten und schreibt die SBOM jeder Version in CycloneDX, in den kostenpflichtigen Tarifen auch in SPDX. Es überwacht jede Komponente auf neue und ausgenutzte Schwachstellen, täglich in den kostenpflichtigen Tarifen und wöchentlich im kostenlosen. Sein CI-Schritt sucht nach Belegen, dass ein verwundbares Paket nie geladen wird; in den Tarifen Pro und Consultant geht er für npm bis zur verwundbaren Funktion hinunter. Bei npm- und pnpm-Lock-Dateien, die sie verzeichnen, zählen Pakete mit Installationsskript immer als geladen. Jeder solche Befund ist ein Vorschlag mit seinem Nachweis, den Sie übernehmen oder nicht.