sharang/compliance-scanner-agent
1
0
Fork 0
Code Issues 79 Pull Requests 1 Actions Packages Projects Releases 1 Wiki Activity

ONB · Bitbake/Yocto detection (our classifier) + Yocto-native SPDX/cve-check ingest (no tramiton dep) #150

New Issue
Open
opened 2026-07-12 21:56:20 +00:00 by sharang · 2 comments
sharang commented 2026-07-12 21:56:20 +00:00
Owner
Copy Link
Copy Source

Part of #118. Recognize bitbake/Yocto as a build system so Yocto source repos classify correctly and surface Yocto-native SBOM/CVE.

Context

Tramiton detects PlatformIO/Zephyr/ESP-IDF/CMake/Make/Arduino/bare-metal, but not bitbake/Yocto (its coverage doc calls this out). So a Yocto BSP repo won't auto-classify as EmbeddedLinuxYocto today.

Approach

  • Detection: recognize Yocto markers (conf/bblayers.conf, *.bb/*.bbappend recipes, oe-init-build-env, meta-* layers) → EmbeddedLinuxYocto. Add as a tramiton provider (preferred, upstream in tramiton) or in our classifier registry as a fallback.
  • Yocto-native evidence: SPDX SBOM via the create-spdx class (full image bill of materials + licenses) and recipe-level cve-check (recipe→NVD). Feed these into SBOM/CVE + the compliance/license mapping.

Depends

Classifier (#121), tramiton integration (#135). Feeds the Yocto dynamic path issue.

Part of #118. Recognize **bitbake/Yocto** as a build system so Yocto source repos classify correctly and surface Yocto-native SBOM/CVE. ## Context Tramiton detects PlatformIO/Zephyr/ESP-IDF/CMake/Make/Arduino/bare-metal, but **not bitbake/Yocto** (its coverage doc calls this out). So a Yocto BSP repo won't auto-classify as `EmbeddedLinuxYocto` today. ## Approach - **Detection:** recognize Yocto markers (`conf/bblayers.conf`, `*.bb`/`*.bbappend` recipes, `oe-init-build-env`, `meta-*` layers) → `EmbeddedLinuxYocto`. Add as a tramiton provider (preferred, upstream in tramiton) or in our classifier registry as a fallback. - **Yocto-native evidence:** SPDX SBOM via the `create-spdx` class (full image bill of materials + licenses) and recipe-level `cve-check` (recipe→NVD). Feed these into SBOM/CVE + the compliance/license mapping. ## Depends Classifier (#121), tramiton integration (#135). Feeds the Yocto dynamic path issue.
sharang added this to the Onboarding v1 milestone 2026-07-12 21:56:20 +00:00
sharang added the onboardingenhancement labels 2026-07-12 21:56:20 +00:00
sharang commented 2026-07-16 10:41:30 +00:00
Author
Owner
Copy Link
Copy Source

Customer context (tracker #167): CODESYS-on-Yocto device. Beyond the Yocto/bitbake SPDX SBOM, reconcile with the control-application dependency SBOM (CODESYS libraries + runtime version) from #166 so the CODESYS runtime isn't double-counted between the image SBOM and the control-app SBOM.

Customer context (tracker #167): CODESYS-on-Yocto device. Beyond the Yocto/bitbake SPDX SBOM, reconcile with the **control-application dependency SBOM** (CODESYS libraries + runtime version) from #166 so the CODESYS runtime isn't double-counted between the image SBOM and the control-app SBOM.
sharang commented 2026-07-16 22:04:34 +00:00
Author
Owner
Copy Link
Copy Source

Re-scope: own the Yocto path here, not in tramiton (decision 2026-07-17)

Verified against tramiton v0.4.1 (the tag pinned in compliance-agent/Cargo.toml): its providers are platformio, arduino, cargo_embedded, cmake, espidf, make, zephyr, scan, source_archaeology, and its BuildSystem enum is {PlatformIo, Zephyr, EspIdf, Cargo, CMake, Make, Arduino} — still no bitbake/Yocto. Our classify::firmware::detection_to_target_type already maps a bitbake/yocto signal → EmbeddedLinuxYocto, but tramiton never emits that signal, so the mapping can only fire from the synthetic unit test, never from real analysis.

Decision — do not wait on a tramiton bitbake provider. Own it in this repo:

  1. Detection in our classifier registry — Yocto markers (conf/bblayers.conf, *.bb/*.bbappend, meta-* layers, oe-init-build-env) → EmbeddedLinuxYocto. No tramiton (#135) dependency for the Yocto path.
  2. SBOM = ingest Yocto-native SPDX — parse the create-spdx / cyclonedx.bbclass output the customer's build already emits (+ recipe cve-check results) → our SBOM/CVE. Higher-quality than any rebuild, and needs no build on our side.
  3. Binary-image fallback — when only a built image is supplied, use the binwalk + syft / cve-bin-tool path in #151.

Dropping the tramiton dependency from this issue's scope.

## Re-scope: own the Yocto path here, not in tramiton (decision 2026-07-17) Verified against **tramiton v0.4.1** (the tag pinned in `compliance-agent/Cargo.toml`): its providers are `platformio, arduino, cargo_embedded, cmake, espidf, make, zephyr, scan, source_archaeology`, and its `BuildSystem` enum is `{PlatformIo, Zephyr, EspIdf, Cargo, CMake, Make, Arduino}` — **still no bitbake/Yocto**. Our `classify::firmware::detection_to_target_type` already maps a `bitbake`/`yocto` signal → `EmbeddedLinuxYocto`, but tramiton never emits that signal, so the mapping can only fire from the synthetic unit test, never from real analysis. **Decision — do not wait on a tramiton bitbake provider. Own it in this repo:** 1. **Detection in our classifier registry** — Yocto markers (`conf/bblayers.conf`, `*.bb`/`*.bbappend`, `meta-*` layers, `oe-init-build-env`) → `EmbeddedLinuxYocto`. No tramiton (#135) dependency for the Yocto path. 2. **SBOM = ingest Yocto-native SPDX** — parse the `create-spdx` / `cyclonedx.bbclass` output the customer's build already emits (+ recipe `cve-check` results) → our SBOM/CVE. Higher-quality than any rebuild, and needs no build on our side. 3. **Binary-image fallback** — when only a built image is supplied, use the binwalk + syft / cve-bin-tool path in #151. Dropping the tramiton dependency from this issue's scope.
sharang changed title from ONB · Bitbake/Yocto build-system provider (classifier + tramiton) + SPDX/cve-check to ONB · Bitbake/Yocto detection (our classifier) + Yocto-native SPDX/cve-check ingest (no tramiton dep) 2026-07-16 22:04:34 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
P0-demo
CERTifAI P0 demo build tickets (CS-*)
 bug
critical
enhancement
epic
Tracking issue spanning multiple sub-issues
 high
infrastructure
onboarding
Multi-target onboarding wizard redesign
 performance
security
v0.3.0
No labels enhancement onboarding
Milestone
No items
No Milestone Onboarding v1
Projects
Clear projects
No projects
Assignees
Clear assignees
Benjamin_Boenisch sharang (Sharang Parnerkar)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sharang/compliance-scanner-agent#150