plc-code-analysis

plc-code-analysis

目标

对 PLC 代码进行结构化、多角度的安全与质量分析，生成按严重程度排序的问题报告。充当自动化工程师的自动化“第二双眼睛”。

独立于 tia-openness-roadmap

此技能不会由 tia-openness-roadmap 路由。它拥有自己的触发模式，可独立运行。Openness 路线图负责工程自动化（通过 API 创建、修改、导入/导出）。此技能负责分析和审查现有代码。

此技能使用通过 Openness/VCI 导出的代码或用户粘贴的代码，但不依赖特定的封装工具。

输入识别

PLC 代码通常以三种方式之一提供。分析前，请识别准确的格式和来源。

格式 1 — 原始 SCL / Structured Text

用户粘贴或上传 .scl、.st 文件或纯文本 PLC 代码。这是最简单的情况。直接按文本解析。查找 FUNCTION_BLOCK、FUNCTION、ORGANIZATION_BLOCK、DATA_BLOCK 标头，以识别块边界。

格式 2 — SIMATIC SD 源文档（V21）

TIA Portal V21 可将 S7-1200/S7-1500 SCL、LAD、FBD、DB、F-DB、UDT 和 F-UDT 内容导出为基于文本的 SIMATIC Source Document 格式。如果 .s7dcl 声明/代码文档和 .s7res 资源同时存在，请结合分析。保留文档路径和标识符，以便追溯问题。

SIMATIC SD 是源代码表示形式，不是运行时证据。特别是，即使 SCL 块无法通过编译检查，也可以将其导出；导出成功并不能证明编译、下载或 PLC 行为成功。

格式 3 — SimaticML XML（导出的 LAD/FBD/SCL）

用户提供从 TIA Portal 导出的 .xml 文件。这些文件遵循 SimaticML 架构。 主要导航位置：

• <SW.Blocks.FB>、<SW.Blocks.FC>、<SW.Blocks.OB>、<SW.Blocks.DB> — 块类型
• <Interface> → <Section Name="Input|Output|InOut|Static|Temp|Constant"> — 变量声明
• <ObjectList> → <CompileUnit> — 各个网络
• <FlgNet>（位于 CompileUnit 内）— LAD/FBD 网络逻辑，表示为有向图
• <Access> 元素 — 带作用域和 UID 的变量引用
• <Part> 元素 — 指令（触点、线圈、函数调用）
• <Wire> 元素 — 部件之间的连接（数据/信号流）
• <StructuredText> — SCL 编译单元内容，包括 LAD/FBD 中的内嵌 SCL
• <Comment> — 块和网络注释（对了解工艺背景很有价值）
• 根块类型（SW.Blocks.FB、SW.Blocks.FC、SW.Blocks.OB 或 SW.Blocks.GlobalDB）以及 <AttributeList> 元素，例如 <Number>、<ProgrammingLanguage> 和 <MemoryLayout>（Optimized/Standard）

请使用已安装的 V21 架构验证 XML，而不要假定其遵循历史架构版本。已安装的 SCL 架构为 SW.PlcBlocks.SCL_v4.xsd；LAD/FBD 和共享接口架构则是单独的。

对于 LAD/FBD 分析，请根据 <FlgNet> 图重建逻辑流：Parts 是节点，Wires 是边。沿 Powerrail → Contact 链 → Coil/Function 跟踪，以理解每个网络的行为。

如果未提供必要的上下文信息（声明、UDT、调用路径、标签表或硬件映射），请仅继续进行有限审查。最终报告必须包含上下文清单；如果缺失的上下文导致无法确认问题，则须将受影响的问题标记为基于推断。

分析工作流

分析按顺序分轮进行。每轮加载一个参考文件，使用该文件所对应的视角分析代码，并生成问题。

重要指示： 每轮结束后，Claude 都要在加载下一个参考文件前，将本轮发现概括为简洁的内部列表。这样可以避免所有轮次中积累的原始分析内容造成令牌压力。

检查顺序

检查	参考文件	重点
1	references/process-architect.md	物理合理性和流程上下文
2	references/security-practices.md	PLC 安全编码 20 项最佳实践 + 通信加固
3	references/threat-mapping.md	MITRE ATT&CK for ICS 技术识别
4	references/compiler-critic.md	Siemens 平台缺陷、CWE 内存安全、安全边界
5	references/hardware-reviewer.md	硬件配置、访问设置、网络安全

检查顺序说明： 首先了解流程上下文，因为代码实际控制的物理对象决定了后续所有发现的严重程度。状态指示灯缺少范围检查属于低风险；同样的缺陷出现在化学品加药泵上则属于严重风险。

每轮检查流程

开始检查前，先构建一份精简的上下文清单：

• 代码： 粘贴或导出的代码块、块名称、语言、行号/网络引用
• 声明： VAR_INPUT、VAR_OUTPUT、VAR_IN_OUT、VAR_STATIC、VAR_TEMP、常量
• 类型： UDT、数组、结构体；已知时记录优化访问与标准访问的元数据
• 数据流： 调用树、交叉引用、外部写入源、HMI/SCADA 输入
• 硬件： CPU、通信设置、网络接口、安全相关映射
• 验证： 可用时记录基线编译状态，以及是否运行了仿真

每轮检查：

1. 加载参考文件
2. 根据提供的代码逐项检查所有清单项目
3. 记录每项发现，包括：严重程度、类别标签、位置、证据、推断级别、描述、影响、修复措施和验证要求
4. 汇总本轮检查发现
5. 进入下一轮检查

完成所有检查后，进行最终验证综合：

• 根据上下文清单审查高风险/严重风险发现
• 对依赖缺失的 UDT、调用路径或硬件映射的发现，降低严重程度或标注相关依赖
• 标记任何需要编译检查、仿真或安全审查的建议修复措施
• 未经编译和工程验证，不得将生成的 PLC 代码作为可部署代码提供

每项发现都必须有源代码依据：引用所提供的行号/网络/XML/SD 节点或检索到的工件。若上下文不足以满足要求，清单匹配只能作为审查问题或验证请求，不能视为已确认的漏洞。

硬件审查员的适用条件

如果没有可用的硬件配置数据（用户只提供了代码，没有硬件配置或硬件导出文件），硬件审查员仍需执行检查，但只生成一项发现：

#### [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.

输出格式

完成所有检查后，合并并去重发现（多个检查轮次发现的同一问题采用最高严重程度，并交叉引用两个类别），然后按严重程度排序。

## 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 ...]

严重程度定义

严重程度	标准
严重	对人身安全或流程完整性构成直接风险，或可能导致远程代码执行。需要立即采取措施。
高	存在可被网络级攻击者利用的重大安全漏洞，或在故障条件下影响流程控制的逻辑缺陷。
中	违反安全编码实践，增加攻击面或削弱纵深防御，但需要额外条件才能利用。
低	代码质量或风格问题，间接削弱安全态势。偏离最佳实践，但无直接风险。
信息	观察、建议，或说明因缺少上下文而无法完成检查。

局限性与如实报告

Claude 不得：

• 为填充报告而编造发现——如果某一轮检查没有发现任何问题，请报告“未发现问题”
• 在没有所提供源代码作为依据的情况下，推测代码行为
• 对依赖于未提供的 CPU 配置的运行时行为声称确定性
• 臆造变量名、块编号或行号

Claude 必须：

• 明确说明某项发现是基于推断还是直接证据
• 指出分析何时受到上下文缺失的限制（例如，未提供 UDT 定义）
• 区分已确认的违规行为与值得进一步调查的可疑模式