plc-code-analysis

plc-code-analysis

目標

PLC コードを複数の観点から体系的にセキュリティおよび品質分析し、重大度順に並べた指摘レポートを作成します。自動化エンジニア向けの「もう一組の目」として機能します。

tia-openness-roadmap からの独立性

このスキルは tia-openness-roadmap によるルーティングの対象ではありません。独自のトリガーパターンを持ち、単独で動作します。Openness ロードマップは、API を介したエンジニアリングの自動化（作成、変更、インポート／エクスポート）を扱います。このスキルは、既存のコードの分析とレビューを扱います。

このスキルは、Openness／VCI 経由でエクスポートされたコード、またはユーザーが貼り付けたコードを使用しますが、特定のラッパーには依存しません。

入力の識別

PLC コードは一般に、次の 3 つの形式のいずれかで届きます。分析の前に、正確な形式と出所を特定してください。

形式 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> — 個々のネットワーク
• CompileUnit 内の <FlgNet> — 有向グラフとして表現された LAD／FBD ネットワークロジック
• <Access> 要素 — スコープと UID を含む変数参照
• <Part> 要素 — 命令（接点、コイル、関数呼び出し）
• <Wire> 要素 — 部品間の接続（データ／信号フロー）
• <StructuredText> — インライン SCL を含む SCL コンパイルユニットの内容
• <Comment> — ブロックおよびネットワークのコメント（プロセスの背景を理解するうえで有用）
• ルートブロックの種類（SW.Blocks.FB、SW.Blocks.FC、SW.Blocks.OB、または SW.Blocks.GlobalDB）と、<Number>、<ProgrammingLanguage>、<MemoryLayout>（Optimized／Standard）などの <AttributeList> 要素

過去のスキーマリビジョンを前提とせず、インストール済みの V21 スキーマに照らして XML を検証してください。インストール済みの SCL スキーマは SW.PlcBlocks.SCL_v4.xsd です。LAD／FBD 用のスキーマと共有インターフェース用のスキーマはそれぞれ別です。

LAD／FBD の分析では、<FlgNet> グラフからロジックの流れを再構築します。Part はノード、Wire はエッジです。Powerrail → Contact チェーン → Coil／Function の順に追い、各ネットワークの動作を把握してください。

必要なコンテキスト項目（宣言、UDT、呼び出しパス、タグテーブル、またはハードウェアマッピング）が提供されていない場合は、限定的なレビューとしてのみ続行してください。最終レポートにはコンテキストマニフェストを含め、コンテキストの不足により確認できない指摘には推論に基づくものと明記してください。

分析ワークフロー

分析は順次のパスに分けて行います。各パスで参照ファイルを 1 つ読み込み、その観点からコードを分析して、指摘を作成します。

重要な指示： 各パスの終了後、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	ハードウェア構成、アクセス設定、ネットワークセキュリティ

パスの順序の理由： コードが物理的に何を制御するのかを理解することで、それ以降のすべての指摘事項の深刻度が決まるため、最初にプロセスの文脈を確認します。ステータスインジケーターの範囲チェック漏れは Low ですが、化学薬品注入ポンプで同じ不備がある場合は Critical です。

各パスの手順

各パスを開始する前に、簡潔なコンテキストマニフェストを作成します。

• コード： 貼り付け／エクスポートされたブロック、ブロック名、言語、行／ネットワーク参照
• 宣言： VAR_INPUT、VAR_OUTPUT、VAR_IN_OUT、VAR_STATIC、VAR_TEMP、定数
• 型： UDT、配列、構造体、判明している場合は最適化アクセスと標準アクセスのメタデータ
• フロー： 呼び出しツリー、相互参照、外部からの書き込み元、HMI／SCADA 入力
• ハードウェア： CPU、通信設定、ネットワークインターフェイス、安全関連のマッピング
• 検証： 入手可能な場合はベースラインのコンパイル状態と、シミュレーションの実施有無

各パスでは、次の手順を実施します。

1. 参照ファイルを読み込みます
2. 提供されたコードに照らして、チェックリストのすべての項目を確認します
3. 各指摘事項について、深刻度、カテゴリタグ、場所、証拠、推論レベル、説明、影響、修正方法、検証要件を記録します
4. このパスの指摘事項を簡潔にまとめます
5. 次のパスに進みます

すべてのパスの完了後、最終検証の統合を行います。

• コンテキストマニフェストに照らして、深刻度が High／Critical の指摘事項を再検討します
• UDT、呼び出しパス、またはハードウェアマッピングの不足に依存する指摘事項は、深刻度を下げるか、その依存関係を明記します
• コンパイルチェック、シミュレーション、安全レビューが必要な修正案にはフラグを付けます
• コンパイルとエンジニアリング検証を経ていない生成済み PLC コードを、デプロイ可能なものとして提示しないでください

すべての指摘事項には、根拠となるソースが必要です。裏付けとなる、提供された行／ネットワーク／XML／SD ノードまたは取得済みアーティファクトを引用してください。必要なコンテキストを欠いたチェックリスト項目との一致は、確認済みの脆弱性ではなく、レビュー時の確認事項または検証依頼です。

ハードウェアレビュアーの条件

ハードウェア構成データがない場合（ユーザーがコードのみを提供し、ハードウェア構成もハードウェアのエクスポートデータもない場合）、ハードウェアレビュアーのパスは実施しますが、指摘事項は 1 件のみとします。

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

深刻度の定義

深刻度	基準
CRITICAL	物理的な安全性やプロセスの完全性に直接的なリスクをもたらす、またはリモートコード実行を可能にする。直ちに対応が必要です。
HIGH	ネットワークレベルの攻撃者が悪用可能な重大なセキュリティ上の不備、または障害発生時のプロセス制御に影響するロジック上の欠陥です。
MEDIUM	攻撃対象領域を拡大する、または多層防御を弱めるセキュアコーディングプラクティスの違反ですが、悪用には追加の条件が必要です。
LOW	セキュリティ態勢を間接的に弱める、コード品質またはスタイル上の問題です。ベストプラクティスからの逸脱ですが、差し迫ったリスクはありません。
INFO	完全な確認を妨げたコンテキストの不足に関する所見、推奨事項、または注記です。

制限事項と誠実な報告

Claude は次のことをしてはいけません。

• レポートを埋めるために調査結果を捏造すること。確認で何も見つからなかった場合は、「問題は特定されませんでした」と報告します。
• 提供されたソースの証拠なしに、コードの動作を推測すること。
• 提供されていない CPU 構成に依存する実行時の動作について、確実であると主張すること。
• 変数名、ブロック番号、行番号を幻覚すること。

Claude は次のことを必ず行わなければなりません。

• 調査結果が推論に基づくものか、直接的な証拠に基づくものかを明確に示します。
• コンテキスト不足（例：UDT 定義が提供されていないこと）によって分析が制限される場合は、その旨を記載します。
• 確認済みの違反と、調査する価値のある疑わしいパターンを区別します。