security-auditor

security-auditorスキルの概要

security-auditorでできること

security-auditor スキルは、コード監査や脆弱性トリアージを支援する、用途を絞ったセキュリティレビュー補助です。深い自動スキャンを行うというより、OWASP Top 10 に沿った確認、軽量なリポジトリ点検、そしてシンプルなレポート作成フローを中心に設計されています。アプリケーションコードを AI アシスタントに見せて、よくあるセキュリティ上の弱点を洗い出し、あり得る指摘を示し、監査レポートの形まで整えたいなら、security-auditor は実用的な出発点になります。

security-auditorスキルが向いている人

この security-auditor skill が特に合うのは、既存コードベースに対して素早く一次監査をかけたい開発者、セキュリティ意識の高いレビュアー、テックリード、エージェント利用者です。単なる「このコードに脆弱性がないか見て」という汎用プロンプトより、もう一段構造化されたレビューがほしい一方で、本格的な SAST プラットフォームまでは不要というケースで特に役立ちます。

実際に解決したい仕事

多くの人が欲しいのは、OWASP の理論講座ではありません。知りたいのは、たとえば次のようなことです。

• このリポジトリでは、まず何から確認すべきか
• 認証、シークレット、インジェクション、設定まわりに明白なリスクがあるか
• チームにそのまま渡せるレポート形式で指摘をまとめられるか
• 脆弱性だと判断する前に、どんな具体的証拠を集めるべきか

security-auditor は、こうした実務フローを助けるためのスキルです。

security-auditorが他と違う点

security-auditor の主な差別化ポイントは、次の要素をまとめて備えていることです。

• セキュリティレビュー依頼に反応するためのアクティベーションルール
• OWASP を軸にしたチェックリストと grep 的な調査パターン
• シークレット検出とレポート生成の補助スクリプト
• チェックリスト、OWASP カテゴリ、修正手順の参照ファイル

そのため、アナリスト主導の軽量な仕組みではあるものの、素のプロンプトより実務で使いやすくなっています。

置き換えられないもの

これは次の代替にはなりません。

• 依存関係スキャナ
• DAST ツール
• インフラやクラウド構成のセキュリティレビュー
• 手動でのエクスプロイト検証
• あらゆる技術スタックに対する言語別のセキュアコーディング専門知識

security-auditor for Security Audit は、完全なセキュリティプログラムの代わりではなく、ガイド付きレビューのレイヤーがほしいときに使うものです。

security-auditorスキルの使い方

security-auditorのインストール方法

スキルのワークフローで GitHub インストールに対応しているなら、実用的な導入手順は次のとおりです。

npx skills add https://github.com/zhaono1/agent-playbook --skill security-auditor

すでにこのリポジトリをローカルで使っている場合は、skills/security-auditor/ 以下を確認してください。

最初に読むべきファイル

最短で使い始めたいなら、読む順番は次のとおりです。

1. SKILL.md
2. README.md
3. references/checklist.md
4. references/owasp.md
5. references/remediation.md
6. scripts/find_secrets.py
7. scripts/security_audit.py

この順番で見ると、まずスコープを把握し、その次に監査チェックリスト、修正時の考え方、最後に補助自動化の内容まで効率よくつかめます。

security-auditorに必要な入力

security-auditor usage の質は、スコープの与え方に大きく左右されます。最低でも次の情報を渡してください。

• リポジトリのパス、または対象ファイル
• アプリ種別と技術スタック
• 信頼境界
• 保護すべき機微資産
• 認証モデル
• デプロイ文脈
• この監査で何をもって完了とするか

弱い依頼の例:
Audit this repo for security issues.

より良い依頼の例:
Audit the API service in ./backend for OWASP Top 10 issues. Focus on auth, IDOR, secrets exposure, SSRF, and unsafe deserialization. Assume this service handles customer billing data and uses JWT auth. Return findings with severity, file evidence, exploit path, and remediation.

実際にどういう依頼で起動するか

リポジトリ上では、このスキルは次のような依頼で有効化される想定です。

• security audit
• vulnerabilities
• security review
• OWASP-related checks

ただし実運用では、より明示的に書くのがおすすめです。対象、リスク領域、欲しい出力形式まで指定したほうが、エージェントが一般論のアドバイスで止まらずに済みます。

曖昧な依頼をより良いプロンプトにする

security-auditor guide をうまく使うなら、次の型に沿うと精度が上がります。

• Scope: どのサービス、フォルダ、PR か
• Risk focus: auth、secrets、injection、SSRF、crypto、logging
• Evidence standard: ファイル、ルート、設定、コマンドのどれを根拠として示すか
• Output: 重大度と修正案を含む findings の表
• Constraints: コード上の証拠がない推測的な指摘は含めない

例:
Use security-auditor on ./src and ./config. Check for OWASP Top 10 issues, especially broken access control, hardcoded secrets, weak hashing, and unsafe external requests. For each finding, cite the exact file and code path, explain the impact, and propose the smallest safe fix.

同梱スクリプトを使う

このリポジトリには、実務で使いやすい補助ツールが 2 つ含まれています。

シークレットスキャナを実行:

python scripts/find_secrets.py .

監査レポートのテンプレートを生成:

python scripts/security_audit.py --name "payments-api" --owner "platform-security"

どちらもシンプルなスクリプトですが、十分に実用的です。find_secrets.py はよくある認証情報パターンをいくつか検出し、security_audit.py は構造化されたレポートを作るので、指摘事項の引き継ぎがしやすくなります。

スクリプトでできること・できないこと

シークレットスキャナは、意図的に軽量に作られています。AWS 風のキー、Google API キー、sk- 形式のトークンなど、限られた既知パターンをテキストファイルから検索します。そのため、多くのシークレット形式は見逃しますし、本番用ではないサンプル文字列を誤検知する可能性もあります。

一方、レポートジェネレータは分析を行いません。作成されるのは、スコープ、責任者、脅威モデル、findings、remediation、evidence の各セクションを持つ markdown の監査ひな型です。

実務監査に向いたsecurity-auditorの進め方

実践的な security-auditor usage フローは次のようになります。

1. 監査スコープと重要資産を定義する。
2. まず auth、routes、config、secrets、outbound calls など高リスク領域を調べるようエージェントに依頼する。
3. scripts/find_secrets.py を走らせて認証情報の簡易チェックを行う。
4. references/checklist.md のチェックリストで見落としを防ぐ。
5. 候補となる指摘を references/owasp.md のカテゴリに対応付ける。
6. references/remediation.md をもとに修正方針を下書きする。
7. 検証できた findings だけを security-audit.md に生成または記入する。

この流れなら、一般的な警告リストではなく、証拠に基づいた監査にしやすくなります。

最初に見るべき高価値なリポジトリ箇所

このスキルは、セキュリティ上のホットスポットを狙って見せたときに最も効果を発揮します。

• route handlers と controllers
• auth middleware
• config と environment の読み込み処理
• file upload ロジック
• URL fetchers と webhook handlers
• serialization と template rendering
• dependency manifests
• logging と monitoring のコード

逆に、モノレポ全体を一度にレビューさせると、結果は浅くなりがちです。

Security Audit向けsecurity-auditorが特に向くケース

security-auditor for Security Audit は、次のような用途に向いています。

• マージ前やリリース前の一次セキュリティレビュー
• 小〜中規模コードベースの構造化監査
• API や Web アプリのロジックを OWASP 観点でレビューしたい場合
• エンジニアが追跡しやすい証拠付き findings がほしい場合
• 手動レビューを補完する軽量な仕組みがほしい場合

通常のプロンプトだけで十分な場合

怪しい関数 1 つについて単発の説明がほしいだけなら、普通のプロンプトでも十分なことがあります。security-auditor の価値が出るのは、再現性のあるカバレッジ、リポジトリの読み方の誘導、チェックリスト、そしてレポート化までの道筋が必要なときです。

security-auditorスキル FAQ

security-auditorは初心者にも向いているか

はい。ただし注意点があります。初心者にとって、チェックリストや OWASP ベースの枠組みは有用ですが、指摘内容の検証は自分で行う必要があります。このスキルは、より良い問いを立てたり、よくある失敗ポイントを点検したりする助けにはなりますが、それだけで悪用可能性やビジネス影響まで保証するものではありません。

security-auditorスキルは依存関係をスキャンするか

直接はしません。参照ファイルではレビューの一部として依存関係の脆弱性確認に触れていますが、同梱スクリプトに package audit 機能はありません。npm audit、pip-audit、cargo audit など、各エコシステム標準のツールや同等のスキャナと組み合わせて使うべきです。

Webアプリ専用なのか

主な適性はそこにあります。リポジトリは broken access control、injection、misconfiguration、SSRF といった OWASP Top 10 のカテゴリを中心に構成されており、Web アプリや API で最も自然に使えます。近接するサービスでも活用はできますが、例やチェック内容は Web 寄りです。

汎用的なセキュリティプロンプトと何が違うのか

汎用プロンプトは、レビューの進め方そのものをモデルに考えさせることになります。対して security-auditor skill は、より明確な監査フレーム、明示的な OWASP カテゴリ、補助リファレンス、そしてよくある作業向けのスクリプトを与えてくれます。準備の手探りが減り、出力の一貫性も高めやすくなります。

どんなときはsecurity-auditorを使わないほうがいいか

次のようなニーズには、このスキルは向きません。

• バイナリ解析
• クラウド IAM 評価
• コンテナハードニングレビュー
• エクスプロイト開発
• コードレビューなしのコンプライアンス文書作成
• 高信頼な自動スキャナの置き換え

また、最初から深い言語別静的解析を期待するチームにとっても、適合度は高くありません。

security-auditorは修正支援までしてくれるか

はい、ただし軽量です。references/remediation.md には、再現、影響把握、修正、テスト追加、変更記録という基本的な修正フローがまとめられています。つまり、修正プロセスを整理するのは得意ですが、あらゆるスタックに対してフレームワーク別の安全なパッチコードまで細かく出すことを主目的にしたものではありません。

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

security-auditorのスコープをより鋭く指定する

最も効く改善ポイントは、スコープ定義です。security-auditor には次を具体的に伝えてください。

• どのフォルダが重要か
• どのデータが機微情報か
• 誰が何にアクセスできるべきか
• どの外部システムを信頼しているか
• どの findings を優先すべきか

ここが曖昧だと、一般論の OWASP コメントに寄りやすくなります。

指摘だけでなく証拠を求める

より良いプロンプトでは、次の要素を要求します。

• 正確なファイルパス
• コード断片または行参照
• 攻撃成立の前提条件
• 現実的な影響
• 信頼度
• 最小限の修正案

こうしておくと、誤検知を減らし、エンジニアが実際に使える出力にしやすくなります。

重大度と悪用可能性でふるい分ける

すべてのコード臭がエスカレーションに値するわけではありません。スキルには次の区分けを依頼すると有効です。

• confirmed vulnerability
• likely weakness needing validation
• hardening suggestion
• non-issue after context review

これにより、理論上の懸念ばかりが並ぶノイジーな監査レポートを避けやすくなります。

リポジトリ固有のツールと組み合わせる

security-auditor install は出発点にすぎません。出力品質を上げるには、次のものと併用してください。

• test suites
• dependency audit tools
• framework security linters
• secret managers と config review
• 可能であれば runtime logs や request traces

実際のプロジェクト証拠を材料に推論できるほど、このスキルの価値は高まります。

よくある失敗パターン

主な失敗パターンは次のとおりです。

• 一度に広すぎるスコープを監査する
• コード上の根拠なしに一般的な OWASP 問題を報告する
• 認可まわりのビジネスロジック文脈を見落とす
• 軽量なシークレットスキャナを過信する
• レポートテンプレートを分析完了とみなす

こうした問題の多くは、プロンプトを絞り、レビュー対象を狭めることで改善できます。

最初のパス後に繰り返し精査する

良い進め方は次のとおりです。

1. まず候補 findings を出させる。
2. 各 finding について、証拠と exploit path を問い直す。
3. トレードオフ付きで remediation options を出させる。
4. 足りないテストケースを挙げさせる。
5. 修正済みファイルだけを対象に再実行する。

広く一度だけ監査させるより、この反復ループのほうが精度向上にははるかに効きます。

許容する出力例を示してプロンプトを強化する

使えるレポートがほしいなら、その旨を明示してください。例:

Use security-auditor to review ./api. Return a table with Severity, OWASP Category, File, Evidence, Impact, Remediation, and Confidence. Only include findings tied to concrete code or config. Add a short "needs manual validation" section for suspicious patterns that are not yet proven.

単に「このコードは安全か」と聞くより、こうした指示のほうが実務向けの監査成果物になりやすいです。

独自の参照資料を追加してスキルを強化する

このスキルを継続的に使うなら、最も簡単な強化策は参照資料を拡張することです。たとえば次を追加できます。

• スタック固有のセキュアコーディング規約
• 組織承認済みの severity 定義
• 利用フレームワーク向けの remediation 例
• 社内レビュー用チェックリスト
• 既知の高リスクモジュールや auth パターン

そうすることで、security-auditor は汎用的な OWASP 補助から、実際の運用環境に合ったレビュー・ワークフローへと育てられます。