security-best-practices

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

概要

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

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

ワークフロー

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

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

フロントエンドとバックエンドの両方を含む Web アプリケーションを作業している場合は、フロントエンドとバックエンドの両方について参照ドキュメントを必ず確認してください。

フロントエンドとバックエンドの両方を含む Web アプリを作成するよう求められていて、フロントエンドフレームワークが指定されていない場合は、javascript-general-web-frontend-security.md も確認してください。フロントエンドとバックエンドの両方を安全に保つ方法を理解することが重要です。

このスキルの references ディレクトリに関連情報がない場合は、その言語、フレームワーク、およびそれに関する広く知られたセキュリティのベストプラクティスについて、自分が知っていることを少し考えてください。確信が持てない場合は、セキュリティのベストプラクティスに関するドキュメントをオンラインで検索してみてください。

そこから、このスキルは次のいくつかの方法で動作できます。

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

2. 2番目のモードは、プロジェクトで作業してユーザーのためにコードを書いている間に、脆弱性を受動的に検出することです。重大または非常に重要な脆弱性、あるいはセキュリティガイダンスに反する大きな問題は、フラグを立ててユーザーに伝えることができます。この受動的なモードでは、最も影響の大きい脆弱性とセキュアなデフォルト設定に焦点を当てるべきです。

3. ユーザーは、セキュリティレポートの作成やコードベースのセキュリティ改善を依頼できます。この場合、プロジェクトがセキュリティのベストプラクティスのガイダンスにどの程度従っていないかを、どのような点でも説明する完全なレポートを作成する必要があります。レポートは優先順位付けされ、重大度と緊急度の明確なセクションを持つ必要があります。その後、これらの問題の修正作業を開始することを提案してください。下記の #fixes を参照してください。

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

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

オーバーライド

これらのリファレンスには言語やフレームワークごとのセキュリティのベストプラクティスが含まれていますが、顧客がこれらのプラクティスを回避またはオーバーライドする必要がある場合もあります。プロジェクトのドキュメントやプロンプトファイルに記載された、特定のベストプラクティスのオーバーライドを求める個別のルールや指示に注意してください。ベストプラクティスをオーバーライドする場合は、その旨をユーザーに報告しても構いませんが、ユーザーと争わないでください。プロジェクト固有の理由からセキュリティのベストプラクティスを回避または無視する必要がある場合は、なぜそのベストプラクティスに従っていないのかが明確になり、今後も同じ回避方法に従えるように、プロジェクトにその内容のドキュメントを追加することを提案しても構いません。

レポート形式

レポートを作成する場合は、security_best_practices_report.md というマークダウンファイルとして作成してください。ユーザーが別の場所を指定した場合はそちらに作成します。レポートの書き込み先をユーザーに尋ねても構いません。

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

レポートは脆弱性の深刻度ごとに複数のセクションに明確に分けてください。レポートでは、ユーザーへの影響が最も大きい最重要の発見事項に焦点を当ててください。すべての発見事項には、参照しやすいように数値のIDを付けてください。

重大な発見事項については、影響を一文で示してください。

レポートを書き終えたら、ユーザーにも直接報告してください。ただし、簡潔にまとめても構いません。ユーザーが任意の発見事項や、セキュリティのベストプラクティスの指針の理由についてさらに詳しい情報を求める場合は、説明を提供することを申し出てください。

重要: レポートでコードを参照する場合は、参照するコードの行番号を必ず見つけて記載してください。

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

また、最終的なレポートの書き込み先もユーザーに伝えてください。

修正

レポートを作成した場合は、ユーザーがレポートを読んだうえで、修正の実施を依頼するまで待ってください。

受動的に重大な発見事項を見つけた場合は、ユーザーに通知し、この発見事項を修正するかどうかを尋ねてください。

修正を行う際は、一度に1つの発見事項に集中してください。修正には、新しいコードが特定のセキュリティのベストプラクティスに基づいていることを説明する簡潔で明確なコメントを付け、必要に応じて、その方法を取らなかった場合に危険になる理由を簡単に添えてください。

変更がユーザーのコードの機能に影響するかどうかを必ず検討してください。変更によってプロジェクトの現在の動作に回帰が生じないかも検討してください。安全でないコードは、他の理由から依存されていることがよくあり、そのために長く残り続けるのです。プロジェクトを壊すとユーザーが今後セキュリティ修正を適用したくなくなる可能性があるため、避けてください。雑に作られた迅速な変更よりも、プロジェクトの他の部分を十分に踏まえた、よく考え抜かれた修正のほうが望ましいです。

ユーザーが設定している通常の変更フローやコミットフローには、必ず従ってください。Gitコミットを行う場合は、セキュリティのベストプラクティスに合わせるための変更であることを説明する明確なコミットメッセージを書いてください。関連のない複数の発見事項を1つのコミットにまとめることは避けてください。

回帰が発生していないことを確認するため、ユーザーが設定しているテストフロー（もしあれば）には必ず従ってください。変更が及ぼしうる二次的な影響を検討し、影響がある場合は変更を行う前にユーザーに知らせてください。

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

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

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

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

TLS についての注意

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