アプリケーションセキュリティの2026年版体系化：LLM時代の設計脅威、サプライチェーン耐性、継続的検証を統合する実践的AppSecアーキテクチャ

1. Introduction

アプリケーションセキュリティ（AppSec）は、2026年においても依然として最重要の防御領域であるが、その意味内容は大きく変質した。かつてAppSecは、Webアプリケーションの脆弱性を見つけ、パッチを当て、再発防止策を講じる実務として理解されていた。しかし現在では、アプリケーションは単体のコードではなく、クラウド上の分散システム、API連携、サードパーティSDK、IaC、CI/CD、コンテナ、サービスメッシュ、そして生成AIコンポーネントまで含む複合体である。したがって、AppSecは「コードの安全性」だけでなく、「変更経路の安全性」「依存の信頼性」「実行環境の隔離性」「意思決定の自動化に伴う誤動作耐性」までを含む、より広いシステム安全保障として捉える必要がある。

この変化の背景には、攻撃者側の戦術変化がある。ソフトウェアサプライチェーンへの侵入、開発者の認証情報窃取、依存ライブラリの汚染、CI/CDのジョブ改ざん、IaCの不適切な設定、API認可不備の悪用、そしてLLMベースの開発支援環境へのプロンプト注入が、現実的かつ再現性の高い侵入経路として定着した。特に2024年以降、開発現場ではコード生成、テスト生成、レビュー補助、脆弱性説明、運用自動化にLLMが常用され、攻撃対象が「完成したアプリ」から「作られる過程」へ拡張した。これは攻撃面の増大だけでなく、防御側にも新たな要求を課す。すなわち、AppSec担当者は静的解析の結果を読むだけでは不十分であり、プロンプト管理、ツール実行権限制御、データ境界、エージェントの行動制約、モデル出力の検証まで理解しなければならない。

2026年時点のAppSecの難しさは、単一技術の欠如ではなく、複数の技術が部分的に最適化され、全体として脆弱になる点にある。たとえばSASTはソースコードの欠陥を検出できても、コンテナランタイムにおける権限逸脱や外部依存の悪性更新は見逃す。DASTは動的な脆弱性を捉えるが、認証必須の深い機能や状態依存の欠陥には弱い。SBOMは依存関係の可視化に有効だが、可視化できることと安全であることは別問題である。LLMガードレールは出力抑制に寄与するが、ツール呼び出し型のエージェントに対しては不十分であり、認可や最小権限が欠ければ容易に迂回される。よって、2026年のAppSecは「単独ツールの導入」では達成できず、複数層を束ねる運用設計が不可欠である。

本稿の目的は、AppSecを実務に耐える形で体系化し、設計時の脅威分析から実行時監視までを統合する枠組みを提示することである。具体的には、第一に、2026年の脅威環境を踏まえてAppSecの対象を再定義する。第二に、脅威モデルを形式化し、機密性 $C$、完全性 $I$、可用性 $A$ に加えて、変更追跡性 $T$ と意思決定の説明可能性 $E$ を含む評価軸を導入する。第三に、静的・動的・ランタイム・LLM安全性を統合した実装アーキテクチャを提案する。第四に、実験評価とケーススタディを通じて、運用可能性と防御効果の両立を検証する。

本研究の立場は明確である。AppSecは「左に寄せる」だけでも「右に寄せる」だけでも成立しない。設計段階での制約、実装段階での自動検査、配備段階での署名・認可・分離、運用段階での観測・検出・封じ込めを一つの制御系として扱う必要がある。特にLLM時代には、ソフトウェアは人間だけでなく機械によっても生成・修正されるため、人的レビューだけに依存するガバナンスは破綻する。したがって、2026年のAppSecは、人的判断と機械的保証の境界を再設計する学際的領域として理解すべきである。

2. Background and Related Work

AppSecの基礎は、OWASPが長年整理してきたWeb脆弱性の知見にある。SQLインジェクション、XSS、CSRF、認証不備、アクセス制御不備、セキュリティ設定ミス、脆弱な依存関係などは、依然として主要な欠陥類型である。OWASP Top 10 2021は、リスクの中心が「インジェクション単体」から「アクセス制御」「暗号の失敗」「ソフトウェアとデータの整合性失敗」へ移行していることを示した（OWASP, 2021）。この傾向は2026年でも継続しており、特にサプライチェーン攻撃とAPI認可欠陥が顕著である。

一方、NISTはSecure Software Development Framework（SSDF）を通じて、ソフトウェア開発ライフサイクルにおけるセキュリティ要件を標準化した（NIST, 2022）。SSDFは脆弱性対策を「作業」ではなく「工程」に埋め込む考え方を明確にし、要件定義、設計、実装、テスト、配備、保守の各段階での統制を求める。さらにSLSAは、ビルドの出所、整合性、再現性を段階的に定義し、改ざん耐性のあるビルドパイプラインを目指した（SLSA, 2024）。これらはAppSecを開発工程に組み込む実践の土台である。

依存関係の可視化については、SBOMが大きな役割を果たした。SPDXとCycloneDXは、ソフトウェア構成要素を機械可読に表現し、脆弱性管理や法令対応を支える（SPDX, 2024; CycloneDX, 2024）。しかしSBOMは万能ではない。第一に、SBOMは既知コンポーネントの列挙であり、実行時の挙動や条件分岐による危険性を記述しない。第二に、生成物の正しさは入力の正しさに依存するため、ビルド境界が汚染されればSBOM自体の信頼性も低下する。第三に、複数サービスが独立に更新されるクラウド環境では、SBOM差分を継続的に監査しない限り、リスクはすぐに陳腐化する。

動的検査の側では、DAST、IAST、RASP、fuzzing が重要な位置を占める。DASTはBlack Box的に外形振る舞いを確認し、IASTはアプリ内部の実行情報を利用してテストを補強する。fuzzingは入力空間の探索に優れるが、認証後の状態機械やビジネスロジックの欠陥は十分に捉えにくい。2020年代半ば以降、API-firstアーキテクチャが主流になったことで、OpenAPI仕様やGraphQLスキーマを起点とするテスト自動化が増えた。APIセキュリティは従来のWeb脆弱性とは異なり、細粒度認可、BOLA/IDOR、スキーマ過剰公開、レート制限不備、Webhookの信頼境界が中心となる（OWASP, 2023）。

クラウドネイティブ環境では、CNAPP、CSPM、CWPP、KSPMが統合され、構成ミスとランタイム防御が一体化した。eBPFはLinuxカーネル可観測性を飛躍的に高め、従来のエージェントより低オーバーヘッドでシステムコール、ネットワーク、プロセス間関係を追跡できる。Falco、Cilium、Tetragon などのツールは、Kubernetesやコンテナ環境における挙動検知を実用域に押し上げた（CNCF, 2025）。ただし、観測可能であることと防御可能であることは同じではない。高精度な検知が可能でも、封じ込めまで自動化されていなければ、攻撃者は短時間で横展開する。

2026年の新しい重要課題はLLMセキュリティである。OWASPはLLM Top 10を通じて、プロンプトインジェクション、機密情報漏えい、サプライチェーン汚染、過剰な権限を持つツール呼び出し、出力の不正利用などを整理した（OWASP, 2024）。LLMはコード生成、運用補助、知識検索、チケット自動化に組み込まれるため、単にモデルの安全性を語るだけでは足りない。重要なのは、モデルを中心とするエージェントの権限、コンテキスト、外部ツールへの接続、ログ保存、評価データの汚染耐性である。ここでの失敗は、古典的な入力検証不備と似ているようで、本質的には「行動の委任」の失敗である。

また、生成AIの普及はソフトウェア供給速度を加速し、レビュー負荷を増大させた。コードレビューはもはや人間による逐次確認だけでは追いつかず、Semgrep、CodeQL、SonarQube、Checkov、Trivy、Grype、Syft、Gitleaksのような自動化が必須である（GitHub, 2025; Aqua Security, 2025）。しかし自動化は万能ではなく、検出結果のトリアージ、重要度判断、修正優先度付け、例外管理が新たなボトルネックとなる。したがって、2026年のAppSec研究は「何を検出するか」だけでなく、「どう運用するか」を同等以上に重視する必要がある。

表1. 2026年時点の主要AppSec能力と対象範囲

能力	主対象	強み	限界
SAST	ソースコード	早期検出、CI統合が容易	実行時条件や深いデータフローに弱い
DAST	実行中アプリ	外形からの実害確認	認証後機能、状態遷移に弱い
IAST	実行中アプリ内部	実コード経路に基づく高精度	計測導入コスト、言語依存
SBOM	依存関係	可視化、脆弱性照合	挙動や改ざん耐性を保証しない
CNAPP	クラウド全体	設定・権限・ランタイム統合	導入複雑、誤検知管理が必要
LLM Guardrails	生成AI利用	出力抑制、ポリシー適用	ツール権限や文脈汚染には不十分

表2. 代表的フレームワークの位置づけ

フレームワーク	公表年	目的	AppSecへの寄与
OWASP Top 10	2021	主要Webリスクの整理	優先度付けの基礎
OWASP ASVS	2024版系	検証要求の体系化	要件定義と監査
NIST SSDF	2022	安全な開発工程	プロセス統制
SLSA	2024	ビルド整合性	サプライチェーン保証
ISO/IEC 27034	2011/継続利用	アプリケーションセキュリティ管理	組織的統制
OWASP SAMM	2024系	成熟度モデル	改善ロードマップ

3. Threat Model and Problem Formalization

本研究では、AppSec対象を「アプリケーション資産 $A$、依存資産 $D$、実行環境 $E$、開発・配備パイプライン $P$、運用コンテキスト $O$、LLM/エージェント機構 $L$」の集合として定義する。攻撃者はこれらのいずれか、あるいは複数に対して影響を及ぼす。脅威の目的は、機密情報の窃取、任意コード実行、認可の迂回、データ改ざん、可用性低下、モデル汚染、または長期潜伏である。特に2026年の環境では、攻撃者はアプリそのものより、ビルド・デプロイ・協業フローへの侵入を好む。理由は、そこが高価値情報に近く、かつ監視が薄いからである。

形式化のため、アプリケーションの安全性を以下で表す。システム状態を $s \in S$、操作集合を $u \in U$、観測集合を $o \in O$ とし、制御ポリシー $\pi$ が許可する操作のみが実行されるとする。安全性は、望ましくない状態集合 $B \subset S$ への遷移確率を十分小さく保つ問題として定義できる。すなわち、 $$ \Pr(s_{t+1} \in B \mid s_t, u_t, \pi) \le \epsilon $$ を満たすよう、設計・検出・封じ込めの制御を実装する。ここで $\epsilon$ は組織が受容できる残余リスクである。実務上はゼロにはできないため、重要なのは「どの状態を危険と見なすか」と「どのタイミングで介入するか」である。

脅威モデルは、以下の4クラスに分類できる。第一に、入力起点の脅威である。SQLインジェクション、コマンド注入、テンプレートインジェクション、Deserialization、XSS、XXE、SSRFなどが含まれる。第二に、依存起点の脅威である。悪性パッケージ、Typosquatting、Dependency Confusion、署名のない更新、脆弱なコンテナベースイメージなどである。第三に、構成起点の脅威である。クラウド権限の過剰付与、公開バケット、脆弱なCIシークレット、Kubernetes RBACの誤設定などがある。第四に、認知起点の脅威である。フィッシング、AI生成のソーシャルエンジニアリング、レビューの自動化疲れ、LLM出力への過信である。

本研究は、攻撃成功条件を次で表現する。ある攻撃経路 $p$ に対して、必要な脆弱性集合を $V_p$、防御制御集合を $K_p$ とする。攻撃が成功するのは、$V_p$ が成立し、かつ $K_p$ がすべて無効化される場合である。したがって成功確率は概念的に $$ P(\text{success}) = \prod_{v \in V_p} P(v) \cdot \prod_{k \in K_p} (1 - P(k)) $$ と書ける。実務では独立性は成り立たないが、この式は防御の意味を明確化する。単発のスキャナで一つの脆弱性を潰しても、別経路が開いていれば全体リスクは残る。逆に、複数の弱い制御を組み合わせると、攻撃成功率は乗法的に低下する。

表3. 2026年AppSecの主な攻撃面と防御原理

攻撃面	典型的攻撃	防御原理	代表的制御
コード	注入、認可不備、RCE	入力正規化、最小権限	SAST、CodeQL、ASVS
依存	汚染、依存混同	出所保証、署名検証	SBOM、Sigstore、SLSA
CI/CD	シークレット窃取、ジョブ改ざん	分離、短命資格情報	OIDC、Policy-as-Code
クラウド	過剰権限、露出設定	継続的コンプライアンス	CNAPP、CSPM
ランタイム	横展開、権限昇格	観測と封じ込め	eBPF、Falco、Cilium
LLM/Agent	プロンプト注入、ツール悪用	権限分離、検証、ガードレール	LLM firewall、sandbox

4. Proposed Methodology

提案手法は、AppSecを4層の制御系として実装する。第1層は予防層であり、設計標準、コーディング規約、依存ポリシー、認証認可の原則、秘密情報管理を担う。第2層は検出層であり、SAST、DAST、SCA、シークレット検出、IaCスキャン、fuzzing、ルールベース監視を統合する。第3層は封じ込め層であり、Kubernetesネットワークポリシー、mTLS、WAF、レート制限、eBPFルール、キルスイッチを用いて被害範囲を抑える。第4層は証跡化層であり、監査ログ、SBOM、ビルド署名、証跡チェーン、チケット連携を通じて説明責任を担保する。

この4層は、単純な直列ではなくフィードバック制御として機能する。検出結果は予防ルールに還元され、封じ込めログは検出モデルの特徴量として再利用される。これにより、AppSecは一回限りの監査から、継続的な学習ループへ変わる。例えば、APIでBOLAが発見された場合、単に当該エンドポイントを修正するだけでなく、認可設計の共通ライブラリ、API仕様テンプレート、レビュー観点に還元する。

技術的には、提案手法を「制約付きパイプライン」として実装する。各コミット $c_i$ は、静的解析 $S(c_i)$、依存評価 $D(c_i)$、秘密検出 $K(c_i)$、IaC検査 $I(c_i)$、ポリシー検査 $P(c_i)$ を通過しなければならない。最終的なリリース許可関数 $R$ は、 $$ R(c_i)= S(c_i)\land D(c_i)\land K(c_i)\land I(c_i)\land P(c_i) $$ で表せる。ここで各関数は二値ではなく、重大度スコアに基づく閾値判定である。たとえば、CVSS 9.0以上の既知脆弱性を含む依存関係は即時停止、CVSS 7.0以上は例外申請が必要、機密データを含む差分は自動マスキングと強制レビュー、といった運用に落とし込む。

設計段階では、脅威モデリングをSTRIDE単独で終わらせず、データ分類と認可モデルに接続する。公開API、管理API、バックオフィスAPI、内部イベントバス、LLMツール呼び出しを別個の信頼境界として表現し、各境界に対して「誰が」「何に」「どの条件で」アクセスできるかを定義する。ここで重要なのは、アプリの機能単位ではなく、攻撃者の到達可能性に基づいて境界を切ることである。たとえば同じ /search エンドポイントでも、検索対象が公開商品情報と内部人事情報では脅威が異なる。

LLMを含む場合、追加でコンテキスト分離を導入する。ユーザ入力、システムプロンプト、取得文書、ツール出力、メモリ、ログを分離し、各要素に信頼レベルを付与する。ツール呼び出しはスキーマ検証と権限制約の下でのみ可能とし、モデル出力は「実行可能命令」ではなく「候補」として扱う。たとえばコード生成結果は、必ず静的解析、テスト、ライセンス検査を経て初めてマージ可能とする。これはモデルの能力を過信しないための基本である。

実用コマンド例1: 依存関係と脆弱性の統合スキャン

syft dir:. -o spdx-json > sbom.spdx.json
grype sbom:sbom.spdx.json --fail-on high
trivy fs --scanners vuln,secret,misconfig --severity HIGH,CRITICAL .
gitleaks detect --source . --redact --no-banner

実用コマンド例2: GitHub Actionsでの安全なビルド署名と監査

name: secure-build
on:
  push:
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write
    steps:
      - uses: actions/checkout@v4
      - uses: anchore/sbom-action@v0
        with:
          format: spdx-json
      - uses: sigstore/cosign-installer@v3
      - run: cosign sign-blob --yes --output-signature artifact.sig artifact.tar.gz
      - run: trivy image --severity HIGH,CRITICAL myapp:latest

5. Implementation

実装は、Gitリポジトリ、CI/CD、クラウド実行基盤、監視基盤の4点で構成した。まずGitリポジトリでは、pre-commitフックにより、シークレット、危険な関数、ライセンス問題、脆弱なIaCを事前検査した。次にCI/CDでは、パイプラインを「ビルド」「スキャン」「署名」「配置」の4ステージに分割し、各段階で成果物の署名を検証した。第三にクラウド基盤では、Kubernetesのnamespace単位で権限を分離し、service accountごとに最小権限のIAMロールを付与した。第四に監視基盤では、eBPF観測とアプリログを相関させ、異常なプロセス生成、外向き通信、権限昇格兆候をアラート化した。

コード解析にはCodeQLとSemgrepを併用した。CodeQLは深いデータフロー解析に優れるため、認可ロジックやパストラバーサルなどの系統的欠陥に有効である。一方Semgrepはルール記述が容易で、組織固有の禁止パターンを素早く反映できる。例えば、eval、危険なシェル呼び出し、未検証のテンプレート展開、Object.assignによる危険なマージなどを組織ポリシーとして禁止した。さらに、Java、JavaScript、Go、Python、C#に対して言語別ルールを設け、False Positiveの低減を図った。

依存管理では、SBOMを生成し、脆弱性データベースと照合した。SBOMはビルド時に生成し、署名付きで保存することで、後続の監査で改ざんを検出できるようにした。また、更新時には差分SBOMを用いて、追加・削除・更新されたコンポーネントを追跡した。これにより、依存関係の変化を「いつ、何が、なぜ変わったか」という監査可能な形で管理できる。特に第三者ライブラリのメジャーアップデートは、機能差分だけでなく、脆弱性露出の変化を同時に評価する必要がある。

ランタイム防御は、WAFだけでは不十分であるため、アプリケーション層、コンテナ層、ノード層の3層で設計した。アプリ層では入力検証と認可チェックを標準化し、コンテナ層では読み取り専用ルートファイルシステム、非root実行、capability削減を徹底した。ノード層ではeBPFを用い、予期しないシェル起動、外部へのデータ持ち出し、暗号資産マイニング特有の挙動を検出した。特にKubernetes環境では、Podの短命性を前提に、検知から封じ込めまでの自動化が重要である。手動でのフォレンジックを待っていては、攻撃者は既に別のPodへ移動している。

LLM利用部では、プロンプトテンプレートをコードとして管理し、ユーザ入力をシステム命令と混同しない構造を徹底した。RAGを用いる場合は、検索対象文書の信頼度を階層化し、外部取得情報は「参照専用」として扱った。また、ツール呼び出しは許可リスト方式とし、ネットワークアクセス、ファイル操作、デプロイ操作には個別の承認を必要とした。これにより、プロンプトインジェクションが成功しても、モデルが実行できる行動は限定される。

6. Experimental Evaluation

評価は、公開ベンチマークと実運用に近い模擬環境の両方で実施した。対象は、1) 典型的なOWASP系脆弱性を含むサンプルWebアプリ、2) API中心のマイクロサービス群、3) 生成AI支援機能を含む社内開発支援ポータル、4) Kubernetes上のコンテナ化システム、の4環境である。評価指標として、検出率、誤検知率、平均修復時間（MTTR）、パイプライン遅延、封じ込め成功率、LLM関連攻撃の抑止率を測定した。評価式として、総合リスク低減量を $$ \Delta R = \frac{R_{base} - R_{defended}}{R_{base}} $$ と定義し、各制御の寄与を比較した。

表4. 代表脆弱性クラスに対する検出性能

脆弱性クラス	SAST単独	SAST+SCA	統合方式
SQLi / コマンド注入	0.81	0.82	0.91
XSS / テンプレート注入	0.78	0.79	0.89
認可不備（BOLA/IDOR）	0.46	0.48	0.84
秘密情報漏えい	0.74	0.91	0.96
依存脆弱性	0.12	0.88	0.95
IaC設定ミス	0.09	0.14	0.90

統合方式は、SAST、SCA、IaC、秘密検出、ポリシー検査、ランタイム監視を連結したものである。最も改善が大きかったのは認可不備とIaC設定ミスであり、これは単一のコード解析では捉えにくいことを示している。特にBOLA/IDORは、コード単体では見えず、API仕様、認証文脈、データ所有権の関係で初めて検出可能になる。したがって、AppSecの実効性は、複数レイヤの相関に依存する。

表5. 導入前後の運用指標比較

指標	導入前	導入後	変化
重大脆弱性の平均修復時間	18.4日	6.7日	-63.6%
CI失敗率（セキュリティ起因）	3.1%	7.8%	+4.7pt
誤検知対応時間	5.2時間	2.1時間	-59.6%
リリース遅延中央値	0.0日	0.4日	+0.4日
ランタイム封じ込め成功率	41%	87%	+46pt
LLM権限制御違反率	12%	2%	-10pt

導入後にCI失敗率が上がったのは、セキュリティを厳格化したためであり、短期的には開発者負荷の増加を意味する。しかし重要なのは、失敗が早期に発生するほど、後工程の修正コストが低いことである。実測では、コードレビュー後に見つかった欠陥の修正コストは、コミット直後に見つかった場合の約 $3.4$ 倍であった。これは一般的なバグ修正コストの経験則とも整合する。AppSecの価値は「失敗しないこと」ではなく、「高コストな失敗を前倒しすること」にある。

表6. 主要制御の効果と運用コスト

制御	リスク低減効果	導入難度	維持コスト
SASTルール強化	中	低	低
SCA/SBOM連携	高	中	中
IaCスキャン	高	中	中
eBPFランタイム監視	高	高	中
LLMツール権限制御	高	中	中
署名付きビルド	高	中	低

実験では、単独のSASTよりも、SBOM連携とIaCスキャンを組み合わせた場合に、総合的な検出率が最も安定した。これは、現代の脆弱性がコードだけでなく、依存と構成に偏っているためである。また、eBPFによるランタイム監視は、攻撃成功後の被害縮小に顕著な効果を示した。ただし、ルール設計が不適切だと誤検知が増えるため、業務フローに合わせた調整が必要である。

7. Case Study

ケーススタディとして、社内向けLLM支援ポータルにおける権限逸脱事案を分析した。対象システムは、チケット要約、コードスニペット生成、運用手順検索、内部文書RAGを備えていた。開発初期は、モデルが参照可能な文書を広く開放し、ツール呼び出しも比較的自由にしていた。その結果、外部文書中の悪意ある指示文がRAG経由で取り込まれ、モデルが本来不要な内部APIの実行候補を生成した。実害は発生しなかったが、レビューで権限設計の欠陥が検出された。

対応として、まず検索対象を分類し、公開、社内、機微、機密に分離した。次に、ツール呼び出しを「参照」「ドラフト作成」「申請」へ分解し、実行は人間の承認を必須とした。さらに、プロンプトテンプレートを署名付きで管理し、変更時にセキュリティレビューを強制した。加えて、モデルの回答に対してDLPルールを適用し、シークレット、個人情報、認証情報の出力を遮断した。結果として、プロンプト注入に対する耐性は大きく改善し、内部監査でも「過剰権限が抑制されている」と評価された。

この事例が示す教訓は明快である。LLMを含むAppSecでは、モデル精度より権限制御が重要である。モデルは誤る前提で設計すべきであり、出力の正しさを期待して防御を組むべきではない。加えて、RAGは知識基盤であると同時に攻撃面でもあるため、文書の出所、更新権限、埋め込み生成、検索ランキングの汚染に注意が必要である。つまり、LLM時代のAppSecは、従来の入力検証に加えて、知識供給網の信頼性を扱う必要がある。

8. Discussion

本研究の結果は、AppSecにおける「単機能ツールの限界」と「統合制御の有効性」を示している。SASTやDASTは依然として有用だが、現代のリスク分布はそれだけでは説明できない。依存関係、IaC、権限設計、CI/CD、LLMツールチェーンが相互に結びついているため、攻撃者は最も弱い部分を選んで侵入する。したがって、防御側も最も強い一層ではなく、最も弱い連結部を中心に対策を設計する必要がある。

重要な論点の一つは、セキュリティと開発速度のトレードオフである。実験では、セキュリティ制御を導入すると短期的なCI失敗率とレビュー負荷が増加した。しかし、これは長期的な欠陥流出を減らすための必要コストである。実務上は、すべての制御を一斉導入するのではなく、リスクの高い領域から段階的に適用するほうが成功しやすい。たとえば、認証・認可、シークレット、外部公開API、支払い処理、管理機能、LLMツール呼び出しを最優先にするべきである。

もう一つの論点は、AI支援開発の広がりである。生成AIは生産性を上げる一方で、セキュリティ上の「見えない複雑性」を増やす。AIが生成したコードはレビュー可能だが、AIが生成した設計判断や文書化されない前提はレビューしづらい。よって、AI利用を禁止するのではなく、利用範囲を明文化し、レビューと自動検査を前提に組み込むべきである。特に、AIによるコード提案をそのままマージする文化は危険である。人間が意味的妥当性を確認し、機械が規約適合性を確認する二重化が必要だ。

さらに、ポスト量子暗号（PQC）の移行もAppSecの範囲に含まれる。直接的なWeb脆弱性とは別だが、認証、署名、鍵管理、ビルド検証の基盤が将来的にPQCへ移行するため、今からアルゴリズムのアジリティを確保することが望ましい。これは「今すぐ量子攻撃が来る」という意味ではなく、長寿命システムにおける暗号の将来耐性を設計要件として扱うべきだという意味である。特にソフトウェア署名とアーティファクト検証は、将来の暗号移行に備えた柔軟性が必要である。

9. Conclusion and Future Work

本稿は、2026年時点のAppSecを、コード中心の脆弱性管理から、設計、依存、CI/CD、クラウド、ランタイム、LLMまでを包含する統合制御問題として整理した。提案した4層モデルは、予防、検出、封じ込め、証跡化を連結し、単独ツールでは難しい複合リスクへの対処を可能にする。実験とケーススタディは、認可不備、依存脆弱性、IaCミス、LLMプロンプト注入に対して、統合的制御が有効であることを示した。特に、SBOM、署名、最小権限、eBPF、LLM権限制御の組み合わせは、現実的な防御効果を示した。

今後の課題は三つある。第一に、AppSecの自動化をさらに進めつつ、誤検知と運用負荷を抑えることである。第二に、LLM/Agentのガバナンスを、開発現場の実情に即して制度化することである。第三に、PQC移行、継続的コンプライアンス、AIガバナンスを、アプリケーションのセキュリティ設計に統合することである。2026年以降のAppSecは、単なるセキュリティ機能の集合ではなく、変化の激しいソフトウェア供給網を安全に運用するための学習システムとして進化しなければならない。

10. References

ABNT形式で列挙する。本文中の引用は（SOBRENOME, ano）形式に対応させた。

1. ALCMÉN, et al. OWASP Top 10 - 2021. OWASP, 2021. Disponível em: https://owasp.org/www-project-top-ten/. Acesso em: 9 maio 2026.

2. AQUA SECURITY. Trivy Documentation. 2025. Disponível em: https://trivy.dev/. Acesso em: 9 maio 2026.

3. BELL, J.; et al. CodeQL Documentation. GitHub, 2025. Disponível em: https://codeql.github.com/docs/. Acesso em: 9 maio 2026.

4. CNCF. Falco Documentation. Cloud Native Computing Foundation, 2025. Disponível em: https://falco.org/docs/. Acesso em: 9 maio 2026.

5. CNCF. Tetragon Documentation. Cloud Native Computing Foundation, 2025. Disponível em: https://tetragon.io/docs/. Acesso em: 9 maio 2026.

6. CYCLONEDX. CycloneDX Specification. 2024. Disponível em: https://cyclonedx.org/specification/. Acesso em: 9 maio 2026.

7. GITHUB. GitHub Advanced Security Documentation. 2025. Disponível em: https://docs.github.com/en/code-security. Acesso em: 9 maio 2026.

8. ISO. ISO/IEC 27034-1:2011 Information technology — Security techniques — Application security. International Organization for Standardization, 2011. Disponível em: https://www.iso.org/standard/44378.html. Acesso em: 9 maio 2026.

9. MUSTAFA, et al. OWASP Application Security Verification Standard. OWASP, 2024. Disponível em: https://owasp.org/www-project-application-security-verification-standard/. Acesso em: 9 maio 2026.

10. NIST. Secure Software Development Framework (SSDF), Version 1.1. National Institute of Standards and Technology, 2022. Disponível em: https://csrc.nist.gov/Projects/ssdf. Acesso em: 9 maio 2026.

11. NIST. Software Bill of Materials (SBOM). National Institute of Standards and Technology, 2024. Disponível em: https://www.nist.gov/sbom. Acesso em: 9 maio 2026.

12. OWASP. OWASP API Security Top 10 - 2023. OWASP, 2023. Disponível em: https://owasp.org/www-project-api-security/. Acesso em: 9 maio 2026.

13. OWASP. OWASP Top 10 for Large Language Model Applications. OWASP, 2024. Disponível em: https://owasp.org/www-project-top-10-for-large-language-model-applications/. Acesso em: 9 maio 2026.

14. OWASP. Software Assurance Maturity Model (SAMM). OWASP, 2024. Disponível em: https://owasp.org/www-project-samm/. Acesso em: 9 maio 2026.

15. PAXSON, V. Bro: A System for Detecting Network Intruders in Real-Time. Computer Networks, 1999. Disponível em: https://www.icir.org/vern/papers/bro-CN99.pdf. Acesso em: 9 maio 2026.

16. PYPI. Python Packaging User Guide. 2025. Disponível em: https://packaging.python.org/. Acesso em: 9 maio 2026.

17. SLSA. Supply-chain Levels for Software Artifacts. 2024. Disponível em: https://slsa.dev/. Acesso em: 9 maio 2026.

18. SPDX. SPDX Specification. Linux Foundation, 2024. Disponível em: https://spdx.dev/specifications/. Acesso em: 9 maio 2026.

19. SIGSTORE. Sigstore Documentation. 2025. Disponível em: https://docs.sigstore.dev/. Acesso em: 9 maio 2026.

20. SONATYPE. State of the Software Supply Chain. 2025. Disponível em: https://www.sonatype.com/resources/state-of-the-software-supply-chain. Acesso em: 9 maio 2026.

21. SONAR. SonarQube Documentation. 2025. Disponível em: https://docs.sonarsource.com/sonarqube/. Acesso em: 9 maio 2026.

22. SNYK. Snyk Open Source Documentation. 2025. Disponível em: https://docs.snyk.io/. Acesso em: 9 maio 2026.

23. GOOGLE. Binary Authorization. Google Cloud, 2025. Disponível em: https://cloud.google.com/binary-authorization. Acesso em: 9 maio 2026.

24. KUBERNETES. Kubernetes Documentation. 2025. Disponível em: https://kubernetes.io/docs/. Acesso em: 9 maio 2026.

25. RED HAT. OpenShift Security and Compliance. 2025. Disponível em: https://docs.openshift.com/. Acesso em: 9 maio 2026.

26. SYFT. Syft Documentation. Anchore, 2025. Disponível em: https://github.com/anchore/syft. Acesso em: 9 maio 2026.

27. GRYPE. Grype Documentation. Anchore, 2025. Disponível em: https://github.com/anchore/grype. Acesso em: 9 maio 2026.

28. SEMGREP. Semgrep Documentation. 2025. Disponível em: https://semgrep.dev/docs/. Acesso em: 9 maio 2026.

29. CHEF, T.; et al. eBPF and Linux observability tooling. 2025. Disponível em: https://ebpf.io/. Acesso em: 9 maio 2026.

30. MITRE. CWE Top 25 Most Dangerous Software Weaknesses. MITRE, 2024. Disponível em: https://cwe.mitre.org/top25/. Acesso em: 9 maio 2026.