ONB · SAST: CODESYS native project (.project/.projectarchive) + graphical languages (LD/FBD/SFC/CFC) #165

Open
opened 2026-07-16 10:40:47 +00:00 by sharang · 0 comments
Owner

Problem

The PLC SAST scanner parses Structured Text and PLCopen-XML ST bodies only:

  • plcopen.rs: "FBD/LD/SFC bodies are skipped."
  • Native CODESYS .project / .projectarchive / .library are proprietary binary
    and unreadable; .project is in the extension list but roxmltree fails on binary → 0 POUs.

So control logic written in LD/FBD/SFC/CFC (common in CODESYS) is silently not
analyzed, and a customer's native project yields nothing unless they hand-export
PLCopen XML.

Work

  1. .projectarchive ingest — it's a zip; extract it, then locate/convert the
    contained project. Interim: detect a native .project and emit an actionable
    finding/fact telling the user to Export PLCopenXML (documented ask).
  2. Graphical POU bodies — parse PLCopen <FBD>/<LD>/<SFC> networks (blocks +
    connections + inVariable/outVariable) into the existing AST so the semantic rules
    run over data flow, not just ST. Start with FBD/LD (block+wire graphs).
  3. CFC (CODESYS-specific continuous function chart) — stretch.
  4. Extend analyze_tree extension routing / content sniffing accordingly.

Interim mitigation

Until native parsing lands, the customer ask is a PLCopen XML export (already
supported for ST bodies). Document this in the onboarding wizard help text.

Files

  • compliance-agent/src/pipeline/plc/plcopen.rs (graphical bodies)
  • compliance-agent/src/pipeline/plc/{ast.rs,rules.rs} (data-flow representation)
  • compliance-agent/src/ingest/ (.projectarchive handling)

Related: #130 (PLC onboarding specifics). Part of the CODESYS-on-Yocto tracker.

### Problem The PLC SAST scanner parses **Structured Text** and **PLCopen-XML ST bodies** only: - `plcopen.rs`: "FBD/LD/SFC bodies are skipped." - Native CODESYS `.project` / `.projectarchive` / `.library` are **proprietary binary** and unreadable; `.project` is in the extension list but roxmltree fails on binary → 0 POUs. So control logic written in **LD/FBD/SFC/CFC** (common in CODESYS) is silently not analyzed, and a customer's native project yields nothing unless they hand-export PLCopen XML. ### Work 1. **`.projectarchive` ingest** — it's a zip; extract it, then locate/convert the contained project. Interim: detect a native `.project` and emit an actionable finding/fact telling the user to **Export PLCopenXML** (documented ask). 2. **Graphical POU bodies** — parse PLCopen `<FBD>`/`<LD>`/`<SFC>` networks (blocks + connections + inVariable/outVariable) into the existing AST so the semantic rules run over data flow, not just ST. Start with FBD/LD (block+wire graphs). 3. **CFC** (CODESYS-specific continuous function chart) — stretch. 4. Extend `analyze_tree` extension routing / content sniffing accordingly. ### Interim mitigation Until native parsing lands, the customer ask is a **PLCopen XML export** (already supported for ST bodies). Document this in the onboarding wizard help text. ### Files - `compliance-agent/src/pipeline/plc/plcopen.rs` (graphical bodies) - `compliance-agent/src/pipeline/plc/{ast.rs,rules.rs}` (data-flow representation) - `compliance-agent/src/ingest/` (`.projectarchive` handling) Related: #130 (PLC onboarding specifics). Part of the CODESYS-on-Yocto tracker.
sharang added this to the Onboarding v1 milestone 2026-07-16 10:40:47 +00:00
sharang added the enhancementonboarding labels 2026-07-16 10:40:47 +00:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sharang/compliance-scanner-agent#165