mirror of https://github.com/luongnv89/claude-howto.git synced 2026-08-30 12:30:36 +02:00

Files

T

Luong NGUYEN 28149a85fc docs: sync to Claude Code v2.1.245 (#177 )

* docs: sync to Claude Code v2.1.245

Sync the tutorial, its four translations, and both learner-facing skills
against Claude Code v2.1.245 (was anchored at v2.1.235).

The graded material turned out to be staler than the tutorials it grades.
The lesson READMEs already said "31 hook events", "six rewind options" and
"six permission modes"; the quiz and self-assessment still said 25, 5 and 5,
so learners were scored against a wrong answer and then sent to a lesson
that contradicted it. Seven such claims are fixed here.

Two long-standing doc defects were also verified against official docs:

- Hook default timeout was documented as 60 seconds. It is 600 for
  command/http/mcp_tool (30 for prompt, 60 for agent), with per-event
  overrides. Wrong in five places.
- Skill precedence was documented as enterprise > project > personal. The
  official order is enterprise > personal > project. question-bank.md
  Lesson 03 Q9 already graded the correct order, so the lesson had been
  contradicting its own quiz.

Fixed
- Hook default timeout 60s -> 600s, with per-event overrides
- Skill precedence: project and personal were swapped
- Memory "overrides root CLAUDE.md" -> concatenation model (last holdouts
  after the quiz was aligned in #164)
- permissionMode frontmatter omitted `auto` (English + vi/ja/uk); the quiz
  was right and the docs were wrong
- Built-in subagent `Bash` no longer exists upstream -> renamed to `claude`
- `/undo` is absent from the official commands reference -> marked deprecated
- `backgroundTasks` settings block was fabricated -> replaced with
  CLAUDE_CODE_DISABLE_BACKGROUND_TASKS and the concurrency env var
- Plugin manifest field is `lspServers`, not inline `lsp`
- vi/05-mcp documented `claude mcp add --transport ws`, which upstream
  explicitly does not support
- Self-assessment could never reach its own maximum score: rounds cap at
  4+4+4+3+4 = 19, not 20
- 13 dangling quiz `Review:` pointers, two of which named another lesson
- Skill description cap: 1024 chars -> 1,536 combined with `when_to_use`

Added
- WebSocket (`ws`) MCP transport, undocumented until now
- Concise output style (v2.1.237), a fifth built-in
- modelPicker, promptCacheTtl, subagentPromptCacheTtl, modelPricing,
  keybindingFlavor settings
- ANTHROPIC_DEFAULT_MODEL env var
- Hook `async`, `asyncRewake`, `shell`, `statusMessage`, `retry` keys;
  `agent` type marked experimental
- /design canvas, Remote Control out of research preview, notify_when_idle,
  plugin manifest fields (workflows, channels, dependencies, outputStyles)

Deferred deliberately: the reserved `synced` skills folder, and a bulk
footer stamp across the translations. zh/ carries none of the P0 claims
(it is abridged upstream of this run), so it has no P0 sub-tasks rather
than fabricated English.

Mermaid validation did not run in this environment (mmdc absent); CI covers it.

* fix(docs): propagate v2.1.245 corrections to CATALOG, translations, and stale enumerations

* fix(docs): propagate built-in subagent rename to uk/vi/zh CATALOG and zh lesson

2026-08-26 07:20:04 +02:00

12 KiB

Raw Blame History

セキュリティポリシー

概要

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

サポート対象バージョン

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

バージョン	ステータス	サポート期限
Latest（main）	✅ アクティブ	現在 + 6 か月

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

セキュリティ慣行

コードセキュリティ

依存関係の管理
- すべての Python 依存関係は requirements.txt で固定される
- Dependabot と手動レビューによる定期更新
- すべてのコミットで Bandit によるセキュリティスキャン
- セキュリティチェック用の pre-commit フック
コード品質
- Ruff によるリンティングが一般的な問題を捕捉
- mypy による型チェックで型関連の脆弱性を防止
- pre-commit フックが標準を強制
- すべての変更はマージ前にレビューされる
アクセス制御
- main ブランチでのブランチ保護
- マージ前に必須レビュー
- マージ前に状態チェックの通過が必須
- リポジトリへの書き込み権限を制限

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

サンプルにシークレットを含めない
- サンプル中の API キーはすべてプレースホルダ
- 認証情報はハードコードしない
- .env.example ファイルで必要な変数を示す
- シークレット管理に関する明確な警告
セキュリティのベストプラクティス
- サンプルは安全なパターンを示す
- ドキュメントでセキュリティ警告を強調する
- 公式セキュリティガイドへのリンク
- 関連セクションで認証情報の扱いを議論する
コンテンツレビュー
- すべてのドキュメントをセキュリティ問題についてレビュー
- コントリビューションガイドラインにセキュリティ考慮事項を含める
- 外部リンクと参照の検証

依存関係セキュリティ

スキャン
- Bandit がすべての Python コードを脆弱性についてスキャン
- GitHub セキュリティアラートによる依存関係の脆弱性チェック
- 定期的な手動セキュリティ監査
更新
- セキュリティパッチを迅速に適用
- メジャーバージョンを慎重に評価
- 変更履歴にセキュリティ関連更新を含める
透明性
- セキュリティ更新をコミットに記録
- 脆弱性開示を責任を持って扱う
- 適切な場合に公開セキュリティ勧告を発行

脆弱性の報告

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

以下の報告を歓迎する：

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

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

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

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

報告の方法

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

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

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

その後の流れ：

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

公開報告

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

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

脆弱性対応プロセス

評価（24 時間）

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

開発（1〜7 日）

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

開示（深刻度による）

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： 主要ファイルには指定レビュアー
署名付きコミット： コントリビュータに推奨

開発時のセキュリティ

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

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

依存関係のセキュリティ

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

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

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

サンプルを書くとき

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

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

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

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

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

安全なデフォルトを使う
- 認証をデフォルトで有効化する
- 該当する場合は HTTPS を使う
- 入力を検証・サニタイズする
- パラメータ化クエリを使う
セキュリティ考慮事項をドキュメント化する
- なぜセキュリティが重要かを説明する
- 安全なパターンと安全でないパターンを示す
- 信頼できる出典にリンクする
- 警告を目立つように記載する

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

公開されたシークレットをチェック
- 一般的なパターンをスキャン（api_key=、password= など）
- 設定ファイルをレビュー
- 環境変数を確認
安全なコーディング慣行を確認
- 認証情報のハードコードがないか
- 入力検証が適切か
- 認証／認可が安全か
- ファイル処理が安全か
セキュリティへの影響をテスト
- 悪用される可能性はあるか？
- 最悪のケースは？
- エッジケースはあるか？

セキュリティリソース

公式標準

Python セキュリティ

依存関係管理

一般的なセキュリティ

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

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

連絡先

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

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

謝辞

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

ポリシーの更新

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

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

最終更新：2026 年 8 月 25 日 Claude Code バージョン：2.1.245 情報源：

https://code.claude.com/docs/en/overview Next Review: January 2027

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

12 KiB Raw Blame History Unescape Escape