Skip to main content
セキュリティ修正は、cc-safety-net最新の公開 releaseに提供されます。古い version を使用している場合は、その脆弱性が最新 release にも影響しない限り、問題を報告する前に更新してください。 このページでは、問題の報告方法を説明します。trust boundary、fail-closed の強制、attack surface については、セキュリティモデルを参照してください。正式なポリシーは、ソースリポジトリの SECURITY.md です。 ブロックされなかったコマンドは、公開 bug です。CC Safety Net 自体による有害な動作は、非公開の脆弱性です。どちらの報告か不明な場合は、公開または非公開の報告を選ぶを読んでください。動作の診断が必要な場合は、トラブルシューティングから始めてください。

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

セキュリティ脆弱性を公開 GitHub issue で報告しないでください。 利用可能な場合は、そのリポジトリの GitHub private vulnerability reporting を使用してください。利用できない場合は、maintainer の jliew@420024lab.com に email を送ってください。 安全に共有できる場合は、次の情報を含めてください。
  • 影響を受ける cc-safety-net version
  • OS と runtime の version
  • 影響を受ける連携(例:Claude Code、OpenCode、Gemini CLI、GitHub Copilot CLI、Codex)
  • 再現手順、および CC Safety Net を迂回、弱体化、または悪用するコマンドや入力
  • cc-safety-net explain または cc-safety-net doctor の関連出力
  • 問題がデータ損失、コマンド実行、シークレット露出、またはその他の具体的なセキュリティ影響を引き起こす可能性があるか
log やコマンド出力を送る前に、token、資格情報、非公開リポジトリ名、機密ファイルパスを削除してください。
explaindoctor の出力は、添付しても自動的に安全になるわけではありません。redaction は、認識された資格情報の形式だけを対象にします。入力したコマンドテキスト、解析済み token、ホームディレクトリを含む absolute path、hostname、設定パスは出力に残ります。placeholder の資格情報を使って問題を再現し、送信前に出力を読んでください。

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

CC Safety Net の役割は、選択した安全レベルの文書化された保証の範囲内で、エージェントによる破壊的なコマンドの実行を防止することです。ツールがこの役割を果たせなかったという報告は bug であり、公開 GitHub issue に属します。strict と paranoid の threat model では、攻撃者(prompt injection、敵対的 context)が任意の破壊的コマンドを出力できると想定しています。そのため、「この形式のコマンドは検出されない」と公開しても、攻撃者がまだ持っていない能力を渡すことにはなりません。公開すると、gap をより速く修正でき、利用者は即時の workaround として custom rule を提供できます。 ツールが実行するはずのない有害な動作をしたという報告は、脆弱性です。例として、シークレットの漏えい、自身のディレクトリ外へのファイル書き込み、改ざんされた package の配布があります。明らかでない構成そのものがシークレットであるため、非公開で開示してください。 境界となる質問は次です。ツールが破壊的なコマンドを止められなかったのか、それともツール自体が有害な vector になったのか。

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

次の問題は非公開で報告してください。
  • block message、audit log、diagnostic、debug output、false-positive report の prefill を通じたシークレット漏えい。特定の token 形式の redaction bypass、または report preview が置換済みと表示したパスの漏えいを含みます
  • audit logging または設定処理における path traversal またはファイルシステムの問題。細工された入力によって、意図したディレクトリ外に書き込む場合
  • 公開 npm package またはプラグイン配布に影響する supply-chain または packaging の問題。rulebook integrity を含みます

代わりに公開 issue に属するもの

次の問題には通常の GitHub issue を使用してください。
  • 破壊的コマンドの実行を許す任意の bypass または fail-open。coverage gap(ルールがまだブロックしないコマンド)、parser、tokenizer、wrapper analysis の edge case、またはブロックせずにコマンドを通す analysis error を含みます。すぐ貼り付けて使える weaponized prompt-injection payload ではなく、コマンドの形式を報告してください
  • 安全なコマンドがブロックされる false positive
  • 不足している convenience rule または新しい feature request
  • ドキュメントの bug
  • セキュリティ影響がないインストール問題
  • custom rule または設定についての質問
破壊的コマンドの coverage gap は、重大に見える場合も公開のままです。脆弱性に再分類されません。非公開の経路は、上記の分類のために確保します。standard mode の文書化された緩和で許可されるコマンドは gap ではありません。standard は best-effort であり、strict または paranoid がこれらの形式を fail closed にするレベルです。

報告後の流れ

7 日以内に最初の応答を受け取る予定です。maintainer は、影響の確認、影響する version の特定、修正の準備、開示の調整を報告者と共に進めます。詳細を公開する前に、maintainer に合理的な調査期間を与えてください。 脆弱性が確認された場合、maintainer は実用上できるだけ早く修正を公開します。また、希望しない場合を除き、適切な credit を付けた GitHub security advisory または release note を公開できます。修正版が利用可能になるまで、exploit の詳細を開示しないでください。
最終更新日 2026年8月12日