2026年 OpenClaw ClawHub スキルサプライチェーン「本番投入前ゲート」：出所検証、オフラインミラー、読み取り専用マウントと独占リモート Mac 非特権ランタイム面——再現可能な堅牢化チュートリアル＋FAQ

TL;DR — セキュリティ設計メモに貼る用

結論：ダイレクトにインターネットからスキルを解決させたまま、ダイジェスト固定・オフライン昇格・OS レベルの読み取り制約なしで本番ゲートウェイを動かさない。OpenClaw は 管理者権限のない専用 macOS ユーザーで、エンドツーエンドで支配できるハードウェア上で動かす。

• ゲート A — 出所：ベンダ tarball → 社内オブジェクトストア → 署名付きマニフェスト。ドリフトは拒否。
• ゲート B — ミラー：定期 pull＋本番はエアギャップ引き渡し。ランタイムの curl | sh は禁止。
• ゲート C — 読み取り専用：検証済みインストール後のスキルディレクトリを APFS スナップショット化、または bind 相当の読み取り専用ルート。書き込みは /var/tmp/openclaw-scratch のみに閉じる。
• ゲート D — ランタイム：LaunchAgent で非管理者。SIP と Gatekeeper は有効。キーチェーン分離。人間用ログインセッションと共有しない。

1. 脅威モデル：2026 年における「スキル・サプライチェーン」の意味

スキルパッケージは 小さなプログラムです。Markdown に加え、実行フック、スクリプト、ツールマニフェストを含みます。侵害経路は古典的な CI サプライチェーン攻撃と同型——タイポスクワット、セマンティックバージョン範囲の拡大、初回インストール時の MITM、インストール後の自己更新。ゲートは「レジストリが一度だけ間違ってもフェイルクローズする」前提で設計します。

2. ゲート A — 出所検証（ハッシュ、署名、ポリシー as Code）

スキル版ごとに 不変アーティファクト として扱います。

• tarball または OCI レイヤの SHA-256 ダイジェストを Git 管理のマニフェストに固定。CI は不一致で失敗。
• 任意で署名（minisign / Sigstore）を staging／prod 昇格前に検証。
• マニフェストで リスクラベル：network: none|egress|browser、filesystem: read|write-scratch など。ポリシーエンジンが「どこにでも書く」スキルの本番インストールを自動ブロックできるようにする。

運用のコツ：ゲートウェイ起動時はスキル本文ではなく マニフェスト版＋ダイジェストだけをログに残し、監査ログを読みやすく保つ。

3. ゲート B — オフラインミラーと昇格レーン

二段ホップを組む：インターネット接続の puller ジョブが allowlist 済みアーティファクトだけを社内バケットへコピーし、本番ゲートウェイは 社内エンドポイントのみを読む。真のエアギャップなら、リムーバブルメディアやデータダイオード越しの rsync でバケットを渡す。

3.1 ミラー側の受入チェック

• オブジェクトの不変性とバージョニングをバケットで有効化。
• TLS または mTLS の終端は自社インフラ。本番読み取りの前にワイルドカード正向きプロキシを置かない。
• 定期 再検証 ジョブ：オブジェクトを再ハッシュしマニフェストと diff。ビット反転ならページ。

4. ゲート C — スキルルートの読み取り専用マウント

macOS で現実的なのは次の二パターンです。

• 検証済みインストール後のスキルディレクトリを APFS スナップショット化。前進はスナップショット差し替えで行い、インプレースパッチはしない。
• スキルだけを載せた 別ボリュームを起動時に読み取り専用でマウント（該当する場合は mount -o rdonly）。書き込みキャッシュは別 APFS ボリュームに厳しいクォータで分離。

読み取り専用ルートとセットで、エージェントが一時ファイルを置ける 単一の書き込み可能スクラッチ木 を決め、ホームディレクトリ全体への書き込み権を与えない。

5. ゲート D — 独占リモート Mac と非特権ランタイム面

独占リモート Mac（単一テナント、他テナントの CI と同居しない）では、サービスユーザー openclaw-svc を用意し、sudo 不可、インストール接頭辞とスクラッチだけを所有、OpenClaw は LaunchAgent で動かす（GUI オートログインセッションではない）。

5.1 効く macOS コントロール

• スキル同梱のネイティブヘルパには Gatekeeper と Developer ID。
• SIP は有効のまま。無効化を要求するワークフローは拒否。
• ログインキーチェーン分離またはトークンファイル ACL をサービスユーザーに限定——エンジニアの対話セッションと再利用しない。
• ファイアウォール：OpenClaw ゲートウェイの allowlist 以外はデフォルト拒否（MCP／ゲートウェイ runbook 参照）。

6. 再現検証チェックリスト（リリースゲート）

• CI のマニフェストダイジェスト＝ディスク上ダイジェスト＝最終起動ログのダイジェスト。
• スキルルートのマウントが mount 出力で read-only。
• プロセスが非管理者 UID。sudo -l がそのユーザーで空。
• スクラッチのクォータとディスク枯渇前のアラート。
• テーブルトップ：「悪意あるスキルがホームで chmod +x を試す」→ 拒否とログ。

FAQ

本番から直接 ClawHub を読んでもよい？

証明できる緩和策（ダイジェスト固定、ミラーへの TLS ピン留め、インシデント runbook）があるなら可。多くのチームは本番を 社内ミラー経由にします。

読み取り専用マウントは自己更新スキルを壊さない？

意図的に壊します。更新は CI 検証つきの 統制された昇格であり、ランタイムのサプライズではない。

ブラウザ自動化が必要なスキルは？

同一 Mac 上でブラウザプロファイルを分離し、ディスク上限を設け、マニフェストに browser: sandboxed のようにタグ付けして本番利用をポリシーでゲートする。

ベアメタルより VM の方が安全？

場合による。Apple Silicon 上の macOS VM は運用トレードオフがある。物理的に独占した Mac mini と最小権限の組み合わせは、手入れの行き届いていない「安全毛布」VM に勝つことが多い。

このサプライチェーン設計に Apple Silicon Mac mini が合う理由

スキル系ゲートウェイは 常時稼働が前提です。ミラー向けのディスク I/O、エグレス検査の TLS、エージェントがバッチ更新するときのスパイクが重なります。Mac mini（Apple Silicon）は、複数プロセスの Node／Python スタックに向く ユニファイドメモリ帯域と、極めて低いアイドル電力を両立し、数ヶ月ヘッドレスで回す単一テナント「独占」ノードに向きます。

macOS では Gatekeeper、SIP、FileVault をサードパーティ EDR なしの積み上げとして使いやすく、LaunchAgent と SSH は CI や署名パイプラインと同じオペレータースキルで OpenClaw の堅牢化にそのまま流用できます。

上記ゲートを通した ClawHub スキルを、夜間も静かで電力を抑えた筐体で回したいなら、Mac mini M4 は 2026 年時点でもコストパフォーマンスの良い足場の一つです。マニフェストを締め、読み取り専用でマウントし、メトリクスで第二台の要否を判断してください。