Paper Files / AppSec
2026年のAppSec再設計：AI支援開発、サプライチェーン、クラウドネイティブ環境におけるアプリケーションセキュリティの統合的防御モデル
2026年のアプリケーションセキュリティ（AppSec）は、従来の脆弱性スキャン中心の運用から、開発ライフサイクル、サプライチェーン、ランタイム、ガバナンスを一体化した継続的制御へと明確に移行している。本論文は、AI支援開発、クラウドネイティブ実行基盤、API中心アーキテクチャ、OSS依存の肥大化、そして生成AIを悪用したソーシャルエンジニアリングという2026年特有の脅威環境を前提に、AppSecの実務上の課題を定式化し、現実的な統合防御モデルを提案する。提案手法は、静的解析、依存関係解析、ソフトウェア部品表（SBOM）、秘密情報検出、IaC検査、コンテナ・Kubernetesセキュリティ、動的テスト、ランタイム観測を、リスクベースの制御面で統合するものである。さらに、LLMを用いた安全でないコード提案、プロンプト注入、依存パッケージ汚染、CI/CDの認証情報漏えい、クラウド資格情報の横展開といった複合攻撃を対象に、検出率、誤検知率、平均修正時間、リリース阻害率を同時に最適化する評価枠組みを提示する。実装面では、Semgrep、CodeQL、Gitleaks、Syft、Grype、Trivy、OWASP ZAP、kube-bench、Falco、Open Policy Agentを組み合わせた現実的な参照アーキテクチャを示し、CI/CDパイプラインへの組み込み方法を具体化する。評価では、Python、JavaScript、Go、Javaの複数リポジトリを対象に、脆弱性検出、秘密情報発見、サプライチェーン透明化、ランタイム異常検知の性能を比較し、単独ツール運用に対する統合運用の優位性を示す。最後に、AIガバナンス、ポスト量子暗号移行、eBPFベース可視化、CNAPPとの連携を含む2026年以降の研究課題を整理する。本研究は、AppSecを「検査の集合」ではなく「継続的なセキュリティ制御システム」として再定義し、実務適用可能な形で提示する。
1. Introduction
アプリケーションセキュリティ（AppSec）は、2026年時点で最も再設計を迫られているセキュリティ領域の一つである。理由は単純ではない。第一に、ソフトウェア開発の主体が人間単独ではなく、AI支援IDE、コード補完、テスト生成、リファクタリング提案を含む複合的な生成支援環境へ移行したことで、脆弱性の混入経路が増えた。第二に、アプリケーションの実行基盤がオンプレミス中心から、Kubernetes、マイクロサービス、API Gateway、マネージドDB、Serverless、SaaS連携を含む分散構成へ拡大し、境界防御の前提が崩れた。第三に、ソフトウェアサプライチェーンの攻撃が、依存パッケージ、ビルドシステム、CI/CD、コンテナイメージ、IaC、そして署名・検証の各段階を狙うようになり、単一の静的解析や脆弱性スキャナでは対応しきれなくなった。第四に、2026年には生成AIを用いたフィッシング、ビッシング、内部者詐称、コードレビュー偽装が高度化し、AppSecは純粋なコード品質問題ではなく、認証、権限管理、ガバナンス、教育を含む業務統制へと拡張されている（NIST, 2024; ENISA, 2024）。
この文脈で重要なのは、AppSecを「脆弱性を見つけて修正する活動」としてのみ捉えると、現代の脅威に対して構造的に後手に回る点である。たとえば、CWE-79のような入力検証不備やCWE-89のSQLインジェクションは今なお重要だが、実際の重大インシデントは、それら単独よりも、認証情報漏えい、権限昇格、依存ライブラリ改ざん、クラウド権限の誤設定、秘密鍵のCIログ流出など複数要因の連鎖として発生する。実務では、開発速度を維持しつつ、検出・抑止・修復・監査の全てを工程に組み込む必要がある。したがって2026年のAppSecは、ツール導入の問題ではなく、制御設計の問題である。
本論文の目的は、2026年の実環境に適合するAppSecの統合モデルを提案し、開発組織が実装可能な参照構成として提示することにある。提案の中心は、$R = f(T, S, E, O)$ というリスク関数である。ここで $T$ は脅威インテリジェンス、$S$ はソフトウェア構成要素の重要度、$E$ は曝露面、$O$ は運用成熟度を表す。単なる脆弱性件数ではなく、業務インパクトと露出条件を組み合わせて優先順位を付けることで、修正の経済性を高める。これは、全件修正を前提とする理想論を退け、限られた人員で最大のリスク低減を図る現実的なアプローチである。
本研究はまた、AI支援開発がもたらす新種のAppSec問題を正面から扱う。生成AIは生産性を向上させる一方、過去コードの不適切な模倣、認可境界の欠落、危険なデフォルト設定、秘密情報の再生成、脆弱なサンプルの再利用を誘発する。さらに、LLMに対するプロンプト注入やコンテキスト汚染は、単にアプリケーションの出力にとどまらず、コード生成、テスト生成、セキュリティチケット自動化にも影響する。そのため、AppSecはアプリケーション本体だけでなく、開発支援システム自体の安全性も監査対象に含めなければならない。
2. Background and Related Work
AppSecの研究史は、脆弱性検出技術の進化と開発パラダイムの変化に強く依存している。初期のWebセキュリティ研究は、入力検証、セッション管理、認可不備を中心に進展したが、2000年代後半には動的解析、ペネトレーションテスト、Webアプリケーションファイアウォールが普及した。2010年代には、OWASP Top 10が業界共通言語として機能し、SAST、DAST、IAST、RASPの概念が整理された（OWASP, 2021）。しかし、当時の前提は比較的単純であり、アプリケーションは単一の境界内に存在し、依存関係も限定的で、デプロイ頻度も今ほど高くなかった。
その後、DevOps、Infrastructure as Code、コンテナ、Kubernetes、マイクロサービスが主流となり、AppSecはビルド前、ビルド時、デプロイ時、ランタイムの全段階に拡張された。NISTはソフトウェアサプライチェーンのリスクを重要課題と位置づけ、SBOM、署名、来歴証明、依存管理、CI/CDの保護を強く推奨した（NIST, 2022）。SLSAやSigstoreは、ソフトウェアの生成・署名・配布の信頼性向上に寄与したが、実運用では依存関係の爆発、複数レジストリの混在、例外運用、レガシー資産の残存が障壁となった。つまり、技術的に可能であることと、組織的に定着することの間には大きな隔たりがある。
一方で、脆弱性の検出技術そのものも成熟した。CodeQLは大規模コードベースに対するデータフロー解析を実用化し、Semgrepはルールベースの迅速な導入性を提供した。GitleaksやTruffleHogは秘密情報検出を標準化し、SyftとGrype、TrivyはSBOMと脆弱性評価を日常的なCIタスクに変えた。Kubernetes環境ではkube-bench、kube-score、Falco、OPA Gatekeeper、Kyvernoが、設定不備とランタイム異常の検出に利用されている（Aqua Security, 2025; Sysdig, 2025）。これらのツールは個別には有効だが、相互の検出結果を統合し、業務リスクに変換する仕組みが不足しがちである。
近年の研究では、AI支援開発の安全性も注目されている。LLMはコード補完の質を向上させるが、既存の脆弱性パターンを学習しているため、認証・認可、暗号化、入力検証、エラーハンドリングにおいて危険な提案を返すことがある。さらに、プロンプト注入により、外部入力が開発支援システムに流入した場合、意図しないコード修正や機密情報の抽出が発生しうる。2026年のAppSecでは、開発ツールの安全性も対象化し、AI利用ポリシー、秘密情報マスキング、モデル出力のレビュー基準、サンドボックス化された補助エージェントを導入する必要がある。
表1は、主要AppSec領域と代表的制御を整理したものである。単独制御は有効だが、攻撃者は常に境界の外側を選ぶため、多層防御が必須である。
| 領域 | 主要リスク | 代表的制御 | 典型的ツール |
|---|---|---|---|
| ソースコード | 注入、認可不備、危険なデシリアライズ | SAST、コードレビュー、セキュア設計 | CodeQL、Semgrep |
| 依存関係 | 既知CVE、typosquatting、依存汚染 | SCA、SBOM、ピン留め | Syft、Grype、Trivy |
| 秘密情報 | APIキー、トークン、証明書漏えい | Secret Scanning、pre-commit | Gitleaks、TruffleHog |
| CI/CD | ビルド改ざん、権限濫用 | 署名、最小権限、監査 | Sigstore、OPA |
| 実行環境 | コンテナ脱出、横展開、異常挙動 | Runtime Detection、Policy | Falco、Kyverno、eBPF |
| API/外部連携 | 認証・認可不備、BOLA | API Security、契約テスト | ZAP、Postman |
研究文献のもう一つの重要な流れは、セキュリティを「後付け」ではなく「設計時制約」として扱う考え方である。NIST Secure Software Development Framework（SSDF）は、設計、開発、テスト、リリース、運用の各段階での実装責任を明確化した（NIST, 2022）。同様に、OWASP SAMMは成熟度ベースで組織の改善を支援し、BSIMMは実際の企業活動を観測することでベストプラクティスを抽出した。2026年時点では、これらのフレームワークはもはや競合ではなく補完関係にある。AppSec組織は、SSDFで最低限の統制を定め、SAMMで成熟度を追跡し、BSIMMで他社比較を行うという重層的な運用が現実的である。
3. Threat Model and Problem Formalization
本研究の脅威モデルは、外部攻撃者、サプライチェーン侵害者、内部不正、そして誤設定を含む非意図的リスクを同時に扱う。攻撃者は、高度な脆弱性悪用だけでなく、開発者の認証情報、CI/CD権限、依存パッケージの公開権限、クラウドロール、Webhook、Artifact Repositoryへのアクセスを狙う。特に2026年では、生成AIを利用したフィッシングが自然言語の質で本物の社内連絡と区別しづらくなり、開発者のワークフローにおけるソーシャルエンジニアリングが急増している。したがって、AppSecの脅威モデルはコード欠陥だけでなく、人間の操作ミスと自動化基盤の誤用を含める必要がある。
形式化のため、対象システムを $A = (C, D, P, R, L)$ とする。ここで $C$ はコード、$D$ は依存関係、$P$ はパイプライン、$R$ はランタイム、$L$ はログ・監査証跡である。攻撃面の集合を $X = X_C \cup X_D \cup X_P \cup X_R \cup X_L$ とし、各攻撃ベクトル $x \in X$ に対して、成功確率 $p(x)$、期待被害 $I(x)$、検出遅延 $d(x)$ を定義する。総合リスクは次式で表される。
$$ \mathcal{R}(A) = \sum_{x \in X} p(x) \cdot I(x) \cdot e^{-\lambda d(x)} $$
ここで $\lambda$ は検出遅延に対する感度である。すなわち、検出が遅れるほど実害が指数関数的に増加するという現実をモデル化している。この定式化の利点は、脆弱性件数そのものではなく、到達可能性、権限、露出、修復速度を同時に扱える点にある。実務上、CVEの深刻度が高くても、外部到達不能かつ認可境界で遮断されていれば優先度は下がる。一方、深刻度が中程度でも、CIトークンや本番データベース資格情報が関与する場合は優先順位が跳ね上がる。
本研究では、検出精度を $P$、再現率を $R$、F1スコアを $F_1$ として、以下のように評価する。
$$ F_1 = \frac{2PR}{P+R} $$
しかしAppSecではF1単独では不十分である。実務影響を反映するため、修正工数 $M$、誤検知対応工数 $F$、リリース遅延 $L$ を加味した運用コストを
$$ \mathcal{C} = \alpha M + \beta F + \gamma L $$
と定義する。目的は $\mathcal{R}$ の最小化だけでなく、$\mathcal{C}$ を制約付きで最小化することにある。言い換えれば、AppSecは最適化問題であり、検出率と開発速度のトレードオフを設計しなければならない。
表2は、脅威カテゴリごとの優先度評価の考え方を整理したものである。
| 脅威カテゴリ | 例 | 主な損害 | 優先度判定要因 |
|---|---|---|---|
| コード欠陥 | SQLi、XSS、RCE | 情報漏えい、任意コード実行 | 到達可能性、認可境界 |
| 依存関係汚染 | 悪性パッケージ、CVE依存 | サプライチェーン侵害 | 署名、固定化、採用率 |
| 秘密情報漏えい | APIキー、JWT、SSH鍵 | 横展開、クラウド侵害 | 権限範囲、有効期限 |
| CI/CD侵害 | ビルド改ざん、Runner侵害 | 配布物汚染 | 権限分離、監査 |
| ランタイム侵害 | コンテナ脱出、権限昇格 | 横展開、持続化 | 特権設定、eBPF検知 |
| AI支援開発悪用 | プロンプト注入、毒入りコンテキスト | 脆弱コード生成、漏えい | ツール連携、レビュー有無 |
4. Proposed Methodology
提案する方法論は、AppSecを5層の制御面として再構成するものである。第1層は設計時制御であり、脅威モデリング、セキュアコーディング規約、認証・認可パターン、暗号利用規則を定義する。第2層はビルド時制御であり、SAST、SCA、Secret Scanning、IaCスキャン、SBOM生成、署名検証を含む。第3層はデプロイ時制御であり、ポリシーエンジンによるAdmission Control、イメージ署名確認、最小権限適用を担う。第4層はランタイム制御であり、eBPFやカーネル観測を用いた異常検知、ネットワーク政策、ファイル操作監視を行う。第5層は運用時制御であり、ログ相関、脆弱性トリアージ、修正SLO、例外承認を管理する。
この方法論の要点は、各制御を単独で導入するのではなく、共通のリスクオントロジーで連結することである。たとえば、CodeQLで検出されたSQLインジェクション候補は、ZAPの動的検査結果、実際の攻撃面、認証要件、API公開範囲と結合される。Syftで生成したSBOMは、Grypeの脆弱性データと照合され、さらに本番環境の露出情報と結びつく。Gitleaksで検出された秘密情報は、発見時点だけでなく、権限スコープ、ローテーション状況、使用履歴を参照して緊急度を決める。この統合により、全てのアラートを同一の深刻度で扱う従来の欠点を回避する。
本研究では、制御選択をリスク適応型にする。具体的には、脅威スコア $s_i$ と制御コスト $c_j$ に対して、適用可能な制御集合 $K$ を以下の最適化で選ぶ。
$$ \min_{K \subseteq {1,\dots,n}} \sum_{i}(1-d_i(K))s_i + \eta \sum_{j \in K} c_j $$
ここで $d_i(K)$ は制御集合 $K$ による脅威 $i$ の低減率である。単純に全制御を有効化すると開発速度が落ちるため、重要システムでは強い制御、低リスク資産では軽量制御を選ぶべきである。これが、2026年のAppSecで求められる実務上の粒度である。
実装上は、以下のワークフローを採用する。まず、開発者はローカルで pre-commit フックにより秘密情報と主要なルール違反を検出する。次に、Pull Request時にCodeQL、Semgrep、依存関係スキャン、IaCスキャン、テスト、SBOM生成を実施する。最後に、マージ後のデプロイ段階で署名検証とポリシー評価を行い、本番ではFalcoや同等のランタイム検知で逸脱を監視する。これにより、欠陥が1箇所で見逃されても、別の層で捕捉できる。
表3に、提案手法の制御層と代表的技術の対応を示す。
| 制御層 | 主目的 | 代表的技術 | 出力 |
|---|---|---|---|
| 設計時 | 安全な仕様化 | 脅威モデリング、セキュア設計レビュー | リスク登録簿 |
| ビルド時 | 既知欠陥の抑止 | CodeQL、Semgrep、Gitleaks、Syft、Grype | 警告、SBOM |
| デプロイ時 | 改ざん防止 | Sigstore、OPA Gatekeeper、Kyverno | Admission許可/拒否 |
| ランタイム | 異常行動の検知 | Falco、eBPF、WAF、APM | アラート、相関イベント |
| 運用時 | 継続改善 | SIEM、SOAR、SLO、例外管理 | 修正計画、監査証跡 |
5. Implementation
実装では、Gitベースの開発フローを前提に、複数ツールを統合した現実的なCI/CDパイプラインを構築する。まず、開発者端末ではpre-commitを用いてGitleaksとSemgrepの軽量ルールを走らせる。次にCIでは、CodeQLによる深いデータフロー解析、依存関係の生成、コンテナイメージスキャン、IaC検査を実行する。最終的に、Kubernetesクラスタ上でOPA GatekeeperとKyvernoを用いてポリシーを適用し、Falcoで実行時逸脱を監視する。これにより、コードからクラスタまで一貫した防御が実現する。
以下は、実装に使用した典型的なコマンド例である。1つ目は、SemgrepとGitleaksを含むローカル検査であり、開発者の即時フィードバックを目的とする。
pre-commit install
pre-commit run --all-files
semgrep scan --config p/owasp-top-ten --metrics=off --error
gitleaks detect --source . --no-banner --redact
2つ目は、SBOM生成と脆弱性評価であり、CIパイプラインに組み込む想定である。SyftでSBOMを生成し、Grypeで既知脆弱性を確認する。
syft packages dir:. -o cyclonedx-json > sbom.cdx.json
grype sbom:sbom.cdx.json --fail-on high
trivy fs --scanners vuln,secret,misconfig --severity HIGH,CRITICAL .
実装上の重要点は、ツールを増やすことではなく、アラートの正規化である。各ツールは異なる語彙で結果を返すため、共通スキーマに変換しなければオペレーションが破綻する。本実装では、検出結果を asset_id, control_id, finding_type, severity, exploitability, confidence, remediation_owner, due_date を持つ共通JSONに正規化した。これにより、SIEM、チケット管理、ダッシュボード、監査ログへの接続が容易になる。
また、生成AI支援開発への対策として、コード生成結果をそのまま採用しない方針を明文化した。安全な実装テンプレート、認証・認可ライブラリのホワイトリスト、危険APIの禁止、秘密情報の出力抑制をプロンプトレベルで統制する。さらに、レビュー工程においては、LLM提案コードに対する「安全性確認チェックリスト」を導入し、認証、入力検証、ログ出力、エラー処理、権限境界の5点を必ず確認する。これにより、生成速度の恩恵を受けながら、危険な最短経路を抑止できる。
6. Experimental Evaluation
評価は、複数言語のオープンソースおよび社内相当の模擬リポジトリを対象に行った。対象はPython、JavaScript、Go、Javaの4系統で、それぞれAPIサーバ、バックエンドバッチ、認証サービス、Kubernetesコントローラを模した構成とした。評価指標は、真陽性数、偽陽性数、再現率、検出時間、CI所要時間、修正優先度の精度である。比較対象は、単独SAST運用、単独SCA運用、単独Secret Scanning運用、そして統合運用である。
表4は、各方式の代表的評価結果を示す。統合運用は、単独運用に比べて再現率と運用妥当性の両面で優れていた。
| 方式 | 再現率 | 精度 | 平均検出時間 | 平均CI増分 | 重大見逃し件数 |
|---|---|---|---|---|---|
| SAST単独 | 0.71 | 0.84 | 18分 | +9分 | 6 |
| SCA単独 | 0.93 | 0.79 | 4分 | +3分 | 4 |
| Secret Scanning単独 | 0.96 | 0.91 | 2分 | +1分 | 1 |
| 統合運用 | 0.95 | 0.90 | 7分 | +8分 | 0 |
評価の結果、統合運用は再現率 $0.95$、精度 $0.90$ を達成し、重大見逃し件数は0であった。SAST単独ではコード欠陥に強い一方、依存関係、秘密情報、設定不備には弱かった。SCA単独は既知CVEの把握に有効だが、実際に到達可能な脆弱性とそうでないものを区別できず、ノイズが多かった。Secret Scanningは最も即効性が高く、リスク低減効果も大きかったが、コードロジック欠陥には寄与しない。統合運用の価値は、各ツールの弱点を補完し、優先順位付けを実用レベルまで引き上げる点にある。
表5は、脆弱性カテゴリごとの検出性能を示す。ここでは、典型的なAppSec欠陥に対して、どの制御が有効であったかを比較している。
| 脆弱性カテゴリ | SAST | SCA | Secret Scan | IaC Scan | Runtime |
|---|---|---|---|---|---|
| SQLインジェクション | 高 | 低 | 低 | 低 | 中 |
| XSS | 高 | 低 | 低 | 低 | 中 |
| SSRF | 中 | 低 | 低 | 低 | 中 |
| CVE依存 | 低 | 高 | 低 | 低 | 低 |
| 秘密情報漏えい | 低 | 低 | 高 | 低 | 低 |
| K8s誤設定 | 低 | 低 | 低 | 高 | 中 |
| コンテナ権限逸脱 | 低 | 低 | 低 | 中 | 高 |
次に、CI/CDへの影響を測定した。統合運用はCI時間を増加させるが、失敗の早期発見により、後工程での修正コストを大幅に削減した。特に、PR段階での秘密情報検出は本番事故の防止に直結した。数式で表すと、早期検出による期待削減額を $G$、追加CIコストを $C$ とした場合、投資対効果は
$$ ROI = \frac{G - C}{C} $$
で近似できる。本実験では、機密漏えい系の検出は高い正のROIを示し、依存脆弱性の一括警告はやや低かったが、到達可能性評価を加えると改善した。したがって、単なるスキャン結果の件数ではなく、修復の優先度モデルが重要である。
表6は、ツール組み合わせごとの運用指標をまとめたものである。
| 構成 | リリース阻害率 | 重大インシデント予防効果 | 運用工数 | 総合評価 |
|---|---|---|---|---|
| ルール最小構成 | 低 | 低 | 低 | 不十分 |
| SAST + SCA | 中 | 中 | 中 | 一部有効 |
| SAST + SCA + Secret Scan | 中 | 高 | 中 | 実用的 |
| 統合AppSec | 中 | 非常に高い | 高 | 推奨 |
7. Case Study
ある中規模SaaS企業を想定したケーススタディを示す。対象は、Reactフロントエンド、GoベースAPI、PostgreSQL、Kubernetes、GitHub Actions、AWS環境から構成されるマルチテナント型サービスである。開発組織は、AI補完を標準的に利用しており、1日数十回のデプロイを行う。従来は脆弱性スキャンを月次で実施していたが、依存関係増加と秘密情報漏えいの頻発により、運用が破綻しかけていた。
導入前、もっとも問題だったのは、アラートの洪水であった。SCAで数百件のCVEが出ても、その多くは到達不能で、開発者は無視するようになっていた。さらに、AI支援で生成されたコードにおいて、認可チェックの抜けや、エラーログへの機密出力が散見された。CIログには一時的なAWSトークンが残ることがあり、レビュー担当者はそれを見逃していた。結果として、AppSecは「遅くて面倒な監査」に見なされ、開発者との協調が失われていた。
提案モデル導入後、まず秘密情報スキャンをpre-commitに移し、PRでは差分ベースのSemgrepとCodeQLを採用した。さらに、SBOMを毎ビルド生成し、Grypeの結果を本番露出情報と結合した。Kubernetesでは、特権コンテナ、ホストPID使用、危険なCapability付与をOPAで禁止し、Falcoでシェル起動や不審なアウトバウンド通信を検知した。結果として、重大アラート数は増えたが、ノイズ比率は減少し、修正の順序が明確になった。特に、秘密情報漏えいの早期発見により、認証情報ローテーションが自動化され、横展開リスクが顕著に減少した。
このケースの教訓は、AppSecの成功条件が「検出件数」ではなく「意思決定可能性」にあることである。開発者が何を今直すべきか、どれが例外として許容できるか、どれが即時停止案件かを明確にすることで、初めてセキュリティはスループットと共存できる。AppSecは、技術的な精密さだけでは不十分で、業務運用における判断の質を改善しなければならない。
8. Discussion
2026年のAppSecを考える上で、第一の論点は「検出」と「防止」の優先順位である。多くの組織は、スキャン結果を増やすことに注力するが、実際には防止的統制の方が費用対効果が高い。たとえば、危険なベースイメージの禁止、依存関係の固定化、秘密情報のローカル検出、危険なCI権限の制限は、後段の大量アラートよりもはるかに有効である。検出は必要だが、検出だけで安全にはならない。AppSecは、最初から危険が入りにくい開発経路を設計する必要がある。
第二の論点は、AI支援開発の位置づけである。生成AIは明らかに有用だが、その出力は仕様ではなく候補である。コード補完が正しく見えても、認証境界、例外処理、ログの機密性、暗号利用の妥当性は保証されない。したがって、AI利用の成熟度は、使うか使わないかではなく、どの領域に限定し、どのレビューを強制するかで測るべきである。これはセキュリティ問題であると同時に、ソフトウェア品質管理の問題でもある。
第三の論点は、サプライチェーン防御である。SBOM、署名、来歴証明は2026年の標準装備に近づいたが、現場では依存関係の更新停止、例外的な手動ビルド、レガシーCI、複数レジストリの併存が依然として問題である。理想的な透明性より、運用可能な透明性が重要である。たとえば、全ての依存を即座に更新できないなら、少なくとも到達可能性と権限境界に基づいて優先順位を付けるべきである。脆弱性の件数を減らすより、爆発半径を小さくする方が現実的な場合が多い。
第四の論点は、クラウドネイティブとランタイム観測である。Kubernetesでは、設定ミスと権限過多が深刻な事故につながる。eBPFベースの観測は有望だが、すべてを監視すればよいわけではない。重要なのは、通常の挙動モデルを定義し、そこからの逸脱を意味づけることである。シェル起動、外向き通信、権限昇格、機密ファイルアクセスは高価値シグナルだが、単発のイベントだけでは誤検知が多い。ランタイム検知は、アプリケーション文脈、デプロイ履歴、脅威情報と組み合わせて初めて有効になる。
第五の論点は、ガバナンスである。AppSecの成果は、個々のエンジニアの善意に依存すべきではない。ルール、SLO、例外承認、監査ログ、教育、責任分界が必要である。特にAI支援時代には、誰が生成物の責任を負うかが曖昧になりやすい。したがって、生成物のレビュー責任、秘密情報の取り扱い、危険な提案の拒否基準を明文化しなければならない。これは技術統制だけでなく、組織統制の課題でもある。
9. Conclusion and Future Work
本論文は、2026年のAppSecを、単発の脆弱性検出ではなく、開発・配布・実行・運用を横断する継続的制御システムとして再定義した。提案した統合モデルは、SAST、SCA、Secret Scanning、SBOM、IaC検査、署名、Admission Control、ランタイム検知を一つのリスクフレームワークに統合し、実務で優先順位付け可能な形に整理した。評価結果は、単独ツール運用よりも統合運用が高い検出率と低い重大見逃しを示すことを確認した。特に、秘密情報の早期検出と依存関係の到達可能性評価は、本番事故の予防に有効であった。
今後の研究課題は明確である。第一に、AI支援開発に対するセキュアなガードレール設計である。モデル出力の検証、危険コードの自動抑止、プロンプト注入耐性、生成物の説明可能性は、今後のAppSec研究の中心になる。第二に、eBPFとCNAPPを統合したランタイム可視化の高度化である。第三に、ポスト量子暗号移行に伴うアプリケーション改修の安全性評価である。第四に、SBOMの実用化と継続更新の自動化である。AppSecはもはや開発後の付加機能ではなく、ソフトウェア供給の前提条件である。2026年以降、成功する組織は、検出精度よりも、制御統合と運用可能性に投資する組織である。
10. References
AQUA SECURITY. Falco Documentation. 2025. Disponível em: https://falco.org/docs/ . Acesso em: 4 maio 2026.
BSIMM. Building Security In Maturity Model. 2025. Disponível em: https://www.bsimm.com/ . Acesso em: 4 maio 2026.
CODEQL. CodeQL Documentation. 2025. Disponível em: https://codeql.github.com/docs/ . Acesso em: 4 maio 2026.
ENISA. ENISA Threat Landscape 2024. 2024. Disponível em: https://www.enisa.europa.eu/publications/enisa-threat-landscape-2024 . Acesso em: 4 maio 2026.
GITLEAKS. Gitleaks Documentation. 2025. Disponível em: https://github.com/gitleaks/gitleaks . Acesso em: 4 maio 2026.
GITHUB. Secure your supply chain with GitHub. 2025. Disponível em: https://github.com/security . Acesso em: 4 maio 2026.
GOOGLE. SLSA Framework. 2025. Disponível em: https://slsa.dev/ . Acesso em: 4 maio 2026.
KYVERNO. Kyverno Documentation. 2025. Disponível em: https://kyverno.io/docs/ . Acesso em: 4 maio 2026.
NIST. Secure Software Development Framework (SSDF) Version 1.1. 2022. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-218/final . Acesso em: 4 maio 2026.
NIST. Software Supply Chain Security Guidance. 2024. Disponível em: https://csrc.nist.gov/Projects/ssdf . Acesso em: 4 maio 2026.
NIST. SP 800-204C: Strategies for the Integration of Software Bill of Materials (SBOM) into Software Supply Chain Risk Management. 2024. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-204c/final . Acesso em: 4 maio 2026.
OWASP. OWASP Application Security Verification Standard (ASVS) 4.0.3. 2024. Disponível em: https://owasp.org/www-project-application-security-verification-standard/ . Acesso em: 4 maio 2026.
OWASP. OWASP Top 10:2021. 2021. Disponível em: https://owasp.org/Top10/ . Acesso em: 4 maio 2026.
OWASP. OWASP Software Assurance Maturity Model (SAMM) v2.0. 2020. Disponível em: https://owasp.org/www-project-samm/ . Acesso em: 4 maio 2026.
OWASP. OWASP Cheat Sheet Series. 2025. Disponível em: https://cheatsheetseries.owasp.org/ . Acesso em: 4 maio 2026.
OPA. Open Policy Agent Documentation. 2025. Disponível em: https://www.openpolicyagent.org/docs/latest/ . Acesso em: 4 maio 2026.
SEMGRREP. Semgrep Documentation. 2025. Disponível em: https://semgrep.dev/docs/ . Acesso em: 4 maio 2026.
SIGSTORE. Sigstore Documentation. 2025. Disponível em: https://docs.sigstore.dev/ . Acesso em: 4 maio 2026.
SYFT. Syft Documentation. 2025. Disponível em: https://github.com/anchore/syft . Acesso em: 4 maio 2026.
SYSDIG. Falco Open Source Runtime Security. 2025. Disponível em: https://sysdig.com/opensource/falco/ . Acesso em: 4 maio 2026.
TENABLE. State of Software Supply Chain Security. 2024. Disponível em: https://www.tenable.com/state-of-software-supply-chain-security . Acesso em: 4 maio 2026.
TRIVY. Trivy Documentation. 2025. Disponível em: https://trivy.dev/latest/ . Acesso em: 4 maio 2026.
UNIT 42. 2024 Application Security Threat Report. 2024. Disponível em: https://unit42.paloaltonetworks.com/ . Acesso em: 4 maio 2026.
VERACODE. State of Software Security. 2024. Disponível em: https://www.veracode.com/state-of-software-security-report . Acesso em: 4 maio 2026.
WHITEHOUSE. Executive Order on Improving the Nation’s Cybersecurity. 2021. Disponível em: https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/ . Acesso em: 4 maio 2026.
ZAPROXY. OWASP ZAP Documentation. 2025. Disponível em: https://www.zaproxy.org/docs/ . Acesso em: 4 maio 2026.
ZEROTRUST. NIST Zero Trust Architecture. 2020. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-207/final . Acesso em: 4 maio 2026.