security-best-practices

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

概要

このスキルでは、現在のコンテキストで使用されている言語とフレームワークを特定し、その言語やフレームワークに関するセキュリティのベストプラクティスを、このスキルの references ディレクトリから読み込む方法について説明します。

該当する情報があれば、デフォルトでセキュアな新しいコードの作成や、既存のコードにある重大な問題の受動的な検出に利用できます。また、ユーザーから求められた場合は、脆弱性レポートを作成し、修正案を提示できます。

ワークフロー

このスキルの最初の手順では、作業対象のプロジェクトの範囲内で、使用するよう求められている、またはすでに存在するすべての言語とすべてのフレームワークを特定します。主要なコアフレームワークに注目してください。多くの場合、フロントエンドとバックエンドの両方の言語およびフレームワークを特定します。

次に、このスキルの references ディレクトリを確認し、その言語やフレームワークに関連するドキュメントがあるか調べます。特定のフレームワークまたは言語に関連する参照ファイルは、すべて必ず読んでください。ファイル名の形式は <language>-<framework>-<stack>-security.md です。また、使用するフレームワークに依存しない <language>-general-<stack>-security.md があるかどうかも確認してください。

フロントエンドとバックエンドを含むウェブアプリケーションを扱う場合は、フロントエンドとバックエンドの両方について、参照ドキュメントを確認してください。

フロントエンドとバックエンドの両方を含むウェブアプリの作成を依頼され、フロントエンドのフレームワークが指定されていない場合は、javascript-general-web-frontend-security.md も確認してください。フロントエンドとバックエンドの両方をセキュアにする方法を理解することが重要です。

このスキルの references ディレクトリに関連情報がない場合は、その言語やフレームワークについて知っていることと、広く知られているすべてのセキュリティのベストプラクティスを考慮してください。不確かな場合は、セキュリティのベストプラクティスに関するドキュメントをオンラインで検索できます。

その後、いくつかの方法で運用できます。

1. 主なモードは、その情報を使って、以降のコードをデフォルトでセキュアに作成することです。新しいプロジェクトを始める場合や、新しいコードを書く場合に役立ちます。

2. 2つ目のモードは、プロジェクトで作業し、ユーザー向けのコードを書いている間に、脆弱性を受動的に検出することです。セキュリティガイダンスに反する重大または非常に重要な脆弱性や大きな問題にフラグを立て、ユーザーに知らせることができます。この受動的なモードでは、影響が最も大きい脆弱性とセキュアなデフォルトに注目してください。

3. ユーザーからセキュリティレポートの作成や、コードベースのセキュリティ向上を求められることがあります。この場合は、プロジェクトがセキュリティのベストプラクティスに関するガイダンスにどのように従っていないかを詳しく説明する、完全なレポートを作成してください。レポートでは優先順位を付け、重大度と緊急度のセクションを明確にしてください。その後、これらの問題の修正に着手することを提案してください。詳しくは、以下の #fixes を参照してください。

ワークフローの判断ツリー

• 言語やフレームワークが不明な場合は、リポジトリを調べて特定し、根拠を列挙してください。
• references/ に該当するガイダンスがある場合は、関連するファイルのみを読み込み、その指示に従ってください。
• 該当するガイダンスがない場合は、選択した言語やフレームワークで広く知られているセキュリティのベストプラクティスを把握しているか検討してください。レポートの作成を求められた場合は、具体的なガイダンスがないことをユーザーに伝えてください（それでもレポートを作成したり、確実な重大な脆弱性を検出したりできます）。

サプライチェーンと依存関係のセキュリティ

現代のアプリケーションは、サードパーティ製パッケージに大きく依存しています。必ず次の点を評価してください。

1. 依存関係の監査：

   # Node.js
   npm audit
   npx better-npm-audit audit --level moderate
   
   # Python
   pip-audit
   safety check
   
   # Go
   govulncheck ./...
   

2. ロックファイルの整合性：package-lock.json、yarn.lock、poetry.lock、または go.sum がコミットされており、再現可能であることを確認してください。

3. タイポスクワッティング：人気のあるパッケージと名前が非常によく似たパッケージがないか確認してください（例：lodash に対する lodahs）。

4. CI でのバージョン固定：CI/CD では範囲指定ではなく、正確なバージョンまたはダイジェストを使用してください。

5. SBOM の生成：本番環境で使用するアプリケーションでは、ソフトウェア部品表の生成を推奨します。

   # Node.js
   npx @cyclonedx/cyclonedx-npm --output-file sbom.json
   
   # Python
   cyclonedx-py environment -o sbom.json
   

シークレット管理

コード内のシークレットは、重大かつ頻繁に見つかる問題です。次の点を確認してください。

• ハードコードされた API キー、トークン、パスワード、接続文字列
• Git にコミットされた .env ファイル（.gitignore を確認してください）
• ログに記録される環境変数内のシークレット
• Docker のビルド引数内のシークレット（イメージの履歴から確認できます）

検出ツール：

# Gitleaks — scan git history for secrets
gitleaks detect --source . --verbose

# TruffleHog — scan git history
trufflehog git file://. --since-commit HEAD~20

# Detect-secrets
detect-secrets scan --all-files

推奨されるパターン：

• シークレットマネージャー（AWS Secrets Manager、HashiCorp Vault、GCP Secret Manager、Azure Key Vault）を使用してください
• シークレットが漏えいした場合は、直ちにローテーションしてください。Git から削除するだけでは不十分です（履歴には残っています）
• git filter-repo を使用して、漏えいしたシークレットを履歴から除去してください

例外

ここに記載されたガイドラインは、言語やフレームワークに関するセキュリティのベストプラクティスを示していますが、顧客によっては、これらの慣行を回避または上書きする必要がある場合があります。プロジェクトのドキュメントやプロンプトファイルにある具体的なルールや指示を確認してください。特定のベストプラクティスを上書きする必要がある場合があります。ベストプラクティスを上書きする場合、その旨をユーザーに伝えてもかまいませんが、ユーザーと争わないでください。プロジェクト固有の理由でセキュリティのベストプラクティスを回避または無視する必要がある場合は、その理由を明確にし、今後もその例外に従えるよう、プロジェクトにドキュメントを追加することを提案してもかまいません。

レポート形式

レポートを作成する場合は、ユーザーから別の保存場所を指定されていなければ、security_best_practices_report.md に Markdown ファイルとして記述してください。レポートの保存場所をユーザーに尋ねてもかまいません。

レポートの冒頭には、短いエグゼクティブサマリーを記載してください。

レポートは脆弱性の重大度に基づいて複数のセクションに明確に分けてください。ユーザーへの影響が最も大きいため、最も重大な問題を中心に報告してください。参照しやすいように、すべての指摘事項に数値 ID を付けてください。

重大な指摘事項には、影響を一文で記載してください。

レポートを書き終えたら、簡潔な内容でもかまいませんので、ユーザーにも直接報告してください。ユーザーが指摘事項について詳しい情報を希望する場合は、その内容やセキュリティのベストプラクティスに関するガイダンスの理由を説明することを提案してもかまいません。

重要：レポートでコードに言及する際は、該当するコードの行番号を確認して記載してください。

レポートファイルを書き終えたら、指摘事項をユーザーに要約してください。

また、最終レポートの保存場所もユーザーに伝えてください。

修正

レポートを作成した場合は、ユーザーがレポートを読めるようにし、修正の開始を希望するか尋ねてください。

重大な問題を受動的に発見した場合は、ユーザーに知らせ、その問題の修正を希望するか尋ねてください。

修正を行う際は、一度に1つの問題に集中してください。新しいコードが特定のセキュリティのベストプラクティスに基づいていることを説明する、簡潔で分かりやすいコメントを付けてください。また、そうしないことが危険な理由も、ごく短く添えるとよいでしょう。

変更によってユーザーのコードの機能に影響が出ないか、常に検討してください。プロジェクトの現在の動作に後退をもたらす可能性がないか考慮してください。安全でないコードがほかの理由で利用されていることはよくあります（それが安全でないコードが長く残る理由です）。ユーザーが今後セキュリティ修正を適用したくなくなる可能性があるため、ユーザーのプロジェクトを壊さないようにしてください。急ごしらえの変更ではなく、プロジェクト全体をよく理解したうえで、十分に検討した修正を行うほうが適切です。

ユーザーが設定している通常の変更やコミットの手順には、必ず従ってください。Git コミットを作成する場合は、セキュリティのベストプラクティスに準拠するための変更であることを明確に示すコミットメッセージを付けてください。関連性のない複数の問題を、1つのコミットにまとめないようにしてください。

ユーザーが設定している通常のテスト手順があれば、必ず従い、変更によって後退が生じていないことを確認してください。変更がもたらす二次的な影響も考慮し、影響がある場合は変更を行う前にユーザーに伝えてください。

一般的なセキュリティに関するアドバイス

以下は、ほぼすべての言語やフレームワークに当てはまる、安全なコーディングに関するアドバイスです。

リソースの公開 ID に連番 ID を使用しない

リソースに割り当てた ID をインターネットに公開する場合、小さな自動採番 ID は使用しないでください。代わりに、より長いランダムな UUID4 またはランダムな 16 進文字列を使用してください。これにより、ユーザーがリソースの数を推測したり、リソース ID を推測したりするのを防げます。

TLS に関する注意

TLS は本番環境へのデプロイにおいて重要ですが、開発作業のほとんどは TLS が無効になっているか、対象範囲外の TLS プロキシによって提供される環境で行われます。このため、TLS がないことをセキュリティ上の問題として報告しないよう十分注意してください。また、「セキュア」Cookie の使用にも十分注意してください。アプリケーションが実際に TLS 経由で動作する場合にのみ設定してください。ローカル開発環境やテスト環境へのデプロイなど、TLS を使用しないアプリケーションで設定すると、アプリケーションが動作しなくなります。環境変数などのフラグを用意して設定を上書きできるようにし、TLS を使用する本番環境へのデプロイまでは無効にしておくこともできます。さらに、HSTS の推奨は避けてください。長期的な影響を十分に理解せずに使用すると危険であり（大規模な停止やユーザーのロックアウトを引き起こす可能性があります）、codex がレビューするプロジェクトの範囲では一般に推奨されません。

よくある落とし穴

このセクションでは、セキュリティのベストプラクティスを適用する際に起こりうる、既知の失敗パターンやエッジケースを説明します。

1. エージェントがコンテキストを把握していないことによる脆弱性

落とし穴： エージェントが、ユーザーのプロジェクト固有の制約、脅威モデル、デプロイ環境を理解せず、セキュリティのベストプラクティスはあらゆるコードコンテキストに一律に適用されると思い込んでしまいます。

現れ方：

• ユーザーが文書化した要件と矛盾する厳格なセキュリティ制御を推奨する
• ユーザーが外部の制御（ネットワーク分離、リバースプロキシの強化など）ですでに対処しているセキュリティ対策を、脆弱性として指摘する
• すべてのプロジェクトを同じセキュリティ上の緊急度で扱う（すべてのシステムに同じ脅威モデルが必要なわけではありません）

緩和策：

• セキュリティレポートを作成する場合や修正を準備する場合は、推奨事項を提示する前に、プロジェクトの脅威モデル、デプロイ環境、既存のセキュリティ制御について確認してください
• ユーザーが提供したセキュリティ関連ドキュメント、アーキテクチャ上の決定事項、脅威分析を確認してください
• 修正を適用する場合は、プロジェクト固有の要件や既存の緩和策を損なわないことを確認してください
• ベストプラクティスを適用しない理由が文書化されている場合は、ユーザーがそれを選択できるようにしてください（その理由をプロジェクトに追記するよう提案してください）

2. ローカル開発環境における TLS／HTTPS の誤検知

落とし穴： TLS がまだ導入されていないローカル開発、テスト、CI 環境で、HTTPS や TLS の欠如をセキュリティ脆弱性として指摘してしまいます。

現れ方：

• localhost の開発サーバーに HTTPS／TLS の適用を推奨する
• 不要な自己署名証明書の設定を提案する
• TLS が対象範囲外のリバースプロキシやインフラストラクチャ層で処理されていることを考慮しない
• 開発環境と本番環境のデプロイを区別できない

緩和策：

• 必ずデプロイ環境を確認してください。開発、テスト、ステージング、本番のどれですか？
• 開発作業の多くでは、TLS が無効になっているか、外部プロキシによって提供されているものと想定してください
• 本番環境へのデプロイであることが明確でない限り、TLS の欠如をセキュリティ問題として報告しないでください
• 本番環境でのみ TLS 固有の保護を有効にする環境フラグの提供を検討してください

関連するガイダンスについては、上記の TLS に関する注意事項 も参照してください

3. 「セキュア」Cookie フラグの過剰適用

落とし穴： TLS を使わない接続（localhost、HTTP のみの開発サーバー）でアプリケーションを実行すると動作しなくなる Cookie フラグ Secure、HttpOnly、SameSite の設定を、開発環境で推奨してしまいます。

現れ方：

• 開発サーバーが HTTP を使用しているのに Secure が設定されているため、Cookie が通知なく破棄される
• ローカルテストでアプリケーションのログインが原因不明のまま失敗する
• 認証 Cookie がないためテストが失敗する
• コード上は「修正」されたように見える一方で、開発環境での利用体験が損なわれる

緩和策：

• セキュア Cookie フラグを推奨する前に、必ず現在のデプロイ環境を確認してください
• 環境に応じた設定を提案してください。Secure は本番環境でのみ設定し、開発環境では設定しないようにします
• 修正内容には、このパターンを明確に記載してください（例：secure: process.env.NODE_ENV === 'production'）
• 変更を適用した後、Cookie に依存するフロー（ログイン、セッション管理）をテストしてください
• この変更を行う前にユーザーに警告してください：「この変更により、TLS を使わない環境では Cookie の処理が機能しなくなります」

関連するガイダンスについては、上記の TLS に関する注意事項 も参照してください

4. ベストプラクティスを無視するタイミングに関する指針の不足

落とし穴： 正当な理由で逸脱、上書き、または延期する場合があることを認めず、すべてのセキュリティのベストプラクティスを絶対的なルールとして扱うことです。

現れ方：

• 時間をかけて段階的に導入できるプラクティスに対して、破壊的変更を推奨する
• 技術的負債とのトレードオフを認めず、回避策を脆弱性として指摘する
• 安全でないパターンを段階的に廃止する方法を提案しない
• アーキテクチャ上の判断を、単純なベストプラクティス違反として扱う

緩和策：

• ベストプラクティスが他の要件（パフォーマンス、互換性、スケジュール）と競合する場合は、その点を認める
• 段階的な対応策を提案する：「懸念があります。今すぐ対処する［選択肢A］、［緩和策B］を講じて延期する、または［文書化したうえで］リスクを受け入れることができます」
• 「今すぐ修正する」という理想的な方法でなくても、必ず前に進むための道筋を示す
• 後で見直せるよう、逸脱する理由を記録する
• ユーザーの明示的な同意なしに、機能やユーザー体験を損なう「セキュアな」修正を決して強制しない

5. コンテキストを考慮しない受動的な検出

落とし穴： ユーザーが積極的なセキュリティ監視を望んでいるのか、機能の提供に集中しているのかを把握せず、エージェントの作業中にセキュリティ上の懸念を受動的に指摘することです。

現れ方：

• ユーザーが認識しているパターンについてセキュリティ警告を出し、機能の実装を中断する
• 変更できない継承コード（レガシーシステム、サードパーティーの依存関係）を脆弱性として指摘する
• すべてのコードを本番環境向けとして扱い、迅速なプロトタイピングや概念実証を妨げる

緩和策：

• 重大または非常に深刻な影響度の脆弱性のみを受動的に指摘する
• コンテキストを確認する：これはプロトタイプ、レガシーシステム、それとも本番環境向けのコードですか？
• 軽微なベストプラクティスからの逸脱ではなく、最も影響の大きい脆弱性に焦点を当てる
• 指摘する場合は、その理由と、すぐに修正する必要があるかどうかを説明することを申し出る
• ユーザーの優先事項を尊重する：セキュリティとのトレードオフには、正当な理由がある場合があります