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

ONB · CODESYS-on-Yocto customer: end-to-end SBOM/SAST/DAST/pentest coverage tracker #167

New Issue
Open
opened 2026-07-16 10:40:57 +00:00 by sharang · 1 comment
sharang commented 2026-07-16 10:40:57 +00:00
Owner
Copy Link
Copy Source

Customer case: CODESYS control logic on a Yocto Linux device

A prospective customer runs CODESYS (IEC 61131-3) control applications on a
device whose OS is Yocto embedded Linux. That single device is really two
layers we must cover end-to-end:

  • ICS / PLC layer — the CODESYS runtime, the control application (POUs), and
    the industrial protocols it speaks (CODESYS programming protocol 11740/11741,
    OPC UA, Modbus TCP 502, EtherNet/IP, WebVisu HTTP).
  • Embedded-Linux layer — the Yocto OS image, its packages, kernel config, and
    network services (SSH, TLS, exposed daemons, web).

Goal: from one onboarded target, produce a clear SBOM, SAST, and simulated
DAST/Pentest across both layers.

Coverage matrix (status as of this issue)

Chain PLC / CODESYS layer Yocto-Linux layer
SBOM ❌ control-app deps + runtime version → #166 🟡 #150 (bitbake/SPDX), #151/#128 (image SBOM)
SAST 🟡 ST + PLCopen-ST only; native .project + LD/FBD/SFC/CFC → #165 🟡 source Semgrep umbrella exists; recipe/kernel-config depth via #151 (EMBA)
DAST ❌ HTTP-only today; ICS protocols → #148 🟡 #149 (QEMU boot → DAST)
Pentest ❌ supports_pentest(PlcSps)=false; soft-PLC + ICS modules → #148 🟡 #149 (QEMU → pentest)
Matrix wiring ❌ PlcSps offers only control-logic → #164 ✅ EmbeddedLinuxYocto offers full set

Legend: ✅ done · 🟡 issue exists / partial · ❌ gap.

Convergence problem

Onboarding binds one TargetType per target, but this device is simultaneously
PlcSps and EmbeddedLinuxYocto. #A decides how the two layers converge
(composite PlcSps that also runs firmware SBOM/CVE + DAST/pentest when those
artifacts/endpoints are attached, vs. two linked targets).

What to ask the customer (once the gaps are closed)

  1. PLCopen XML export of the CODESYS project (interim until #B reads native .project).
  2. Device firmware image (Yocto) + CODESYS runtime version.
  3. A reachable WebVisu / OPC UA endpoint, or agreement to run CODESYS Control
    for Linux SL     (soft-PLC container) + a runqemu Yocto image for safe DAST/pentest.

Tracks

  • New: #164 composite matrix · #165 CODESYS native + graphical-language SAST · #166 control-app SBOM
  • Existing: #122 matrix · #128/#130 onboarding specifics · #148 PLC dynamic · #149 Yocto dynamic · #150 bitbake/SPDX · #151 FirmwareStatic

Implementation order: #164 → #166 → #165 → (#148/#149 ICS dynamic).

## Customer case: CODESYS control logic on a Yocto Linux device A prospective customer runs **CODESYS** (IEC 61131-3) control applications on a device whose OS is **Yocto embedded Linux**. That single device is really two layers we must cover end-to-end: - **ICS / PLC layer** — the CODESYS runtime, the control application (POUs), and the industrial protocols it speaks (CODESYS programming protocol 11740/11741, OPC UA, Modbus TCP 502, EtherNet/IP, WebVisu HTTP). - **Embedded-Linux layer** — the Yocto OS image, its packages, kernel config, and network services (SSH, TLS, exposed daemons, web). Goal: from one onboarded target, produce a clear **SBOM**, **SAST**, and simulated **DAST/Pentest** across *both* layers. ### Coverage matrix (status as of this issue) | Chain | PLC / CODESYS layer | Yocto-Linux layer | |---|---|---| | **SBOM** | ❌ control-app deps + runtime version → **#166** | 🟡 #150 (bitbake/SPDX), #151/#128 (image SBOM) | | **SAST** | 🟡 ST + PLCopen-ST only; native `.project` + LD/FBD/SFC/CFC → **#165** | 🟡 source Semgrep umbrella exists; recipe/kernel-config depth via #151 (EMBA) | | **DAST** | ❌ HTTP-only today; ICS protocols → #148 | 🟡 #149 (QEMU boot → DAST) | | **Pentest** | ❌ `supports_pentest(PlcSps)=false`; soft-PLC + ICS modules → #148 | 🟡 #149 (QEMU → pentest) | | **Matrix wiring** | ❌ PlcSps offers *only* control-logic → **#164** | ✅ EmbeddedLinuxYocto offers full set | Legend: ✅ done · 🟡 issue exists / partial · ❌ gap. ### Convergence problem Onboarding binds one `TargetType` per target, but this device is simultaneously `PlcSps` **and** `EmbeddedLinuxYocto`. **#A** decides how the two layers converge (composite PlcSps that also runs firmware SBOM/CVE + DAST/pentest when those artifacts/endpoints are attached, vs. two linked targets). ### What to ask the customer (once the gaps are closed) 1. **PLCopen XML export** of the CODESYS project (interim until #B reads native `.project`). 2. **Device firmware image** (Yocto) + CODESYS **runtime version**. 3. A reachable **WebVisu / OPC UA** endpoint, or agreement to run **CODESYS Control for Linux SL** (soft-PLC container) + a **runqemu** Yocto image for safe DAST/pentest. ### Tracks - **New:** #164 composite matrix · #165 CODESYS native + graphical-language SAST · #166 control-app SBOM - **Existing:** #122 matrix · #128/#130 onboarding specifics · #148 PLC dynamic · #149 Yocto dynamic · #150 bitbake/SPDX · #151 FirmwareStatic Implementation order: **#164 → #166 → #165 → (#148/#149 ICS dynamic)**.
sharang added this to the Onboarding v1 milestone 2026-07-16 10:40:57 +00:00
sharang added the epicenhancementonboarding labels 2026-07-16 10:40:57 +00:00
sharang commented 2026-07-16 22:04:34 +00:00
Author
Owner
Copy Link
Copy Source

Current-state audit (2026-07-17) — frame is in place, engine is not

Traced the Yocto/firmware path in code. The scaffolding exists but nothing behind it processes a real Yocto artifact, so the matrix listing these scans can read as "done" when it isn't:

  • EmbeddedLinuxYocto + the PlcSps firmware layer offer FirmwareStatic + Sbom + Cve in scan_matrix.rs, and the classifier maps bitbake→Yocto — but:
  • FirmwareStatic is a stub — a matrix entry + a ScanPhase only; there is no firmware_static.rs and nothing runs it. → #151
  • tramiton has no bitbake provider (v0.4.1), so the bitbake→Yocto mapping never fires from real detection. → #150 (now re-scoped to our classifier + SPDX-ingest, no tramiton dep).
  • Firmware SBOM today is tramiton's source reproducible build (nix seal_and_build), proven for bare-metal MCU (STM32). It does not run a bitbake image build, so no Yocto SBOM is produced today.

Net: the Yocto device-layer coverage is greenfield. What works today = CODESYS control-app SAST/SBOM/CVE + bare-metal/RTOS MCU firmware. Ownership of the Yocto layer stays in this repo: SPDX-ingest (#150) + binary-image static/SBOM (#151) + dynamic QEMU (#149).

## Current-state audit (2026-07-17) — frame is in place, engine is not Traced the Yocto/firmware path in code. The **scaffolding** exists but nothing behind it processes a real Yocto artifact, so the matrix listing these scans can read as "done" when it isn't: - **`EmbeddedLinuxYocto` + the PlcSps firmware layer** offer `FirmwareStatic` + `Sbom` + `Cve` in `scan_matrix.rs`, and the classifier *maps* `bitbake→Yocto` — but: - **`FirmwareStatic` is a stub** — a matrix entry + a `ScanPhase` only; there is no `firmware_static.rs` and nothing runs it. → **#151** - **tramiton has no bitbake provider (v0.4.1)**, so the `bitbake→Yocto` mapping never fires from real detection. → **#150** (now re-scoped to *our* classifier + SPDX-ingest, no tramiton dep). - **Firmware SBOM today** is tramiton's source *reproducible build* (nix `seal_and_build`), proven for bare-metal MCU (STM32). It does **not** run a bitbake image build, so **no Yocto SBOM is produced today**. **Net:** the Yocto device-layer coverage is greenfield. What works today = CODESYS control-app SAST/SBOM/CVE + bare-metal/RTOS MCU firmware. Ownership of the Yocto layer stays in this repo: SPDX-ingest (**#150**) + binary-image static/SBOM (**#151**) + dynamic QEMU (**#149**).
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 epic 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#167