Embedded- & C/C++-Ökosysteme
Der CRA zieht die SBOM-Pflicht in die Embedded-Firmware — genau dort, wo klassische SBOM-Tools blind sind: Abhängigkeiten stehen in Build-System-Manifesten, nicht in Paketmanager-Lockfiles. kunnus bringt eigene Extraktoren für diese Formate mit. Zwei Designregeln gelten für alle: kein Netzwerk (eine deklarierte Version oder ein Git-Ref wird wörtlich übernommen; die Auflösung gegen eine Registry ist bewusst außerhalb des Scopes) und kein Raten (enthalten Identitätsfelder nicht auflösbare Variablen, wird die Komponente verworfen statt erfunden).
Zephyr (west.yml)
Jedes Manifest-Projekt wird nach den west-Regeln aufgelöst — explizite URL, sonst Remote plus repo-path, mit angewandten Defaults. github.com-Projekte werden pkg:github-Komponenten mit der gepinnten Revision (Tag oder SHA) wörtlich. Die Auflösung von manifest import:, die weitere Manifeste aus anderen Repositories zieht, ist bewusst außerhalb des Scopes.
ESP-IDF (dependencies.lock / idf_component.yml)
Das Lockfile gewinnt: Es pinnt exakte Versionen für direkte und transitive Komponenten inklusive des IDF-Frameworks selbst, und seine SHA-256-Komponenten-Hashes landen in der SBOM. Manifeste unter einem gelockten Projekt werden übersprungen, um Komponenten nicht zu duplizieren; Manifest-only-Projekte fallen auf die deklarierten Constraints zurück, wörtlich.
PlatformIO (platformio.ini)
lib_deps-Einträge über alle Sektionen werden geparst: Registry-Specs behalten ihre deklarierte Version oder Range wörtlich; Quell-URLs mit #ref werden pkg:github für github.com, sonst pkg:generic. file://-Pfade und ${...}-Interpolationen werden verworfen.
vcpkg (vcpkg.json)
Jede Abhängigkeit wird eine pkg:vcpkg-Komponente. Die Versionsauflösung nutzt die besten Offline-Daten in dieser Reihenfolge: ein overrides[]-Pin, sonst die version>=-Untergrenze der Abhängigkeit selbst, sonst versionslos. builtin-baseline wird bewusst ignoriert — den Baseline-Commit in konkrete Port-Versionen aufzulösen erfordert die vcpkg-Registry, also Netzwerkzugriff. Feature-bedingte Abhängigkeiten werden nicht verfolgt, da aus dem Manifest allein nicht erkennbar ist, ob ein Feature aktiv ist.
CMake-Declares (FetchContent, ExternalProject, CPM)
Direkt im CMake-Quelltext gepinnte Abhängigkeiten — FetchContent_Declare / ExternalProject_Add mit Git-URL und GIT_TAG, Tarball-URL mit URL_HASH sowie CPM.cmake-Aufrufe — werden erfasst. Das ist ein Deklarations-Scanner, kein CMake-Interpreter: Jedes Identitätsfeld mit einer nicht aufgelösten ${...}-Variablen verwirft das Declare — zugleich die Kontrolle gegen False Positives. URL_HASH-Digests wandern als Komponenten-Hashes in die SBOM.
Arduino (library.properties, sketch.yaml)
Vendorte Bibliotheken werden aus ihrer eigenen library.properties gelesen (Name und Version — installierter Zustand), und arduino-cli-sketch.yaml-Profile steuern ihre gepinnten Bibliotheken und Platform-Cores bei. Das depends=-Feld einer Bibliothek wird bewusst nicht emittiert: Diese ungepinnten transitiven Deklarationen duplizieren meist Bibliotheken, die direkt daneben vendort liegen.
CMSIS-Solution (*.csolution.yml)
solution.packs-Specs (Vendor::Pack@Constraint) werden herstellernamensraum-Komponenten mit wörtlich übernommenem Constraint. Lokale path:-Packs sind Code in Entwicklung, Wildcard-Auswahlen (NXP::*) benennen keine einzelne Komponente; beides wird verworfen.
ModusToolbox (*.mtb)
Jedes einzeilige .mtb-Manifest nennt ein GitHub-Repository und ein Git-Ref; das Ref wird wörtlich die Komponentenversion — Refs sind Tags wie release-v6.1.0, kein Semver. Keine Hashes oder Lizenzen: Ein .mtb pinnt einen Tag, keine Checksumme, und beides aufzulösen bräuchte das Netzwerk.
Git-Submodule (.gitmodules)
Submodule-Remotes auf github.com werden pkg:github-Komponenten, alles andere pkg:generic. Der gepinnte Commit wird aus dem .git/index des Superprojekts dekodiert — kein Submodule-Checkout und kein git-Subprozess nötig. Ein exportierter Baum ohne .git ergibt versionslose Komponenten.