Claude How-To

日本語

English
Tiếng Việt
中文
Українська

日本語

English
Tiếng Việt
中文
Українська

Appearance

セキュリティポリシー ​

概要 ​

Claude How To プロジェクトのセキュリティを私たちは重視している。このドキュメントは、私たちのセキュリティ慣行と、脆弱性を責任を持って報告する方法を定める。

サポート対象バージョン ​

以下のバージョンに対してセキュリティ更新を提供する：

バージョンステータスサポート期限
Latest（main）✅ アクティブ現在 + 6 か月
1.x リリース✅ アクティブ次のメジャーバージョンまで

注： 教育用ガイドプロジェクトとして、私たちは従来のバージョンサポートよりも、現在のベストプラクティスとドキュメントセキュリティの維持に重点を置いている。更新は main ブランチに直接適用される。

セキュリティ慣行 ​

コードセキュリティ ​

  1. 依存関係の管理

    • すべての Python 依存関係は requirements.txt で固定される
    • Dependabot と手動レビューによる定期更新
    • すべてのコミットで Bandit によるセキュリティスキャン
    • セキュリティチェック用の pre-commit フック

  2. コード品質

    • Ruff によるリンティングが一般的な問題を捕捉
    • mypy による型チェックで型関連の脆弱性を防止
    • pre-commit フックが標準を強制
    • すべての変更はマージ前にレビューされる

  3. アクセス制御

    • main ブランチでのブランチ保護
    • マージ前に必須レビュー
    • マージ前に状態チェックの通過が必須
    • リポジトリへの書き込み権限を制限

ドキュメントセキュリティ ​

  1. サンプルにシークレットを含めない

    • サンプル中の API キーはすべてプレースホルダ
    • 認証情報はハードコードしない
    • .env.example ファイルで必要な変数を示す
    • シークレット管理に関する明確な警告

  2. セキュリティのベストプラクティス

    • サンプルは安全なパターンを示す
    • ドキュメントでセキュリティ警告を強調する
    • 公式セキュリティガイドへのリンク
    • 関連セクションで認証情報の扱いを議論する

  3. コンテンツレビュー

    • すべてのドキュメントをセキュリティ問題についてレビュー
    • コントリビューションガイドラインにセキュリティ考慮事項を含める
    • 外部リンクと参照の検証

依存関係セキュリティ ​

  1. スキャン

    • Bandit がすべての Python コードを脆弱性についてスキャン
    • GitHub セキュリティアラートによる依存関係の脆弱性チェック
    • 定期的な手動セキュリティ監査

  2. 更新

    • セキュリティパッチを迅速に適用
    • メジャーバージョンを慎重に評価
    • 変更履歴にセキュリティ関連更新を含める

  3. 透明性

    • セキュリティ更新をコミットに記録
    • 脆弱性開示を責任を持って扱う
    • 適切な場合に公開セキュリティ勧告を発行

脆弱性の報告 ​

私たちが対象とするセキュリティ問題 ​

以下の報告を歓迎する：

  • スクリプトやサンプルの コード脆弱性
  • Python パッケージの 依存関係の脆弱性
  • いずれのコード例にも含まれる 暗号関連の問題
  • ドキュメント中の 認証／認可の欠陥
  • 設定例における データ露出のリスク
  • インジェクション脆弱性（SQL、コマンド等）
  • SSRF／XXE／パストラバーサル の問題

対象外のセキュリティ問題 ​

以下はこのプロジェクトの対象外である：

  • Claude Code 自体の脆弱性（Anthropic に報告すること）
  • 外部サービスやライブラリの問題（上流に報告すること）
  • ソーシャルエンジニアリングやユーザー教育（このガイドの範囲外）
  • 概念実証のない理論的脆弱性
  • 公式チャネルで報告された依存関係の脆弱性

報告の方法 ​

プライベート報告（推奨） ​

機微なセキュリティ問題には、GitHub のプライベート脆弱性報告を使ってほしい：

  1. 訪問先：https://github.com/luongnv89/claude-howto/security/advisories
  2. "Report a vulnerability" をクリック
  3. 脆弱性の詳細を記入
  4. 以下を含める：
    • 脆弱性の明確な説明
    • 影響を受けるコンポーネント（ファイル、セクション、サンプル）
    • 潜在的な影響
    • 再現手順（該当する場合）
    • 推奨される修正案（あれば）

その後の流れ：

  • 48 時間以内に受領を確認する
  • 調査し、深刻度を評価する
  • 修正策の開発に協力する
  • 開示のタイムラインを調整する
  • セキュリティ勧告であなたにクレジットを与える（匿名希望でない限り）

公開報告 ​

機微でない問題、またはすでに公開されている問題については：

  1. GitHub Issue を作成 し security ラベルを付ける
  2. 以下を含める：
    • タイトル：[SECURITY] に続けて簡潔な説明
    • 詳細な説明
    • 影響を受けるファイルまたはセクション
    • 潜在的な影響
    • 推奨される修正案

脆弱性対応プロセス ​

評価（24 時間） ​

  1. 報告の受領を確認する
  2. CVSS v3.1 を使って深刻度を評価する
  3. 対象範囲内かどうかを判定する
  4. 初期評価を報告者に連絡する

開発（1〜7 日） ​

  1. 修正を開発する
  2. 修正をレビュー・テストする
  3. セキュリティ勧告を作成する
  4. リリースノートを準備する

開示（深刻度による） ​

Critical（CVSS 9.0〜10.0）

  • 修正を即座にリリース
  • 公開勧告を発行
  • 報告者に 24 時間前通知

High（CVSS 7.0〜8.9）

  • 48〜72 時間以内に修正をリリース
  • 報告者に 5 日前通知
  • リリースと同時に公開勧告

Medium（CVSS 4.0〜6.9）

  • 次の定期更新で修正をリリース
  • リリースと同時に公開勧告

Low（CVSS 0.1〜3.9）

  • 次の定期更新に修正を含める
  • リリースと同時に勧告

公表 ​

私たちは以下を含むセキュリティ勧告を公表する：

  • 脆弱性の説明
  • 影響を受けるコンポーネント
  • 深刻度評価（CVSS スコア）
  • 修正バージョン
  • 回避策（該当する場合）
  • 報告者へのクレジット（同意がある場合）

報告者のためのベストプラクティス ​

報告前 ​

  • 問題を確認： 一貫して再現できるか？
  • 既存の Issue を検索： すでに報告されていないか？
  • ドキュメントを確認： 安全な使い方のガイダンスはあるか？
  • 修正をテスト： 推奨する修正は機能するか？

報告時 ​

  • 具体的に： 正確なファイルパスと行番号を提供する
  • コンテキストを含める： なぜこれがセキュリティ問題なのか？
  • 影響を示す： 攻撃者が何をできるか？
  • 手順を提供： どうすれば再現できるか？
  • 修正案を出す： どう修正するか？

報告後 ​

  • 辛抱強く： 私たちのリソースは限られている
  • 応答する： フォローアップ質問に迅速に答える
  • 機密を保つ： 修正前に公開しない
  • 調整を尊重： 開示のタイムラインに従う

セキュリティヘッダと設定 ​

リポジトリのセキュリティ ​

  • ブランチ保護： main ブランチへの変更には 2 名の承認が必要
  • 状態チェック： すべての CI/CD チェックの通過が必須
  • CODEOWNERS： 主要ファイルには指定レビュアー
  • 署名付きコミット： コントリビュータに推奨

開発時のセキュリティ ​

bash
# pre-commit フックをインストール
pre-commit install

# ローカルでセキュリティスキャンを実行
bandit -c pyproject.toml -r scripts/
mypy scripts/ --ignore-missing-imports
ruff check scripts/

依存関係のセキュリティ ​

bash
# 既知の脆弱性をチェック
pip install safety
safety check

# あるいは pip-audit を使う
pip install pip-audit
pip-audit

コントリビュータ向けセキュリティガイドライン ​

サンプルを書くとき ​

  1. シークレットをハードコードしない

    python
    # ❌ 悪い例
api_key = "sk-1234567890"

# ✅ よい例
api_key = os.getenv("API_KEY")

  2. セキュリティへの影響を警告する

    markdown
    ⚠️ **セキュリティに関する注意**：`.env` ファイルは絶対に git に
コミットしない。すぐに `.gitignore` に追加すること。

  3. 安全なデフォルトを使う

    • 認証をデフォルトで有効化する
    • 該当する場合は HTTPS を使う
    • 入力を検証・サニタイズする
    • パラメータ化クエリを使う

  4. セキュリティ考慮事項をドキュメント化する

    • なぜセキュリティが重要かを説明する
    • 安全なパターンと安全でないパターンを示す
    • 信頼できる出典にリンクする
    • 警告を目立つように記載する

コントリビューションをレビューするとき ​

  1. 公開されたシークレットをチェック

    • 一般的なパターンをスキャン（api_key=、password= など）
    • 設定ファイルをレビュー
    • 環境変数を確認

  2. 安全なコーディング慣行を確認

    • 認証情報のハードコードがないか
    • 入力検証が適切か
    • 認証／認可が安全か
    • ファイル処理が安全か

  3. セキュリティへの影響をテスト

    • 悪用される可能性はあるか？
    • 最悪のケースは？
    • エッジケースはあるか？

セキュリティリソース ​

公式標準 ​

Python セキュリティ ​

依存関係管理 ​

一般的なセキュリティ ​

セキュリティ勧告アーカイブ ​

過去のセキュリティ勧告は GitHub Security Advisories タブで確認できる。

連絡先 ​

セキュリティに関する質問やセキュリティ慣行の議論：

  1. プライベートセキュリティ報告： GitHub のプライベート脆弱性報告を使う
  2. 一般的なセキュリティの質問： [SECURITY] タグでディスカッションを開く
  3. セキュリティポリシーへのフィードバック： security ラベルで Issue を作成

謝辞 ​

このプロジェクトを安全に保つために協力してくださるセキュリティ研究者とコミュニティメンバーに感謝する。脆弱性を責任を持って報告したコントリビュータは、セキュリティ勧告で謝意を示す（匿名希望でない限り）。

ポリシーの更新 ​

このセキュリティポリシーは以下のときにレビュー・更新される：

  • 新たな脆弱性が発見されたとき
  • セキュリティのベストプラクティスが進化したとき
  • プロジェクトの範囲が変わったとき
  • 最低でも年 1 回

Last Updated: January 2026 Next Review: January 2027

Claude How To を安全に保つためのご協力ありがとうございます！🔒