Zephyr
west spdx schreibt vier getrennte SPDX-Dokumente (app, zephyr, build und modules-deps). Jedes ist nur ein Teil des Bildes, und sie verweisen über Dokumentverweise aufeinander. Wer eines allein liest, sieht den größten Teil des Produkts nicht. Das Build-Dokument führt außerdem die CMake-Targets als Pakete auf, sodass die Liste lang ist und größtenteils keine Software enthält, die jemand ausliefert.
Wo die Dokumente die Module nennen, ist die Version oft ein 40-stelliger Git-Commit und kein Release, und viele Kennungen sind NOASSERTION. Eine Schwachstellendatenbank ordnet über Name und Release zu, ein Commit-Hash findet daher nichts. Das Ergebnis sieht aus wie eine SBOM, kann aber die Frage „Ist mein Produkt betroffen?“ nicht beantworten.
Eine ist die Liste, die Ihr Build schreibt. Dateien werden in Ihrem Browser gelesen.
Führen Sie west spdx einmal vor dem Build aus, damit es den Build aufzeichnen kann, und noch einmal danach:
west spdx --init -d build
west build -d build
west spdx -d buildapp.spdx, zephyr.spdx, build.spdx, modules-deps.spdx — die vier Dokumente, die west spdx in Ihren Build-Ordner schreibt; laden Sie alle vier hoch.config (optional) — zeigt, welche Subsysteme einkompiliert sind, etwa Bluetooth, MQTT oder mbedTLSwest.yml (optional) — die Modulliste mit festgelegten Revisionen.config gefunden, einschließlich der C-Bibliothek (newlib oder Picolibc)west zeichnet die Revision auf, die Ihre west.yml festlegt, und das ist oft ein Commit. Die Zuordnungstabellen halten fest, wie sich daraus ein Release ableiten lässt, wo das möglich ist; wo nicht, nennt es die Lückenliste.Angaben auf dieser Seite geprüft am 14. Oktober 2026.
Declarable bereitet Unterlagen vor, die Sie prüfen sollen. Das ist keine Rechtsberatung und keine Zertifizierung. Ihre Konformitätserklärung unterschreiben Sie selbst.