b2f4aa9435
After the package/repo rename in #604, the English docs were updated to use gsd-core/... paths, but the four translated doc trees (ja-JP, zh-CN, ko-KR, pt-BR) and .changeset/README.md were never updated and still referenced the pre-rename get-shit-done/ runtime directory, which no longer exists. This commit brings the translations in line with the English docs: - docs/{ja-JP,zh-CN,ko-KR,pt-BR}/**/*.md (57 files): get-shit-done/ -> gsd-core/ (path references) #references-get-shit-donereferencesmd -> #references-gsd-corereferencesmd (anchor in INVENTORY -> ARCHITECTURE links) - .changeset/README.md:9 issue URL: open-gsd/get-shit-done-redux -> open-gsd/gsd-core Legacy references intentionally preserved (historical record): - CHANGELOG.md, .changeset/archived/*, docs/RELEASE-NOTES-LEGACY.md - docs/cleanup-get-shit-done-cc.md, docs/adr/*, docs/research/* - docs/{ja-JP,ko-KR}/superpowers/plans/2026-03-18-* (developer's local paths) - docs/{INVENTORY,README,FEATURES,installer-migrations}.md (rename-history descriptions, some tagged <!-- gsd-allow-legacy-name -->) - Code/tests implementing or testing legacy-cleanup logic (bin/install.js, gsd-core/bin/lib/legacy-cleanup.cjs, scripts/lint-legacy-dir-name.cjs, migration sources/tests) No source code changes — documentation only. Fixes #2420
17 KiB
GSD Core セキュリティモデル
解説 — このドキュメントは、GSD Core がなぜこのようなセキュリティ姿勢を持っているか、そして 各レイヤーがどのように組み合わさるか を説明します。すべてのフックパラメーターのリファレンスではありません。
/gsd-secure-phaseコマンドとそのオプションについては、コマンド を参照してください。実装レベルのフックアーキテクチャについては、アーキテクチャ § フックシステム を参照してください。組織全体のセキュリティベースライン（スキャナー制御、インシデントチェックリスト、所有権モデル）については、SECURITY.md を参照してください。
AI 駆動開発が専用のセキュリティ姿勢を必要とする理由
従来のコードエディターはあなたに代わって任意のパッケージを実行しません。GSD Core は実行します。調査 → 計画 → 実行パイプラインは「パッケージ名を指定する」から「npm install <package> を実行する」まで、「計画アーティファクトを書く」から「そのアーティファクトを LLM システムプロンプトとして使う」までの完全なパスを自動化します。各自動化ステップは人間をループから外します——そして各除去は潜在的な攻撃面です。
GSD Core のセキュリティモデルは一つの組織原則の上に構築されています：多層防御。単一の制御が完璧だとは想定しません。複数の重複したレイヤーがそれぞれ異なるクラスのリスクを軽減し、合わせて全体を完全に排除することなく攻撃面を実質的に悪用しにくくします。このドキュメントの末尾にある正直な要約は、システムが何に対して保護できないかを説明します。
レイヤー 1 — サプライチェーン保護：パッケージ正当性ゲート
脅威
AI モデルはパッケージ名を幻覚します。これはまれな失敗モードではありません：2025 年の研究では、AI が生成するパッケージ参照のおよそ 20% が正規のパッケージに対応しない幻覚された名前であることが記録されています。これらの幻覚された名前のサブセット——同じ研究でおよそ 43%——はプロンプトをまたいで一貫して繰り返され、攻撃者は AI ツールが一般的に生成する名前を観察し、npm、PyPI、または crates.io でそれらの名前を悪意のあるポストインストールスクリプト付きで事前登録できます。この技術は スロップスクワッティング と呼ばれます。
スロップスクワッティングの陰湿な点は、npm view を通過する幻覚された名前が 正当に見える ことです。レジストリエントリは誰かがその名前を登録したことを証明するだけです——パッケージが AI の言う通りのことをするとも、正規のユーザーがいるとも、インストールスクリプトが安全だとも証明しません。ゲートがなければ、幻覚された名前は GSD の調査者 → プランナー → エグゼキューターパイプラインを検出されずに流れ、最終的にあなたのマシンで npm install <attacker-package> として実行されるでしょう。
ゲートの仕組み
ゲートは 3 つのパイプラインステージにわたって動作します：
調査ステージ。 gsd-phase-researcher が外部パッケージを推奨するとき、それぞれに対して slopcheck install <pkgs> --json を実行します。結果は RESEARCH.md の ## Package Legitimacy Audit テーブルに書き込まれます。[SLOP]（高信頼度の幻覚または攻撃者登録済み）とタグ付けされたパッケージは、ファイルが保存される前に RESEARCH.md から完全に除去されます。それらはプランナーに届きません。
計画ステージ。 gsd-planner は監査テーブルを読み取ります。[SUS]（疑わしい：新規登録、低ダウンロード数、ソースリポジトリなし、または人気パッケージに近い命名パターン）または [ASSUMED]（直接レジストリ検証ではなく WebSearch から取得）とタグ付けされたパッケージについて、プランナーはインストールステップの前に checkpoint:human-verify タスクを挿入します。チェックポイントにはレジストリページへの直接リンクと、確認すべき具体的な事項が含まれます：メンテナー履歴、イシュートラッカーの活動、疑わしいインストールスクリプトがないこと。
実行ステージ。 インストールが失敗した場合、gsd-executor はチェックポイントを表示して停止します。それ自体が悪意のある可能性のある代替パッケージ名をサイレントに試みません。これはエグゼキューターの動作における明示的なルールです（エグゼキュータエージェント定義の RULE 3）。
WebSearch パッケージが常に [ASSUMED] である理由
WebSearch を通じて発見されたパッケージ名は、npm view が成功するかどうかに関わらず [ASSUMED] とタグ付けされます。レジストリに存在するパッケージは、インストールしても安全なパッケージと同じではありません。npm view は登録を証明するだけで、正当性を証明しません。[ASSUMED] タグは [SUS] と同じ人間検証チェックポイントをトリガーし、未検証のウェブ検出推奨は常にインストール前に人間のレビューを受けることを保証します。
エコシステムカバレッジ
調査者は単一の汎用チェックではなく、レジストリ固有の検証コマンドを使います：
- Node.js：
npm view - Python：
pip index versions - Rust：
cargo search
これは 2025 年の USENIX 研究によると約 9% の割合で発生するクロスエコシステム幻覚をカバーします——AI が実際に使用しているエコシステムには存在しない別のエコシステムのパッケージを推奨するケース。
グレースフルデグレデーション
slopcheck が利用できない場合（インストールされていない、または調査時に pip インストールが失敗した）、GSD は可能な限り厳格なフォールバックを適用します：すべての推奨パッケージが [ASSUMED] とタグ付けされ、プランナーはすべてのインストールを checkpoint:human-verify タスクでゲートします。調査と計画は通常どおり進行します——システムはツールの依存関係の欠落でハードフェイルすることはありません。これは通常フローより意図的に厳格です：slopcheck の利用不可は、すべてのパッケージインストールに人間のチェックポイントを付与することを意味します。
slopcheck ツールは MIT ライセンスで pip インストール可能です。廃止された場合でも、[ASSUMED] ゲートフォールバックにより、人間チェックポイントカバレッジが維持されます。
レイヤー 2 — プロンプトインジェクション防御
脅威
GSD Core は LLM システムプロンプトになる Markdown ファイルを生成します。調査パイプラインは外部ウェブコンテンツを読み取ります；計画パイプラインはユーザー提供のテキスト（--text-file、--prd）を組み込みます；実行パイプラインは後でエージェントコンテキストとして再読み取りされる計画アーティファクトを書きます。これらのアーティファクトに流れ込む任意のユーザー制御テキストは、潜在的な 間接プロンプトインジェクション ベクターです——一度システムプロンプトの中に入ると、エージェントの指示を上書きしたり情報を窃取しようとする攻撃者制御の文字列。
防御の仕組み
GSD Core はプロンプトインジェクションを 3 つのレベルで対処します。
入力検証（security.cjs）。 gsd-core/bin/lib/security.cjs モジュールは中心的なセキュリティユーティリティです。以下を提供します：
- パストラバーサル防止：ユーザー提供のファイルパス（
--text-file、--prd）はプロジェクトディレクトリ内で解決されることを検証し、macOS の/var→/private/varシンリンク解決を明示的に処理 - プロンプトインジェクション検出：既知のインジェクションパターン（ロールオーバーライド、指示バイパス、システムタグインジェクション）が計画アーティファクトに入る前にユーザー提供テキストをスキャン
- 安全な JSON パース：クラフトされた JSON ペイロードによるプロトタイプ汚染攻撃を防ぐラッパー
- シェル引数検証：サブシェルコマンドに渡される引数の使用前検証
ランタイムフック：gsd-prompt-guard.js。 このフックは .planning/ ファイルを対象とするすべての Write または Edit 呼び出しで発火します。書き込まれるコンテンツを security.cjs と同じインジェクションパターンでスキャンします（サブセットがフックの独立性のために直接インライン化されています——フックはモジュールを require() しないため、モジュールパスが変わっても実行されます）。検出は アドバイザリーのみ：フックは発見をログに記録しますが書き込みをブロックしません。理由は、正当な計画書き込みでの偽陽性ブロックは、セカンダリスキャンレイヤーで見逃したインジェクションより破壊的だからです。
ランタイムフック：gsd-read-injection-scanner.js。 このフックはすべての Read ツール呼び出しの出力で発火します。GSD がエージェントのコンテキストに組み込もうとしているファイルの 読み取ったばかりのコンテンツ をスキャンし、攻撃者が命令を埋め込んでいるケースをキャッチします。
CI スキャナー。 prompt-injection-scan.security.test.cjs はテストスイートの一部として、すべてのエージェント、ワークフロー、コマンドファイルに埋め込まれたインジェクションベクターをスキャンします。これは GSD ソース自体でのインジェクション試みをキャッチします——たとえば、ワークフローファイルにロールオーバーライド命令を追加するよう変更したサプライチェーン攻撃。
Read Injection Scanner vs Prompt Guard
2 つのフックは補完的な面をカバーします。gsd-prompt-guard.js は 計画アーティファクトへの書き込み を監視します——植え付けられているインジェクションをキャッチします。gsd-read-injection-scanner.js は 任意のファイルの読み取り を監視します——外部コンテンツ（依存関係の README、サードパーティの設定ファイル、ユーザー提供のドキュメント）から取り込まれるインジェクションをキャッチします。合わせて、取り込み → 保存 → 再読み取りのライフサイクルを括ります。
レイヤー 3 — リポジトリおよび依存関係の整合性
GSD のランタイム動作の上流で、open-gsd 組織はリポジトリおよびパッケージレベルで制御を強制しています。これらは docs/security/baseline.md に完全に記録されており、ここでは完全性のために要約します。
依存関係の整合性。 すべてのサードパーティ依存関係は package-lock.json でピン留めされ、インストール前に公開されたチェックサムに対して検証されます。scripts/check-npm-integrity.cjs ゲートは CI 時に無効なバージョン、欠落パッケージ、余分なパッケージを検出します。これにより GSD 自身の依存関係に対する依存関係混同とタイポスクワッティング攻撃を軽減します。
シークレットスキャン。 すべてのコミットと PR にはハードコードされたシークレットのスキャンが実施されます。意図的なテストフィクスチャは、プロジェクト標準の除外文法でアノテーションが必要です（アノテーション形式については SECURITY.md を参照）。アノテーションなしの抑制は CI を失敗させます。
ロケールセーフなテキストスキャン。 出力とユーザー向け文字列は、Unicode ホモグリフ、双方向オーバーライド文字、不可視の Unicode についてスキャンされます——CVE-2021-42574（「トロイの木馬ソース」）で記録された、差分に悪意のあるコンテンツを隠すことができる攻撃クラス。
トレードオフと限界
ここで説明するセキュリティモデルは、AI 駆動開発の攻撃面を意味のある程度低減します。サプライチェーンリスクを排除するものではありません。
パッケージ正当性ゲートが低減するもの： 幻覚されたまたは攻撃者登録済みのパッケージが人間のチェックポイントなしに npm install に届く確率。[SLOP] ゲートは高信頼度の悪質なパッケージを完全に除去します；[SUS]/[ASSUMED] ゲートは実行前に人間のレビューを要求します。これによりスロップスクワッティング攻撃の成功コストが実質的に引き上げられます。
パッケージ正当性ゲートが排除しないもの： 後で侵害された正規パッケージ（アカウント乗っ取り、そのパッケージ自体のツリーでの依存関係混同）は、調査時に登録シグナルを確認する slopcheck ではキャッチされません。その種の攻撃に対するコントロールは、依存関係整合性レイヤーのロックファイルと npm audit です。
プロンプトインジェクション防御が低減するもの： 計画アーティファクト内のユーザー制御テキストがエージェントの指示を正常に上書きする確率。既知のインジェクション形式のパターンマッチングは一般的なケースをキャッチします；新しいジェイルブレイクや低シグナルのインジェクションは検出されない可能性があります。アドバイザリーのみの姿勢は、検出がログに記録されるがブロックされないことを意味します——検出でハード停止するコストではなく、ワークフロー継続性を保持する意図的な選択。
プロンプトインジェクション防御が排除しないもの： 既知のパターンにマッチしない十分に創造的なインジェクション、またはフックがカバーしないチャンネルを通じて届くインジェクション（たとえば、サブエージェントがドキュメントをブラウズする際に読み取る依存関係の公開 README にインジェクトされたコンテンツ）。多層防御は各レイヤーが攻撃を困難にすることを意味し、単一のレイヤーが不可能にすることを意味しません。
脆弱性の報告。 https://github.com/open-gsd/gsd-core/security/advisories/new でプライベートな GitHub セキュリティアドバイザリを通じて報告してください。パブリックなイシューを開かないでください。対応タイムラインと開示ポリシーについては SECURITY.md を参照してください。
Related
- コマンド — セキュリティ関連フラグを含む
/gsd-secure-phaseと/gsd-code-review - アーキテクチャ § フックシステム — すべてのフック、そのイベントトリガー、安全性プロパティの実装詳細
- SECURITY.md — 脆弱性報告、組織全体のセキュリティベースライン、シークレットスキャン除外ガバナンス、依存関係整合性検証
- ドキュメント索引