セキュリティポリシー

セキュリティ修正は、cc-safety-net の最新リリースにのみ提供されます。それより古いバージョンを使用している場合は、その脆弱性が最新リリースにも影響する場合を除き、報告する前にアップグレードしてください。 このページでは、問題の報告方法を説明します。信頼境界、fail closed の強制、攻撃対象領域については、セキュリティモデルを参照してください。正式なポリシーは、ソースリポジトリの SECURITY.md です。 ブロックされなかったコマンドは公開のバグです。CC Safety Net 自体による有害な動作は非公開の脆弱性です。どちらに当たるか判断できない場合は、公開または非公開の報告を選ぶを読んでください。まず動作を切り分けたい場合は、トラブルシューティングから始めてください。

​

脆弱性を非公開で報告する

セキュリティ脆弱性を公開の GitHub Issue で報告しないでください。 利用できる場合は、リポジトリの GitHub private vulnerability reporting を使用してください。利用できない場合は、メンテナー宛（jliew@420024lab.com）にメールを送ってください。 差し支えのない範囲で、次の情報を含めてください。

• 影響を受ける cc-safety-net のバージョン
• OS とランタイムのバージョン
• 影響を受ける連携（Claude Code、OpenCode、Gemini CLI、GitHub Copilot CLI、Grok Build、Codex など）
• 再現手順と、CC Safety Net を迂回・弱体化・悪用するコマンドまたは入力
• cc-safety-net explain や cc-safety-net doctor の関連する出力
• データ損失、コマンド実行、シークレットの露出など、具体的なセキュリティ影響につながるかどうか

ログやコマンド出力を送る前に、トークン、資格情報、非公開リポジトリ名、機密性のあるファイルパスを削除してください。

​

公開または非公開の報告を選ぶ

CC Safety Net の役割は、選択した安全レベルについて文書化された保証の範囲内で、エージェントによる破壊的コマンドの実行を防ぐことです。ツールがその役割を果たせなかったという報告はバグであり、公開の GitHub Issue で扱います。strict と paranoid の脅威モデルでは、攻撃者（プロンプトインジェクションや敵対的なコンテキスト）が任意の破壊的コマンドを生成できることを前提にしています。そのため「この形式のコマンドは検出されない」と公開しても、攻撃者に新たな能力を与えることにはなりません。むしろ公開したほうが修正は早く進み、ユーザーもカスタムルールという当面の回避策をすぐ用意できます。 一方、シークレットの漏えい、自身のディレクトリ外へのファイル書き込み、改ざんされたパッケージの配布など、ツールが本来しないはずの有害な動作をしたという報告は脆弱性です。この場合は、その自明でない手口自体が秘匿すべき情報になるため、非公開で開示してください。 判断基準は、ツールが破壊的コマンドを止め損ねたのか、それともツール自体が加害の手段になったのかです。

​

セキュリティ問題に該当するもの

次の問題は非公開で報告してください。

• ブロックメッセージ、監査ログ、診断出力、デバッグ出力、誤検知レポートの入力補完を経由したシークレットの漏えい。特定のトークン形式でマスク処理を回避できる場合や、レポートのプレビューが置換済みと表示したパスが実際には残る場合を含みます
• 監査ログの記録や設定処理におけるパストラバーサルおよびファイルシステムの問題。細工された入力によって意図したディレクトリの外に書き込まれる場合
• 公開 npm パッケージやプラグイン配布に影響するサプライチェーンおよびパッケージングの問題。rulebook の完全性に関わるものを含みます

​

代わりに公開 Issue で報告するもの

次の問題は、通常の GitHub Issue で報告してください。

• 破壊的コマンドの実行を許してしまう迂回や fail open。未対応のコマンド（ルールがまだブロックしないもの）、パーサー・トークナイザー・ラッパー解析のエッジケース、ブロックせずにコマンドを通してしまう解析エラーを含みます。そのまま貼り付けて悪用できるプロンプトインジェクションの攻撃コードではなく、コマンドの形式を報告してください
• 安全なコマンドがブロックされる誤検知
• 不足している利便性向上のルールや、新機能の要望
• ドキュメントの誤り
• セキュリティ影響のないインストールの問題
• カスタムルールや設定についての質問

Grok Build の hook は設計上 fail open であり、ホスト側に failClosed に相当する設定はありません。ツール呼び出しをブロックできるのは、標準出力に明示的な deny を返した場合だけです。hook がクラッシュした場合、タイムアウトした場合、不正な出力を返した場合は、その呼び出しはそのまま実行されます。アダプター自身が fail closed とするケース（ツール入力の切り詰めや、作業ディレクトリを利用できない場合）には、それでも明示的に deny を出力します。このホストでは、アダプターが出力を一切返せなくなる失敗が起きた場合、その呼び出しをブロックできません。これはホスト側の挙動であり、未対応には当たりません。

​

報告後の流れ

通常、最初の返信は 7 日以内に届きます。メンテナーは報告者と連携し、影響と対象バージョンを確認して、修正と開示を準備します。詳細を公開する前に、調査に必要な時間を確保してください。 脆弱性が確認された場合、メンテナーはできるだけ早く修正を公開します。報告者が匿名を希望しない限り、クレジットを記載した GitHub security advisory やリリースノートを公開することがあります。修正版が公開されるまでは、エクスプロイトの詳細を開示しないでください。