` — variable declarations - `` → `` — individual networks - `` inside CompileUnit — LAD/FBD network logic as a directed graph - `` elements — variable references with scope and UID - `` elements — instructions (contacts, coils, function calls) - `` elements — connections between parts (data/signal flow) - `` — SCL compile-unit content, including inline SCL in LAD/FBD - `` — block and network comments (valuable for process context) - Root block kind (`SW.Blocks.FB`, `SW.Blocks.FC`, `SW.Blocks.OB`, or `SW.Blocks.GlobalDB`) and `` elements such as ``, ``, and `` (Optimized/Standard) Validate XML against the installed V21 schemas rather than assuming a historical schema revision. The installed SCL schema is `SW.PlcBlocks.SCL_v4.xsd`; LAD/FBD and shared interface schemas are separate. For LAD/FBD analysis, reconstruct the logic flow from the `` graph: Parts are nodes, Wires are edges. Follow Powerrail → Contact chain → Coil/Function to understand each network's behavior. If a required context item (declarations, UDTs, call paths, tag tables, or hardware mapping) is not supplied, continue only as a limited review. The final report must include a context manifest and mark affected findings as inference-based where the missing context prevents confirmation. ## Analysis workflow The analysis is performed in sequential passes. Each pass loads one reference file, analyzes the code through that specific lens, and produces findings. **Critical instruction:** After each pass, Claude summarizes the findings from that pass in a compact internal list before loading the next reference. This prevents token pressure from accumulating raw analysis across all passes. ### Pass order | Pass | Reference file | Focus | |------|---------------|-------| | 1 | `references/process-architect.md` | Physical plausibility and process context | | 2 | `references/security-practices.md` | Top 20 Secure PLC Coding Practices + communication hardening | | 3 | `references/threat-mapping.md` | MITRE ATT&CK for ICS technique identification | | 4 | `references/compiler-critic.md` | Siemens platform bugs, CWE memory safety, safety boundary | | 5 | `references/hardware-reviewer.md` | Hardware config, access settings, network security | **Pass order rationale:** Process context comes first because understanding what the code physically controls determines the severity of all subsequent findings. A missing range check on a status indicator is Low; the same flaw on a chemical dosing pump is Critical. ### Per-pass procedure Before starting the passes, build a compact context manifest: - **Code:** pasted/exported blocks, block names, language, line/network references - **Declarations:** VAR_INPUT, VAR_OUTPUT, VAR_IN_OUT, VAR_STATIC, VAR_TEMP, constants - **Types:** UDTs, arrays, structures, optimized vs standard access metadata when known - **Flows:** call tree, cross references, external write sources, HMI/SCADA inputs - **Hardware:** CPU, communication settings, network interfaces, safety-related mapping - **Verification:** baseline compile status if available, and whether simulation was run For each pass: 1. Load the reference file 2. Work through every checklist item against the provided code 3. Record each finding with: severity, category tag, location, evidence, inference level, description, impact, remediation, and verification requirement 4. Produce a compact summary of findings from this pass 5. Proceed to next pass After all passes, run a final verification synthesis: - Challenge high/critical findings against the context manifest - Downgrade or label findings that depend on missing UDTs, call paths, or hardware mapping - Flag any proposed remediation that requires a compile check, simulation, or safety review - Do not present generated PLC code as deployable without compile and engineering validation Every finding must be source-backed: cite the supplied line/network/XML/SD node or retrieved artifact that supports it. A checklist match without the required context is a review question or verification request, not a confirmed vulnerability. ### Hardware reviewer conditionality If no hardware configuration data is available (user only provided code, no HW config, no hardware export), the Hardware Reviewer pass still runs but produces a single finding: ``` #### [INFO] Hardware configuration not available - **Category:** HW-REVIEW - **Description:** No hardware configuration data was provided. The following checks could not be performed: PUT/GET access status, web server settings, communication protocol security, access level configuration, protection level status. - **Evidence:** No hardware configuration export was available. - **Inference level:** Confirmed limitation - **Verification required:** Provide a hardware configuration export. - **Remediation:** Provide a hardware configuration export for a complete security assessment. ``` ## Output format After all passes complete, merge findings, deduplicate (same issue found by multiple passes gets the highest severity assigned and cross-references both categories), and sort by severity. ```markdown ## PLC Code Analysis Report **Analyzed:** [block names / file names] **Input format:** SCL/ST / SIMATIC SD / SimaticML XML (SCL/LAD/FBD) **Analysis date:** [date] **Passes completed:** Process Architect, Security Practices, Threat Mapping, Compiler Critic, Hardware Reviewer, Verification Synthesis ### Context Manifest | Context item | Status | Source | |--------------|--------|--------| | Block logic | Provided / Missing | Paste / file / export | | Variable declarations | Complete / Partial / Missing | block interface / XML / YAML | | UDT and array definitions | Complete / Partial / Missing | source / export | | Call tree and cross references | Complete / Partial / Missing | export / cross-reference listing | | Tag tables and external inputs | Complete / Partial / Missing | tag table export | | Hardware and network config | Complete / Partial / Missing | hardware export | | Compile baseline | Clean / Warnings / Errors / Not run | TIA Portal compile output / not available | ### Summary | Severity | Count | |----------|-------| | CRITICAL | N | | HIGH | N | | MEDIUM | N | | LOW | N | | INFO | N | ### Findings #### [CRITICAL] Finding title - **Category:** TOP20-P08 / CWE-787 / T0836 / HW-PUTGET (one or more) - **Location:** FB_MixerControl, Line 47 / Network 3 - **Evidence:** Direct source evidence or supplied context supporting the finding - **Inference level:** Confirmed / Probable / Suspicious / Context-limited - **Confidence:** High / Medium / Low - **Description:** Clear explanation of the issue - **Impact:** What could happen if this is exploited or left unaddressed - **Remediation:** Specific, actionable fix with code example where applicable - **Verification required:** compile check / simulation / safety review / hardware review - **References:** Relevant standard or practice citation --- [... next finding ...] ``` ### Severity definitions | Severity | Criteria | |----------|----------| | CRITICAL | Direct risk to physical safety, process integrity, or enables remote code execution. Immediate action required. | | HIGH | Significant security gap exploitable by network-level attacker, or logic flaw affecting process control under fault conditions. | | MEDIUM | Violation of secure coding practice that increases attack surface or reduces defense-in-depth, but requires additional conditions to exploit. | | LOW | Code quality or style issue that indirectly weakens security posture. Best-practice deviation without immediate risk. | | INFO | Observation, recommendation, or note about missing context that prevented a complete check. | ## Limitations and honest reporting Claude must NOT: - Invent findings to fill the report — if a pass finds nothing, report "No issues identified" - Speculate about code behavior without evidence from the provided source - Claim certainty about runtime behavior that depends on CPU configuration not provided - Hallucinate variable names, block numbers, or line references Claude MUST: - Clearly state when a finding is based on inference vs. direct evidence - Note when analysis is limited by missing context (e.g., UDT definitions not provided) - Distinguish between confirmed violations and suspicious patterns worth investigating