security-requirement-extraction

security-requirement-extraction スキルの概要

security-requirement-extraction スキルでできること

security-requirement-extraction スキルは、脅威分析や業務コンテキストを、実際に使えるセキュリティ要件へ落とし込むためのスキルです。役割は単なる一般的な「セキュリティ助言」ではなく、構造化された変換にあります。つまり、リスク、悪用ケース、コンプライアンス上の要求を、要件、ユーザーストーリー、受け入れ基準、検証可能なセキュリティ期待値へと翻訳します。

どんな人に向いているか

このスキルは、セキュリティエンジニア、アーキテクト、プロダクトセキュリティチーム、ビジネスアナリスト、そして Requirements Planning を進めるデリバリーチームに特に向いています。すでに脅威や事業上の目標は把握しているものの、それをプロダクトチームやエンジニアリングチームが実装・検証できる形で表現したい場合にとくに有効です。

security-requirement-extraction が最も適しているジョブ

security-requirement-extraction は、次のような問いに答えたいときに使うのが適しています。

• 「この脅威を前提にすると、プロダクトにはどんなセキュリティ要件が必要か？」
• 「脅威モデルをどうやって受け入れ基準に変換すればよいか？」
• 「バックログに入れるべきセキュリティのユーザーストーリーは何か？」
• 「事業上守るべきものを、技術的な期待値にどう対応付けるか？」

一般的なプロンプトとの違い

security-requirement-extraction skill の価値は、出力の枠組みにあります。要件カテゴリ、要件タイプ、さらにトレーサビリティやテスタビリティといった要件品質属性を中心に据えている点が大きな違いです。一般的なプロンプトは、いきなりコントロールや対策案に飛びがちですが、このスキルは、その前段としてレビュー・優先順位付け・妥当性確認ができる要件を出すようモデルを導きます。

インストール前に知っておきたいこと

このスキルは軽量です。リポジトリ上で確認できる実体は SKILL.md のみで、補助スクリプト、参考資料、ルールファイルは含まれていません。そのため導入は簡単ですが、出力品質は入力コンテキストの質に大きく左右されます。脅威の記述が曖昧なら、返ってくる要件も曖昧になります。

このスキルが向かないケース

実際に必要なのが次のいずれかなら、security-requirement-extraction は選ばないほうがよいです。

• ゼロから始める本格的な脅威モデリング手法
• 詳細なコントロール実装手順
• コンプライアンスの法的解釈
• 自動スキャンやポリシー強制

このスキルが最も力を発揮するのは、リスクの洗い出しが終わった後、コントロールの詳細設計や実装に入る前の中間工程です。

security-requirement-extraction スキルの使い方

security-requirement-extraction のインストール情報

Skills エコシステムを使っている場合は、スキルを含むリポジトリから次のコマンドでインストールできます。

npx skills add https://github.com/wshobson/agents --skill security-requirement-extraction

リポジトリ構成から見ると、このスキルは plugins/security-scanning/skills/security-requirement-extraction にあり、最初に確認すべき実用的なソースは次のファイルです。

• SKILL.md

最初に読むべきファイル

まずは SKILL.md を読んでください。このスキルでは、このファイルに実際の運用指針がまとまっています。いつ使うべきか、要件カテゴリ、要件タイプ、要件属性といった実務上重要な情報がここにあります。補助リソースやスクリプトがないため、実際に使えるロジックの大半はこの1ファイルに集約されています。

security-requirement-extraction に必要な入力

security-requirement-extraction をしっかり活用するなら、少なくとも次の情報を入れるのが理想です。

• システムまたは機能の説明
• ビジネス目標
• 保護すべき資産
• 既知の脅威または悪用ケース
• ユーザーロールと信頼境界
• 適用されるコンプライアンスまたはポリシー上の制約
• デプロイ環境・運用コンテキスト
• 欲しい出力形式

これらがなくても要件自体は生成できますが、内容は一般論寄りになり、実際のリスクに結び付けて追跡しにくくなります。

最低限使えるプロンプト

実用になるプロンプトには、通常次の3点が含まれます。

1. 対象機能またはシステムの範囲
2. 要件化したい脅威
3. 必要な出力成果物

例:

“Use the security-requirement-extraction skill for Requirements Planning. We are building a customer billing portal. Threats include credential stuffing, privilege escalation, and PII exposure in logs. Derive security requirements grouped by functional, non-functional, and constraint types. Include traceability to each threat and draft acceptance criteria.”

より強いプロンプトの型

より質の高いプロンプトでは、レビュー可能な要件を出すための構造をモデルに十分与えます。

• Business context: だれがシステムを使い、事業上何が重要か
• Threat source: STRIDE の出力、悪用ケース、インシデント、ペネトレーションテストの指摘、アーキテクチャレビューのメモ
• System boundaries: サービス、データストア、連携先、管理者向け経路
• Requirement style: ユーザーストーリー、shall statements、バックログ項目、テストケース
• Quality bar: テスト可能、追跡可能、優先順位付き、重複なし

例:

“Use security-requirement-extraction to convert the following threat model into backlog-ready requirements. System: multi-tenant SaaS admin console. Assets: tenant configs, audit logs, API tokens. Threats: broken access control on admin APIs, token leakage in frontend logs, insecure session handling, missing auditability for privileged changes. Constraints: must align with SOC 2 controls and existing SSO platform. Output:

1. security requirements by type,
2. linked threat IDs,
3. rationale,
4. measurable acceptance criteria,
5. suggested security test cases.”

曖昧な目標をより良いプロンプトに変える方法

弱い依頼は、「このアプリのセキュリティ要件を出して」です。

より良い依頼は、次を明確にします。

• どんなアプリか
• どんなリスクがあるか
• どんなデータを扱うか
• どんな制約があるか
• どんな出力形式が必要か

改善例:

Weak:
“Generate security requirements for a healthcare app.”

Better:
“Use the security-requirement-extraction skill for a patient portal handling PHI. Threats include unauthorized record access, weak session expiration, insecure file upload, and audit log tampering. Produce functional, non-functional, and constraint requirements with traceability, testability, and acceptance criteria.”

security-requirement-extraction の実務向けワークフロー

security-requirement-extraction を実務で使うなら、次の流れが現実的です。

1. 事業コンテキストと機能スコープを整理する。
2. 脅威モデル、インシデントレビュー、アーキテクチャメモから脅威を集める。
3. スキルに対して、タイプ別の要件候補を出させる。
4. 重複、抜けている前提、テスト不能な表現がないかレビューする。
5. 承認した項目を、バックログのストーリー、アーキテクチャ要件、またはテストケースに落とし込む。
6. 脅威 ID やコンプライアンス根拠へのトレースリンクを追加する。

このワークフローこそ、このスキルの価値が最も出る場面です。セキュリティ分析と、実装・計画に使える成果物とのギャップを埋めやすくなります。

相性のよい出力形式

このスキルは、特に次の出力を得るのに向いています。

• 要件一覧
• セキュリティのユーザーストーリー
• セキュリティの受け入れ基準
• セキュリティテストケース
• 脅威と要件のマッピング
• アーキテクチャ文書の入力素材

チームで決まったフォーマットがあるなら、最初から明示して依頼するのが有効です。このスキルは複数の要件表現に対応できますが、欲しい成果物を指定したほうが、標準出力よりも実務で使いやすくなります。

出力品質を上げる実践的なコツ

security-requirement-extraction をより良く使うには、次の点が有効です。

• トレーサビリティを明示するため、脅威 ID やラベルを渡す
• 広い目標ではなく、測定可能な表現を求める
• ビジネス要件と技術的コントロールを分ける
• コンテキストが不足している場合は、前提条件と未解決事項を出させる
• テスト不能な要件があればフラグを立てるよう依頼する

これらが重要なのは、このスキルが単なるアイデア出しではなく、要件品質そのものを重視しているためです。

リポジトリ上の制約として見込むべきこと

このリポジトリには SKILL.md 以外の補助アセットがないため、より作り込まれたスキルに比べると、組み込みの強制力は弱めです。少なくとも1回は次の観点でレビューする前提で使うとよいです。

• コントロールレベルまで踏み込みすぎていないか
• 要件が重複していないか
• 「secure」「appropriate」「robust」のような曖昧表現が残っていないか
• 1行の中にポリシー、設計、実装が混在していないか

security-requirement-extraction スキル FAQ

security-requirement-extraction は Requirements Planning に向いていますか？

はい。security-requirement-extraction は Requirements Planning と相性がよく、セキュリティ上の懸念を、バックログ投入可能な要件、ストーリー、受け入れ基準へ変換するのに役立ちます。実装が始まった後よりも、計画段階で使うほうが効果を発揮しやすいです。

先に正式な脅威モデルが必要ですか？

いいえ。ただし、何らかのリスク入力は必要です。正式な脅威モデルがあるのが理想ですが、インシデントの傾向、悪用ケース、セキュリティレビューのメモ、アーキテクチャ上のリスクでも代用できます。脅威入力の質が高いほど、出てくる要件の質も上がります。

LLM に普通にセキュリティ要件を聞くのと何が違いますか？

一般的なプロンプトでは、緩いチェックリストのような出力になりがちです。security-requirement-extraction skill は、要件カテゴリ、要件タイプ、そしてトレーサビリティやテスタビリティといった要件属性に対して、より規律ある形で出力を組み立てます。その構造により、チームがレビューしやすく、実装にもつなげやすい成果物になりやすいのが違いです。

初心者でも使いやすいですか？

中程度です。インストール自体は簡単ですが、良い結果を得るには有用なコンテキストを自分で与える必要があります。初心者でも使えますが、反復が必要になることが多く、要件とコントロールの違いを見分ける場面では補助が必要になるかもしれません。

技術的コントロールを直接出力できますか？

提案は可能ですが、それがこのスキルの主目的ではありません。このスキルはまず、事業上のニーズや脅威からセキュリティ要件を導く設計になっています。この切り分けは、解決策の自由度を残したい場合や、実装方針を決める前にステークホルダーのレビューを通したい場合に特に有効です。

security-requirement-extraction を使わないほうがよいのはどんなときですか？

次のニーズが直近の目的なら、見送るのが適切です。

• コード修正の具体的ガイダンス
• スキャナ設定
• コントロール検証ツール
• 法務レベルのコンプライアンス解釈
• セキュアアーキテクチャ設計一式

こうしたケースでは、このスキルを入力素材として使うことはできますが、主たる手段には向きません。

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

量よりも、より良い脅威入力を与える

security-requirement-extraction の出力を最も手早く改善する方法は、文章量を増やすことではなく、脅威の記述を明確にすることです。たとえば “Data breach risk” は弱い入力です。一方で “Unauthorized tenant-to-tenant data access via missing authorization checks in reporting endpoints” は強い入力です。脅威が具体的であるほど、要件はテストしやすく、一般論に流れにくくなります。

要件とコントロールを分ける

よくある失敗は、要件を求めたのに、早い段階で実装判断まで混ざってしまうことです。改善するには、次のように分けて依頼します。

• requirement statement
• rationale
• acceptance criteria
• possible controls as a separate optional field

こうしておくと、技術スタックが変わっても要件自体を流用しやすくなります。

トレーサビリティを明示的に求める

トレーサビリティが重要なら、プロンプト内で必ず明示してください。たとえば次のような指定です。

• 各要件を threat ID に対応付ける
• business objective に対応付ける
• relevant な場合は compliance source に対応付ける

これにより、security-requirement-extraction skill は監査、アーキテクチャレビュー、バックログ精査でより使いやすくなります。

テスト可能な言い回しを強制する

初稿では、曖昧で柔らかい表現が残りがちです。各要件を検証可能な形に書き換えるようモデルに求めてください。特に有効なのは次の要素です。

• 測定可能な閾値
• イベントカバレッジの期待値
• 対象となるアクターとデータ範囲
• pass/fail で判定できる acceptance criteria

テスト可能な表現にするだけで、後続のエンジニアリングでの使い勝手は大きく改善します。

バックログ圧力が高いなら優先順位付けを依頼する

意思決定の材料が必要なら、次の観点で要件を分類させると有効です。

• must-have と should-have
• pre-launch と post-launch
• threat severity
• compliance criticality

これにより、量は多いが使えない一覧を作ってしまうのを防ぎやすくなります。

1回の反復で曖昧さを落とす

初稿の後に、次のように問い返してください。

• どの要件が重複しているか？
• どの要件が曖昧すぎてテストできないか？
• どの要件が未解決のアーキテクチャ判断に依存しているか？
• どの項目が実は要件ではなくコントロールか？

このレビュー用プロンプトは、完全に新しいドラフトを作り直させるよりも、出力改善に効くことが多いです。

システム境界と前提条件を追加する

このスキルは、次のような境界条件を明示すると精度が上がります。

• internal-only か internet-facing か
• single-tenant か multi-tenant か
• managed identity か local auth か
• 扱う機微データの分類
• 管理者機能の範囲

これらの情報は、特にアクセス制御、ロギング、データ取り扱いに関する要件を大きく左右します。

成果物を指定して出力を強化する

納品物の形が決まっているなら、名前をはっきり指定してください。たとえば次のような依頼です。

• “write security user stories”
• “produce acceptance criteria”
• “derive security test cases”
• “draft architecture security requirements”

このスキルはどれにも対応できますが、最終成果物を明示したほうが出力の質は上がります。

採用前に最終セットを検証する

結果を完成版として扱う前に、各要件が次を満たしているか確認してください。

• 実在するリスクまたは事業要件に結び付いている
• セキュリティ担当以外のステークホルダーにも理解できる
• 意図を推測せずにテストできる
• 単なるコントロール文の貼り付けになっていない
• 実際のシステム境界に収まっている

この最終確認こそ、実務で security-requirement-extraction を導入する価値が出るポイントです。単発のプロンプトではなく、再現可能な計画支援として使えるようになります。