security-review

security-reviewスキルの概要

security-review スキルは、アプリケーションのセキュリティ上のよくある問題をリリース前に見つけるための実用的なレビュー支援ツールです。認証、ユーザー入力、シークレット、API、決済、アップロードなど、一般的なプロンプトでは曖昧になりやすく、見落としのコストが高い重要なフローを扱う開発者や AI エージェントに最適です。

ここでの主な目的は、抽象的な「セキュリティ理論」ではありません。コード変更を、具体的な合否基準を持つ狙いを絞ったセキュリティチェックに変えることです。security-review skill は、危険なデフォルト設定、検証不足、シークレットの扱いミスを、チェックリストをゼロから自力で組み立てることなく、素早く構造化して確認したいときに特に役立ちます。

何が便利なのか

一回限りのプロンプトと比べて、security-review スキルは再現性のあるレビューの枠組みを提供します。いつ起動するか、最初に何を見るか、どの失敗モードを重視するかが明確です。また、危険なパターンと安全なパターンの具体例も含まれているため、異なるスタックのコードをまたいでレビューするときにも役立ちます。

向いているユースケース

security-review は、次のような Security Audit タスクに使うと効果的です。

• ログイン、セッション、認可ロジック
• フォーム、アップロード、クエリパラメータなどの信頼できない入力
• 機密データを保存・公開・変換する API ルート
• シークレットへのアクセス、環境変数、デプロイ設定
• 悪用リスクが無視できない決済コードや外部サービス連携コード

何が期待できるか

このスキルが最も力を発揮するのは、フルのペネトレーションテストではなく、焦点を絞ったレビューが欲しいときです。セキュリティの基本が備わっているか、実装が明らかに安全でないか、最初の確認で穴が見つかった場合に次に何を確認すべきかを見極める助けになります。

security-reviewスキルの使い方

インストールして文脈に置く

security-review スキルは次のコマンドでインストールします。

npx skills add affaan-m/everything-claude-code --skill security-review

使うのは、セキュリティ上重要なタスクのときだけにしてください。日常的なリファクタリングのたびに使うものではありません。最良の結果が出やすいのは、「アプリ全体をチェックして」という広い依頼ではなく、特定の変更、ルート、コンポーネント、機能をレビュー対象として明確に伝えた場合です。

先に読むべきファイルを見極める

security-review の導入では、まず SKILL.md を読み、その周辺にある README.md、AGENTS.md、metadata.json、およびリンクされたフォルダや補助ドキュメントを確認してください。この repo で特に重要なソースファイルパスは SKILL.md と cloud-infrastructure-security.md です。

自分のワークフローにこのスキルを取り入れる場合も、まずスキルファイルを読んで起動条件を理解し、そのチェック項目を自分のコードベースの実際の認証、検証、デプロイのパターンに当てはめていくのが基本です。

レビュー向けのプロンプトにする

良いプロンプトには、対象範囲、脅威、欲しい出力が入っています。たとえば次のように依頼します。

• 「この signup フローを auth bypass、弱い validation、secret exposure の観点でレビューして」
• 「この API route の injection risk、broken access control、unsafe error handling を確認して」
• 「この payment webhook handler をレビューして、具体的な security issues と修正案を挙げて」

これは「security review して」だけよりも優れています。なぜなら、security-review usage の流れに対して、何を優先し、どんな証拠を探すべきかをはっきり伝えられるからです。

ざっくりした目的から実行可能なレビューへ進める

security-review guide として有効な進め方は次の通りです。

1. 機能と、関わる機密データを明示する。
2. 関連ファイルまたは diff を共有する。
3. リスク順に並べた指摘一覧を求める。
4. 具体的な修正案、または修正済みコードを依頼する。

より実用的な出力が欲しい場合は、フレームワーク、ランタイム、デプロイ環境などの制約も添えてください。シークレットの扱い方や検証パターンはスタックごとに異なるためです。

security-reviewスキルのFAQ

security-reviewスキルは上級者向けだけですか？

いいえ。曖昧なセキュリティの不安を具体的な確認項目に変えてくれるので、初心者にも有用です。特に、その機能が機微な情報を扱うことは分かっているが、どの失敗モードを重視すべきか分からない場合に役立ちます。

通常のプロンプトと何が違いますか？

通常のプロンプトでは、一般論だけの助言になりがちです。security-review skill は、再現性のあるレビュー手順、明確な発動条件、やってはいけないパターン、実コードに適用できる実践的な確認手順が必要なときに向いています。

使わないほうがいいのはどんなときですか？

auth、input、secret、外部連携に影響しない、低リスクな見た目調整や単純な内部リファクタリングには security-review を使わないでください。また、必要な場面では、フルのセキュリティ監査、ペネトレーションテスト、コンプライアンスレビューの代わりにもなりません。

Node 以外のプロジェクトにも使えますか？

はい。考え方自体は広く応用できますが、例は自分のスタックに合わせて置き換える必要があります。このスキルが特に強いのは、レビューのロジックを、そのフレームワーク固有の validation、secret storage、access-control の作法に落とし込める場合です。

security-reviewスキルを改善する方法

アプリ全体ではなく、危険な経路を渡す

最も良い出力は、1 つの endpoint、1 つの auth フロー、1 つの webhook、1 つの upload path のような、狙いを絞った対象から得られます。リポジトリ全体を渡すと、レビューが浅くなりがちです。security-review for Security Audit では、量よりスコープが重要です。

具体的な制約と脅威の文脈を添える

入力が強いほど、次のような情報が含まれます。

• どのデータが機密か
• 誰がこの機能を呼べるのか
• どんな外部システムが関与するのか
• そのコードが公開向けか内部向けか
• すでに弱いと疑っている点は何か

こうした情報があると、無関係な論点に注意を取られることなく、適切な種類の失敗に集中できます。

スタックに合う修正を求める

より良い結果を得たいなら、出力もコードベースと同じ言葉で依頼してください。たとえば middleware 名、schema validator、environment variable の扱い方、webhook verification の手順などです。security-review skill は、提案をそのまま変更可能なコードに結び付けられるときに最も役立ちます。

1回目の確認のあとに反復する

最初のレビューはトリアージとして扱ってください。1 件でも問題が見つかったら、同じファイルを対象に、authorization drift、unsafe defaults、logging 不足などの関連問題を再確認するよう依頼します。何も見つからなかった場合は、範囲を狭めて機微な経路だけを再送してください。そうすると security-review usage が引き続き焦点の合った、高信号なものになります。