software-security-appsec

ソフトウェアセキュリティとアプリケーションセキュリティ

認証、認可、入力と出力の処理、暗号技術、サプライチェーン管理、API セキュリティ、脅威モデリング、セキュリティレビューなど、アプリケーション層のセキュリティにこのスキルを使用してください。これはアプリケーションセキュリティに関する判断レイヤーであり、一般的なバックエンドやインフラストラクチャの強化を扱うものではありません。

クイックリファレンス

タスク	使用するもの
リスクカテゴリの整理	references/owasp-top-10.md
認証と認可の選択	references/authentication-authorization.md、assets/web-application/template-authentication.md、assets/web-application/template-authorization.md
入力処理、アップロード、レンダリング、一般的なバグ	references/input-validation.md、references/common-vulnerabilities.md
セキュア設計と脅威モデリング	references/secure-design-principles.md、references/threat-modeling-guide.md
API とサプライチェーンのセキュリティ	references/api-security-patterns.md、references/supply-chain-security.md、assets/api/template-secure-api.md
暗号技術、パスワードハッシュ化、通信方式の選択	references/cryptography-standards.md
エージェント、LLM、MCP アプリケーションの設計	references/agentic-llm-appsec.md（テストについては qa-security-testing を参照してください）
モバイルのセキュアなストレージ、ピンニングポリシー、アテステーション	assets/mobile/template-mobile-security.md
シークレットストレージの選択	以下の「シークレットストレージの選択」を参照してください。プロバイダーで暗号化とプレーンテキストのどちらを選ぶか、保存後に検証する方法について説明しています
インシデント対応とセキュリティプログラムの整理	references/incident-response-playbook.md、references/security-business-value.md、references/operational-playbook.md

シークレットストレージの選択

プロバイダーの認証情報ストレージを選択し、値を読み取れるユーザーを確認してください。保存時の暗号化が、書き込み専用アクセスや完全な読み取り監査を意味するわけではありません。

プロバイダー	認証情報ストレージ	使用前の確認事項
Cloudflare Workers	wrangler secret put	通常の vars バインディングではなく、シークレットバインディングであることを確認してください。Workers secretsを参照してください
Vercel	シークレット環境変数	Vercel のドキュメントで、現在の書き込み専用オプションと環境のスコープを確認してください。読み取り可能な Config 値でも、暗号化されている場合があります
GitHub Actions	リポジトリ／Organization のシークレット	ワークフローと環境へのアクセスを制限してください。認証情報をワークフローの env: リテラルやリポジトリの Variables に含めないでください
AWS	Secrets Manager または SSM SecureString	復号／読み取り権限を制限してください。認可されたクライアントはプレーンテキストを取得できます（Secrets Manager retrieval）
Kubernetes	保存時暗号化を設定した Secret	Base64だけでは暗号化されません。APIおよびPod作成へのアクセスを制限してください（Kubernetes Secrets）

APIキー、署名キー、パスワード、Webhookシークレットにはシークレットストレージを使用してください。公開識別子は通常の設定に保存します。複数行の値には、保護されたファイルまたはプロバイダーのCLI入力を優先し、値を出力せず、認可されたテストを通じて正確なバイト列を確認してください。すべてのダッシュボードで改行が壊れると決めつけないでください。

認証情報が権限のないユーザーに漏えいした場合は、発行元で無効化してローテーションし、漏えいしたコピーを削除して、置き換えた認証情報のスコープを確認してください。読み取り可能な設定に保存されている場合は、漏えいの可能性を評価する必要がありますが、それだけで侵害があったとは証明できません。

使用する場面

• 認証、セッション、トークン、認可のフローをレビューまたは設計する。
• 入力処理、アップロード、レンダリング、信頼できないデータの境界を検証する。
• API、Webhook、ブラウザーアプリ、管理画面を保護する。
• 機能またはAppSecアーキテクチャの選択について脅威モデリングを行う。
• 依存関係、ビルド、アーティファクト、リリースの経路を強化する。
• AppSecの観点から、エージェント型アプリケーションやMCP接続アプリケーションをレビューする。

他に振り分ける場合

• セキュリティに重点を置かない一般的なバックエンド開発： software-backendを使用してください。
• インフラストラクチャの強化、IAM、クラスターのポリシー、クラウドのセキュリティ態勢：ops-devops-platformを使用してください。
• スマートコントラクトに特化した監査：software-crypto-web3を使用してください（監査手法はreferences/smart-contract-security-auditing.mdが担当します）。
• セキュリティテストツールとカバレッジ（SAST/DAST、LLM／エージェント型テストスイート）：qa-security-testingを使用してください。
• MLパイプラインまたはモデル運用のガバナンス：ai-mlopsを使用してください。
• 実装上の選択を伴わない、コンプライアンスのみの解釈：法務またはコンプライアンスの関係者に振り分けてください。
• 配布済みバイナリ、APK/IPA、Electron/ASAR、ファームウェアのリバースエンジニアリング、または逆コンパイル：このライブラリの担当範囲ではありません。ここにコピーしたものではなく、morluto/rea（MIT）のアップストリームREAスキルとMCPサーバーを使用してください。これはREAのツール名とバージョンに紐づいているためです。ローカルのバイナリを分析するため、サードパーティ製スキルとしてレビューし（agents-skillsの「インストール前にサードパーティ製スキルをレビューする」を参照）、インストール前にバージョンを固定してください。

デフォルト

• リスクの枠組みには OWASP Top 10、要件の深さには ASVS、SDLC のベースラインには NIST SSDF を使用します。選定時には発行元のページを確認し、適用した版とステータスを記録して、ドラフトと最終規格を区別してください：OWASP Top 10、ASVS、SSDF、SLSA、NIST digital identity、WebAuthn、OWASP GenAI。CRA の適用範囲については、supply-chain-security.md で扱っています。
• 実現可能な場合はパスキーを優先し、ブラウザー中心のアプリではセッションを使用します。
• 制御を選ぶ前に、信頼境界をモデル化します。
• エージェント型システムでは、ツール呼び出し、取得したコンテンツ、長期メモリを信頼できない入力として扱います。

ワークフロー

1. 資産、信頼境界、攻撃者の能力、障害がもたらす影響を特定します。
2. 問題を分類します：認証、認可、信頼できない入力、API、サプライチェーン、エージェント型フロー、またはセキュア設計の問題。
3. 関連するリファレンスから制御ファミリーを選択します。
4. 具体的な保護策を適用し、検証の深さを定めます。
5. 最終的な推奨を行う前に、変化しやすい標準とプロバイダーの挙動を再確認します。

AI レビュアーを使ったセルフ監査の範囲設定：チームがコードを所有しており、目的は修正であることを明示します。1 回のレビューにつき 1 つのモジュールまたは信頼境界を対象とします。まず静的ツール（SAST、依存関係監査、シークレットスキャン）を実行し、実際のコードパスに照らして出力をトリアージするようレビュアーに依頼します。エクスプロイト用ペイロードではなく、修正と安全な再現方法を求めます。リポジトリ全体を対象にした「すべての脆弱性を見つけて」というプロンプトでは、浅く検証不能な結果になり、プロバイダーの安全性フィルターに抵触するおそれがあります。

認証モデルの選択

状況	選択するもの	避けるもの
ブラウザーユーザーがいる製品で、セッション状態を許容できる	サーバーセッション（Cookie + サーバー側ストア）	セッション用の JWT — 失効が困難です
デバイスネイティブの生体認証を利用するモバイル／デスクトップアプリ	パスキー（WebAuthn）	SMS OTP — SIM スワップのリスクがあります
サードパーティーのサインインまたは委任アクセス	ID には OIDC、委任アクセスには OAuth 認可コードフロー + PKCE	インプリシットフロー。RFC 9700 のセキュリティガイダンスを適用してください
ユーザーコンテキストがない API 間通信	mTLS または有効期間の短い署名付きトークン	有効期間の長い API キー
信頼できるクラスター内のサービス間認証	サービスアカウント + mTLS	共有シークレットまたはユーザートークン

入力制御の選択

シンク／操作	必要な制御
SQL クエリの構築	パラメーター化クエリまたは ORM バインディング。文字列連結は決して使用しないでください
シェル／プロセスの実行	引数を許可リストで制限し、ユーザー入力を使った shell=True / exec を避けます
HTML のレンダリング	コンテキストに応じた出力エンコーディング、CSP ヘッダー
ファイルアップロード先のパス	正規化し、パストラバーサルの文字列を拒否し、Web ルートの外部に保存します
リダイレクト先	既知のオリジンを許可リストに登録し、オープンリダイレクトのパターンを拒否します
LDAP / XPath / XML	クエリ構築前に、ライブラリレベルのエスケープまたはスキーマ検証を行います
LLM / エージェントのツール呼び出し入力	信頼できない入力として扱い、実行前にスキーマを検証し、意図とスコープをログに記録します

重要な判断

認証とセッション

デフォルトの選択肢：

• 製品と復旧フローが対応している場合はパスキー
• ブラウザーアプリにはサーバーセッション
• サインインには OIDC、委任アクセスには OAuth 認可コードフローと PKCE を使用し、RFC 9700 に従います。最終規格として提示する前に OAuth 2.1 のステータス を確認してください
• 真にステートレスである必要がある場合に限り、有効期間の短いトークン

アプリの形態に合う、最もシンプルで安全なモデルを選択します。

認可と入力境界

最低限のルール：

• デフォルトで拒否する
• サーバー上で認可を確認する
• 境界で検証する
• 危険なシンクではパラメーター化する
• リッチコンテンツとファイルアップロードは、安全性が確認されるまでアクティブコンテンツとして扱う

セキュア設計と脅威モデリング

実装前に脅威をモデル化します：

• 機密データの保存
• 特権を伴う操作
• 外部コールバック
• ファイルアップロード
• リッチコンテンツのレンダリング
• エージェントまたはツールのフロー

後から強化するより、デフォルトでセキュアな設計にするほうが速く、堅牢です。

エージェントおよび MCP のセキュリティ

以下を明示的にモデル化します：

• プロンプトインジェクション
• ツールの悪用
• メモリー汚染
• テナント間の情報漏えい
• 広範すぎるサーバーの機能
• 安全でない承認フロー

読み取り専用の機能と変更を伴う機能を分離し、意図、範囲、結果を記録します。信頼できないコンテンツ、プライベートデータ、データ流出または変更の経路を、決して単一のコンテキストに組み合わせないでください。脅威から制御への設計については、references/agentic-llm-appsec.mdを参照してください。

従量制またはコストのかかる操作（単一ソース設計パターン）：上限付きのクォータを消費する、費用が発生する、またはその他の理由でコストがかかる、もしくは取り消し不能なエージェントのアクションでは、以前にキャッシュした確認結果ではなく、該当の呼び出しを行う直前に、現在の認可状態とクォータ状態を再確認してください。ユーザーが認可した予算とアクションの範囲を適用します。呼び出しがそれらを超える場合、または認可によって呼び出しごとの確認が求められる場合は、新たに確認を求めてください。実行途中で失敗した場合は、再実行によって従量制コストが再度発生するため、最初からやり直すのではなく、保存した状態から再開してください。

サプライチェーンとリリースの完全性

以下を使用します：

• ロックファイル
• 信頼できる公開または来歴情報
• アーティファクトの完全性チェック
• 必要に応じた SBOM
• 依存関係に由来するリスクの明示的なレビュー

検証チェックリスト

脆弱性指摘の証拠要件。

各セキュリティ上の指摘について、攻撃者が可能なこと、到達可能なエントリーポイント、信頼境界を越える箇所、シンク、具体的な影響を特定します。確認済みの悪用経路と、多層防御上の不備、未検証の仮説を分けてください。安全な再現手順またはコードパスの追跡と、実行可能な最小限の修正を提示します。深刻度は、リスクがあるように見える API が存在するかどうかではなく、悪用可能性と影響に基づいて判断します。

AppSec の設計またはレビューの出力を確定する前に、以下を確認してください：

• 信頼境界を明示的に図示している — 境界を越える入力はすべて検証または拒否される
• デフォルトから認証モデルを選択している（パスキー → サーバーセッション → OIDC/PKCE → 短期トークン）
• サーバー側で認可を確認している。特権を伴うすべてのエンドポイントでデフォルト拒否を徹底している
• すべてのシンクをパラメーター化している：SQL、シェル、LDAP、XPath、XML、HTML レンダリング、リダイレクト先
• ファイルアップロードとリッチコンテンツをアクティブコンテンツとして扱っている：タイプ検証、サイズ制限、ストレージ分離
• 認証情報にプロバイダーのシークレットストレージを使用している。読み取り権限、環境スコープ、暗号化設定を確認している
• サプライチェーン対策を講じている：ロックファイル、依存関係のスキャン、アーティファクトの完全性、必要に応じた SBOM
• エージェントのフローについて、プロンプトインジェクション、ツールの悪用、テナント間の情報漏えい、広すぎるスコープを脅威モデルで検討している
• 残存リスクを、軽減策と責任者とともに文書化している
• 標準とブラウザーの挙動に関する主張を、最終出力前に最新の情報源に照らして検証している

出力形式

以下のいずれかをデフォルトとします：

• セキュリティ設計概要： 脅威、制御の選択、検証の範囲。
• セキュリティレビュー： 指摘事項、リスク、実装の優先順位。
• 認証または API の強化計画： 推奨モデル、注意点、検証手順。
• エージェント AppSec レビュー： 脅威モデル、機能の境界、承認制御。

既知の落とし穴

• アーキテクチャや製品のフローがすでに確定した後にセキュリティレビューを始めると、設計の根本的な問題を補うための対策に多大なコストがかかります。
• 認証と認可を混同し、有効なIDトークンがあれば権限の問題も解決すると考えることです。
• ファイルのアップロード、リッチテキスト、マークダウン、取得したツールのコンテンツを、攻撃者が制御できるアクティブな入力ではなく、受動的なデータとして扱うことです。
• 読み取り専用のツールまたはMCPアクションと、変更を伴うツールまたはMCPアクションに、同じ権限範囲を使い回すことです。
• インフラのセキュリティ状況やマネージドプラットフォームが、アプリケーションレベルの制御設計の弱さを補えると考えることです。
• 'unsafe-inline' または 'unsafe-eval' をデフォルトとするCSPをリリースすることです。どちらも、そのポリシーが目的とするXSS保護の多くを損ないます。依存関係によって避けられない場合は、担当者とノンスまたはハッシュへの移行計画を定めた技術的負債として扱ってください。

アンチパターン

• 標準の状況を確認せず、常に最新だと見なすことです。
• アプリケーションに必要な範囲を超えて複雑な認証メカニズムを使うことです。
• システムの深部で、検証されていない入力を信頼することです。
• ツールまたはMCPの権限をデフォルトで広く設定したままにすることです。
• 実装上の選択が確定した後で、機能にセキュリティ対策を後付けすることです。
• インフラのセキュリティ状況とアプリケーションのセキュリティ設計を混同することです。

ナビゲーション

• 攻撃者の動機が不確かな状況で制御策の優先順位を決める場合は、game-theory-applied.mdを読み込んでください。可用性に関するトレードオフについては、reliability-theory-applied.mdを読み込んでください。
• 横方向の信頼境界については、zero-trust-architecture.mdを読み込んでください。
• 高度なブラウザーのペイロードまたは.NETの暗号化統合については、advanced-xss-techniques.mdまたはdotnet-efcore-crypto-security.mdを読み込んでください。
• コントラクトコードのリスクについては、上記のsoftware-crypto-web3への引き継ぎに従い、脆弱性カタログとしてassets/web3/crypto-security.mdを使用してください。
• 主張の出典を確認する必要がある場合は、data/sources.jsonを参照してください。

出典表示：Agentic and MCP Securityにある、従量制またはコストのかかるアクションに対する認可チェックのパターンは、Ansvar Systems ABによるregulatory-threat-modelをもとにしています。これはコミット22d8efa9e9afcf31b98b7e3952ec557694e72c13時点のdavila7/claude-code-templatesに含まれ、ライセンスはCC-BY-4.0です。2026-08-09に抽出されました。これは単一の情報源に基づくパターン（信頼度：中）であり、ベンダー固有かつプロプライエタリツールに限定されたスキルから抽出されています。広く裏付けられた慣例ではなく、検討に値する名称付きパターンとして扱ってください。

学びのループ

過去の判断や落とし穴が関係する場合は、learnings.consolidated.mdがあれば参照してください。必要な履歴を確認する場合、または利用可能な代替資料がない場合に限り、learnings.mdを使用してください。それ以外の場合は、どちらも参照しないでください。

適用後、記憶しておく価値のあるパターン、防止すべきミス、または意外に感じた分野の事実があれば、agents-skills-feedback-loop/scripts/append_learning.pyを使って、日付付きの箇条書きを1つlearnings.mdに追記してください。SKILL.md自体は変更しないでください。