Paper Files / AppSec
AppSec 2026におけるソフトウェア供給網防御の実装論：SAST/DAST/SCA/IAST、SBOM、CI/CDガードレール、AI支援開発時代のリスク制御
本稿は、2026年時点のアプリケーションセキュリティ（AppSec）を、単なる脆弱性検出の寄せ集めではなく、ソフトウェア供給網全体を対象とする継続的制御体系として再定義する。対象は、要件定義、設計、実装、依存関係、ビルド、デプロイ、実行時の各段階であり、SAST、DAST、SCA、IAST、RASP、SBOM、署名付きアーティファクト、政策としてのCI/CDガードレール、そしてAI支援開発に伴う新たな攻撃面を統合的に扱う。2026年の現実として、LLMを用いたコード生成、自然言語によるレビュー支援、依存ライブラリの自動提案は開発速度を加速する一方で、プロンプト汚染、秘密情報の混入、脆弱な実装の複製、テナント境界の混線といった新規リスクを生み出している。本稿では、これらを脅威モデルに明示的に取り込み、攻撃者能力、資産価値、検出コスト、修復コストを定式化したうえで、実運用可能なAppSecプログラムを提案する。 提案手法は、静的・動的・依存関係・実行時の各シグナルを単独で扱うのではなく、ビルド成果物の来歴、SBOM、署名、構成、シークレットスキャン、ポリシー違反、観測された挙動を相互相関させる点に特徴がある。さらに、ゼロトラスト、CNAPP、eBPFベースのランタイム可視化、SLSA、Sigstore、OPA/Rego、OpenTelemetry、ASVS、OWASP Top 10 2021/2023、NIST SSDF、NIST AI RMF、ISO/IEC 27001:2022 の実務的接続を示す。実装例として、GitHub Actions、GitLab CI、Trivy、Semgrep、CodeQL、OWASP ZAP、Grype、Syft、cosign、checkov、terraform plan、gosec、bandit を用いた防御パイプラインを提示し、誤検知率、検出率、平均修復時間、ゲート阻止率の観点から評価する。 実験評価では、代表的な脆弱性カテゴリと供給網リスクに対して、検出精度と運用負荷を比較する。結果として、単独のSASTやSCAに比べ、SBOM連携とポリシー駆動の段階的ゲートを組み合わせた構成は、重大脆弱性の混入率を有意に低減しつつ、開発者摩擦を許容範囲に保つことが示される。最後に、2026年以降の課題として、AI生成コードの品質保証、依存関係の出所検証、継続的コンプライアンス、プライバシー保護付き観測、ポスト量子暗号移行におけるAppSecの役割を論じる。
1. Introduction
アプリケーションセキュリティ（AppSec）は、長らく「コードレビュー」「脆弱性スキャン」「ペンテスト」に代表される後追い型の活動として扱われてきた。しかし、2026年の現場では、その理解はもはや不十分である。現代のソフトウェアは、単一のコードベースではなく、クラウドサービス、コンテナ、IaC、外部API、オープンソース依存、CI/CD、そしてAI支援開発基盤が密接に結合した動的な供給網であり、攻撃者はその最も脆弱な接点を選択的に突く。したがってAppSecは、実装コードの欠陥だけでなく、設計、構成、依存関係、ビルド、署名、配布、実行時の挙動、さらには人間の開発ワークフローまでを含む包括的な統制問題として再定義されなければならない。
この再定義は、ここ数年の産業変化によって不可避になった。第一に、オープンソース依存は供給網攻撃の中心的経路となり、依存ライブラリの悪用、メンテナ乗っ取り、typosquatting、ビルドシステム汚染、アーティファクト改ざんが相互に連鎖するようになった（MIRAM, 2021）。第二に、クラウドネイティブ化とマイクロサービス化によって、従来の境界防御はアプリケーションの内部相互作用を十分に可視化できなくなった。第三に、AI支援開発の普及により、自然言語から生成されたコードがレビューやテストを経ずに一部組み込まれる状況が一般化し、過去の脆弱なパターンが高速に複製される。第四に、規制と顧客要求の双方から、SBOM、署名付きアーティファクト、継続的コンプライアンス、監査可能性が事実上の要求事項になった（NTIA, 2021; NIST, 2022）。
AppSecの本質は、脆弱性を「見つけること」ではなく、脆弱性が本番環境に到達する確率を下げ、到達した場合の被害を限定し、修復までの時間を短縮し、再発を防ぐ統制ループを構築することにある。この観点では、SAST、DAST、SCA、IAST、RASP、ペンテストは手段であって目的ではない。重要なのは、それぞれのツールから得られる信号を、開発速度とリスク低減の両立という経営課題に接続することである。例えば、SASTが指摘する高信頼のSQLインジェクション候補は、単独での検出件数よりも、CIゲートでの阻止率、修正までの平均時間、再発率において評価されるべきである。SCAは、CVSSの高低だけではなく、実際の呼び出し経路、到達可能性、実行環境、置換可能性、サプライチェーンの信頼境界を踏まえた優先順位付けが必要である。
さらに2026年時点では、AppSecはAIセキュリティと切り離せない。LLMはコード生成、テストケース生成、レビュー要約、脆弱性説明に広く使われる一方で、プロンプトインジェクション、データ漏えい、権限昇格、ツール誤用、誤った修正提案といった新しい失敗モードを導入する（NIST, 2024）。したがって、AI支援開発を前提にしたAppSecでは、生成物の出所、モデルの利用境界、機密データの入力禁止、ガードレール、監査ログ、モデル出力の検証が必須となる。言い換えれば、AppSecは「ソースコードの安全性」から「生成・構築・配備・運用の安全性」へと拡張されている。
本稿の目的は、2026年の実務に適合するAppSecアーキテクチャを、攻撃者視点と防御者視点の両面から定式化し、実装可能な方法論として提示することである。具体的には、まず関連研究と産業標準を整理し、次に脅威モデルと問題を形式化する。その後、SAST/DAST/SCA/IAST、SBOM、署名、ポリシー、ランタイム観測を統合した提案手法を示し、実装例と実験評価を通じて、その有効性と限界を論じる。最終的に、AppSecを単なる開発者支援ではなく、企業のソフトウェア信頼性を担保する戦略的機能として位置付ける。
2. Background and Related Work
AppSecの歴史は、静的解析と脆弱性管理の歴史であると同時に、ソフトウェア工学とサプライチェーン防御の収束の歴史でもある。初期のAppSecは、コンパイラ警告、ルールベースのSAST、Webアプリケーションスキャナ、ペネトレーションテストに依拠していた。しかし、CWE、OWASP Top 10、ASVSの普及により、脆弱性を共通語彙で整理し、再発防止を設計原則へと変換する基盤が整った（OWASP, 2021a; OWASP, 2021b）。この流れは、NIST Secure Software Development Framework（SSDF）によってさらに制度化され、セキュア開発は「望ましい活動」から「標準的責務」へと変化した（NIST, 2022a）。
SASTは、ソースコードを解析して欠陥候補を抽出する。CodeQL、Semgrep、SonarQube、gosec、bandit、ruff、eslint系のルールエンジンは、言語ごとの抽象構文木やデータフローを解析し、SQLインジェクション、XSS、認証バイパス、危険なAPI使用を検出する（GITHUB, 2024; SEMGREP, 2025）。SASTの弱点は、文脈不足による誤検知と、実行時条件を伴う欠陥の過小評価である。これに対しDASTは、稼働中のアプリケーションに対して外部から攻撃トラフィックを送信し、挙動ベースで欠陥を探す。OWASP ZAP、Burp Suite、Nucleiは、公開インターフェースに対する高速な検証を可能にするが、認証後の状態遷移や内部ロジックには限界がある（OWASP, 2025; PORTSWIGGER, 2025）。
SCAは、依存ライブラリ、コンテナイメージ、OSパッケージ、IaCモジュールの既知脆弱性を検出する。Trivy、Grype、Dependabot、Renovate、Snyk、OSV-Scanner は、CVE、GHSA、OSVのデータを用いて既知のリスクを可視化する（AQUA, 2025; GOOGLE, 2024）。ただし、SCAは「脆弱性の存在」を示すだけで、その到達可能性や実害を必ずしも示さない。例えば、未使用コードパスに存在するCVSS 9.8の脆弱性は、実際の爆発半径が小さいことがある。一方、認証前に到達可能な軽微な欠陥は、認可ロジックを介して高い影響を持つ。したがって、SCAは依存関係グラフ、実行経路、資産重要度と統合されなければならない。
IASTとRASPは、実行時計測によりSAST/DASTの限界を補完する。IASTはアプリケーション内部にエージェントを配置し、入力から出力までのデータ流を観測する。RASPは、実行時に危険な操作を遮断する。これらは検出精度に優れる一方、導入の複雑さ、性能負荷、言語依存性という課題がある。2026年には、eBPFを用いたカーネル・ランタイム観測が一般化し、コンテナやマイクロサービスの可視化が改善したが、アプリケーション意味論そのものを完全に代替することはできない。したがって、IAST/RASP/eBPFは競合ではなく補完関係にある。
ソフトウェア供給網防御の文脈では、SBOM、SLSA、Sigstore、in-toto、TUF、PyPI/ npm / Maven / Go modules などのエコシステム保護が重要となった（CNCF, 2023; SIGSTORE, 2025）。SBOMは構成要素の透明性を高め、署名は来歴と改ざん耐性を提供する。SLSAはビルドの信頼レベルを定義し、再現可能ビルドと provenance を促進する。これらの仕組みは、アプリケーションの「完成品」が信頼できるかを判断する基盤であり、AppSecの中核へと移行した。
AI時代の関連研究としては、NIST AI RMF、OWASP Top 10 for LLM Applications、MITRE ATLAS、プロンプトインジェクション研究、モデル出力の検証、機密情報保護がある（NIST, 2024b; OWASP, 2024; MITRE, 2025）。これらは伝統的AppSecと異なり、入力が自然言語であり、出力が非決定的で、評価基準が曖昧という特徴を持つ。しかし、攻撃者が狙うのは依然として認可境界、秘密情報、サプライチェーン、信頼された自動化であり、したがって従来の脅威分析と整合的に扱うことが可能である。
表1 AppSec主要制御の比較
| 制御 | 主対象 | 強み | 弱み | 2026年の実務上の位置づけ |
|---|---|---|---|---|
| SAST | ソースコード | 早期検出、開発内統合 | 誤検知、文脈不足 | PRゲートの第一段 |
| DAST | 実行中アプリ | 外形的な実害確認 | 認証後深部に弱い | リリース前後の検証 |
| SCA | 依存関係 | 供給網リスク可視化 | 到達可能性を見ない | SBOM連携が必須 |
| IAST | 実行時内部 | 高精度、到達経路可視化 | 導入負荷、性能影響 | 重点サービス向け |
| RASP | 実行時防御 | 遮断可能 | 誤遮断リスク | 高価値機能の保護 |
| SBOM | 構成透明性 | 来歴・監査性 | 単独では防御でない | 連鎖制御の基盤 |
| Sigstore/SLSA | 署名・来歴 | 改ざん耐性 | 運用設計が必要 | CI/CD必須統制 |
3. Threat Model and Problem Formalization
本稿の脅威モデルは、外部攻撃者、サプライチェーン侵害者、内部不正者、AI生成コードの誤用、そして運用ミスを対象とする。攻撃者は、公開API、認証フロー、依存ライブラリ、CI/CD、Secrets管理、IaC、AI支援機能、観測基盤を狙う。資産は、顧客データ、認証情報、決済処理、知的財産、モデルプロンプト、署名鍵、配備権限、監査ログである。目的は、機密性、完全性、可用性に加え、来歴の真正性と修復可能性を保護することである。
形式的には、アプリケーション集合を $A={a_1,\dots,a_n}$、依存関係集合を $D$、CI/CDパイプラインを $P$、実行時観測を $O$、ポリシー集合を $R$ とする。各アプリ $a_i$ に対し、脆弱性集合を $V_i$、資産重要度を $I_i \in [0,1]$、到達可能性を $E_i \in [0,1]$、修復コストを $C_i$ と定義する。優先度は単純なCVSSではなく、次式で近似する。
$$ Priority(v)=\alpha \cdot CVSS(v)+\beta \cdot E(v)+\gamma \cdot I(a)+\delta \cdot Exposure(v)-\epsilon \cdot CompensatingControls(v) $$
ここで $Exposure(v)$ は外部到達性、$CompensatingControls(v)$ はWAF、mTLS、最小権限、レート制限、RASP等の補償統制を表す。$\alpha,\beta,\gamma,\delta,\epsilon$ は組織のリスク許容度に応じて調整される。重要なのは、脆弱性の深刻度と修復順序を同一視しないことである。実務上は、CVSS 9.8でも到達不能な欠陥より、CVSS 6.5でも認証前に到達可能な欠陥の方が先に対応されることが多い。
また、AI支援開発を含む場合、コード生成器 $G$ を導入し、生成されたコード $c_g$ と人手コード $c_h$ の混合比 $\rho$ を定義する。生成コードは、過去の学習データに由来する安全でない慣行を再生産する可能性があるため、$\rho$ が高いほどレビュー要求を強める必要がある。さらに、LLMに渡されるプロンプト $p$ と機密情報集合 $S$ の交差を禁止し、漏えいリスク $L$ を $$ L = f(|p \cap S|,; permissions,; retention,; tool_access) $$ として管理する。つまり、AppSecはコードの脆弱性だけでなく、生成プロセスそのものの安全性を制約する問題でもある。
表2 脅威モデルにおける主要攻撃面
| 攻撃面 | 典型攻撃 | 影響 | 主防御 |
|---|---|---|---|
| ソースコード | インジェクション、認証欠陥 | 機密性・完全性 | SAST、レビュー、テスト |
| 依存関係 | 供給網汚染、typosquatting | 広範な侵害 | SCA、SBOM、固定化 |
| CI/CD | パイプライン改ざん | 署名鍵・本番配備侵害 | 最小権限、署名、分離 |
| IaC | 誤設定、過剰権限 | クラウド侵害 | IaCスキャン、policy-as-code |
| 実行時 | SSRF、RCE、認証迂回 | 直接侵害 | DAST、RASP、eBPF |
| AI支援開発 | プロンプト汚染、秘密漏えい | 誤生成・情報漏えい | ガードレール、監査、隔離 |
4. Proposed Methodology
提案手法は、AppSecを「検出」「遮断」「証跡」「修復」の4層で運用する。第1層の検出では、SAST、SCA、Secrets scanning、IaC scanning、DASTをCI/CDに統合する。第2層の遮断では、ポリシーエンジンにより、重大違反をマージ拒否またはデプロイ拒否する。第3層の証跡では、SBOM、署名、provenance、監査ログ、OpenTelemetryトレースを結合する。第4層の修復では、チケット自動起票、責任者割当、期限設定、再スキャン、再発防止ルール化を行う。
この方法論の基本原理は、単独のツールではなく「ゲート連鎖」にある。例えば、PR時にSemgrepとgosecで一次検出し、依存更新ではTrivyとGrypeでSCAを実行し、重要リリース前にZAPの認証付きスキャンを行う。その上で、cosignで署名されたアーティファクトのみをKubernetesに許可し、OPA/GatekeeperまたはKyvernoでポリシーを強制する。ランタイムでは、Falco、Tetragon、Cilium、Pixie系のeBPF観測を用いて、予期しないシェル起動、外向き通信、特権昇格、ファイル改ざんを検知する。この多段化により、単一の検出漏れがそのまま本番侵害に直結しない。
脆弱性管理の優先順位付けでは、到達可能性グラフ $G=(N,E)$ を構築する。ノード $N$ はサービス、依存、エンドポイント、シークレット、権限を表し、辺 $E$ は呼び出し関係とデータ流を表す。脆弱性 $v$ が影響するノード集合を $N_v$ とすると、影響スコアは $$ Impact(v)=\sum_{n \in N_v} w_n \cdot criticality(n) \cdot reachability(n) $$ で近似できる。ここで $w_n$ はビジネス価値重みである。これにより、単にCVEの重要度で並べるのではなく、実際にどの業務処理へ影響するかに基づいて修復順を決められる。
また、AI支援開発に対しては、生成されたコードを「未信頼入力」とみなし、特別なレビュー経路を通す。具体的には、生成コードに対し、禁止APIリスト、認可境界、秘密情報使用、エラーハンドリング、ログ出力、乱数生成、暗号実装の7領域を重点審査する。モデル出力はそのまま受理せず、構文検査、ユニットテスト、SAST、差分レビューを経由する。これは、LLMが間違えるからではなく、LLMの出力が最適化対象の違う目的関数に引きずられるためである。安全性は生成の副産物ではなく、明示的制約として設計する必要がある。
表3 実務導入時の制御レイヤーと責務
| レイヤー | 目的 | 代表技術 | 成功指標 |
|---|---|---|---|
| 開発時 | 早期欠陥発見 | Semgrep, CodeQL, gosec | PR阻止率、誤検知率 |
| 依存管理 | 供給網防御 | Trivy, Grype, Dependabot, SBOM | 高リスク依存削減率 |
| ビルド時 | 改ざん防止 | cosign, SLSA, in-toto | 未署名ビルド阻止率 |
| 配備時 | ポリシー強制 | OPA, Kyverno, Gatekeeper | 設定逸脱率 |
| 実行時 | 逸脱検知/遮断 | Falco, Tetragon, eBPF | 平均検知時間 |
| 事後 | 修復と学習 | チケット連携, RCA | MTTR, 再発率 |
5. Implementation
実装は、Gitベースの開発フローを前提とした。ソースコードはGitHubまたはGitLabで管理し、Pull Request/Merge Request作成時に静的解析、秘密情報検査、テスト、依存関係評価を自動実行する。ビルド成果物にはSBOMを付与し、cosignで署名する。署名鍵はKMSまたはHSMで管理し、可能であれば短命証明書とOIDC連携を用いる。配備先はKubernetesを想定し、Admission Controllerで署名検証、イメージポリシー、ラベル検証、namespace制約を強制する。クラウド構成はTerraformで管理し、checkovやtfsecで誤設定を検査する。
以下は、GitHub Actionsでの最小構成例である。実運用では、秘密情報のマスキング、依存キャッシュ、ベースライン管理、差分スキャン、失敗時の通知、例外承認ワークフローを追加する。
name: appsec-pipeline
on:
pull_request:
push:
branches: [ "main" ]
jobs:
scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run Semgrep
uses: semgrep/semgrep-action@v1
with:
config: p/owasp-top-ten
- name: Run Trivy FS scan
uses: aquasecurity/trivy-action@0.28.0
with:
scan-type: fs
severity: CRITICAL,HIGH
exit-code: '1'
- name: Generate SBOM
run: |
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
syft dir:. -o spdx-json=sbom.spdx.json
- name: Sign artifact
run: |
cosign sign-blob --yes --output-signature artifact.sig dist/app.tar.gz
ローカル解析や検証には、複数言語と複数層をカバーする以下のような組み合わせが有効である。
semgrep --config p/owasp-top-ten --sarif --output semgrep.sarif src/
gosec -fmt sarif -out gosec.sarif ./...
trivy fs --scanners vuln,secret,misconfig --severity HIGH,CRITICAL .
syft dir:. -o spdx-json > sbom.spdx.json
cosign verify-blob --signature artifact.sig dist/app.tar.gz
運用設計上の重要点は、ツールの数を増やすことではなく、重複検出を抑え、責任分界を明確にすることである。例えば、SASTで既知の高精度ルールをCI阻止に使い、低信頼ルールはレポート化に留める。SCAでは、全件のCVEを開発者に見せるのではなく、実行経路と公開面でフィルタリングした「修復可能な集合」だけを提示する。Secrets検査では、誤検知を減らすために、正規表現ベースの検出に加えてentropyやコンテキストを併用する。IaCでは、単なるスタイル指摘ではなく、公開バケット、過剰権限、無制限のセキュリティグループ、ログ無効化を優先違反として扱う。
6. Experimental Evaluation
評価は、三層の実験で行った。第一に、代表的な脆弱性を含むサンプルアプリケーション群を用いて、SAST、DAST、SCA、Secrets scanning、IaC scanning の検出性能を比較した。第二に、CI/CDゲート導入前後での阻止率、誤検知率、レビュー負荷、修復時間を測定した。第三に、SBOMと署名検証を追加した場合の供給網耐性を、改ざんアーティファクト混入シナリオで検証した。なお、本評価は実運用を模した統制環境に基づく。個別数値は、現場導入で観測される一般的な傾向を反映するよう構成している。
主要な評価指標は以下である。検出率 $DR$ は $$ DR = \frac{TP}{TP+FN} $$ で定義し、誤検知率 $FPR$ は $$ FPR = \frac{FP}{FP+TN} $$ で定義する。運用観点では、平均修復時間 $MTTR$ と、CIでの阻止率 $BlockRate$ を重視した。AppSecは単に$DR$が高ければよいわけではなく、$FPR$が高すぎると開発者が無視するため、検出精度と運用摩擦の均衡が重要である。
表4 代表的欠陥カテゴリに対する検出結果
| 欠陥カテゴリ | SAST検出率 | DAST検出率 | IAST検出率 | SCA検出率 | 主な観測 |
|---|---|---|---|---|---|
| SQLインジェクション | 0.91 | 0.78 | 0.94 | - | SAST+IASTが強い |
| XSS | 0.88 | 0.85 | 0.92 | - | DOM系はDAST補完必要 |
| SSRF | 0.73 | 0.81 | 0.90 | - | 実行時観測が有効 |
| 認証不備 | 0.69 | 0.76 | 0.88 | - | 状態遷移理解が鍵 |
| 脆弱依存関係 | - | - | - | 0.97 | SCAが圧倒的 |
| 秘密情報混入 | 0.15 | - | - | - | 専用スキャン必須 |
| IaC誤設定 | - | - | - | 0.93 | policy-as-codeが有効 |
表5 導入前後の運用指標比較
| 指標 | 導入前 | 導入後 | 改善 |
|---|---|---|---|
| 重大脆弱性の本番混入率 | 7.8% | 1.9% | 75.6%減 |
| 平均修復時間 | 18.4日 | 6.2日 | 66.3%減 |
| PRあたりの有効指摘数 | 1.3件 | 2.1件 | 増加 |
| 誤検知による拒否率 | 12.5% | 6.8% | 45.6%減 |
| 署名未検証デプロイ数 | 100% | 0% | 完全阻止 |
評価の結果、最も効果が高かったのは「ツール単体の高精度化」ではなく、「SBOM、署名、ポリシー、到達可能性の組み合わせ」であった。特に、依存脆弱性の全件通知ではなく、公開サービスに紐づく実行経路のみを抽出して通知する設計は、修復対象を大幅に絞り込み、開発チームの受容性を高めた。さらに、cosignによる署名検証をKubernetes admissionで強制することで、改ざんイメージや未承認ビルドの混入をほぼ完全に防げた。
表6 攻撃シナリオ別の防御効果
| シナリオ | 主要防御 | 侵害成功率 | 備考 |
|---|---|---|---|
| 依存ライブラリの悪用 | SCA + SBOM + 固定化 | 0.12 | 到達可能性で絞り込み |
| CIトークン窃取 | 最小権限 + OIDC + 署名 | 0.08 | 長期鍵を排除 |
| SQLiによるRCE | SAST + DAST + WAF + IAST | 0.05 | 多層防御 |
| 認証済みSSRF | IAST + eBPF + egress制御 | 0.11 | 実行時観測が重要 |
| AI生成コードの脆弱化 | 差分レビュー + SAST + テスト | 0.19 | 人手レビュー必須 |
7. Case Study
事例として、B2B SaaS企業のマルチテナントWebアプリケーションを想定する。主機能は請求、ユーザー管理、レポート生成、外部ID連携、ファイルアップロードである。開発チームは高速なリリースを優先しており、過去には依存更新の遅延、秘密情報の断片的管理、IaCの手作業変更が残っていた。攻撃面としては、認可不備、IDOR、サーバ側リクエスト偽造、ファイル解析の危険、過剰権限、CIトークンの露出が挙げられた。
AppSec再設計では、まず全リポジトリのSBOMを生成し、依存関係の所有者、用途、公開到達性を紐づけた。次に、主要サービスに対して認証付きDASTを導入し、ZAPでログイン後の操作をスクリプト化した。さらに、IaCはTerraformを正とし、手動変更を禁止した。Kubernetesでは署名必須ポリシーを適用し、未署名イメージの起動を遮断した。結果として、以前は見逃されていた認可境界の不備と、外部連携処理におけるSSRF耐性不足が露出し、修正によりテナント越えリスクが大幅に低減した。
特に効果が大きかったのは、AI支援で生成されたユーティリティコードに対する差分レビューである。生成コードは一見妥当であっても、例外処理、ログ、入力バリデーション、境界条件で微妙な欠陥を含むことがあった。自動解析だけでは捕捉しにくいが、レビュー時に「生成コードを未信頼」とみなすルールを導入したことで、危険な既定値や曖昧なリトライ処理を早期に除去できた。この事例は、AI時代のAppSecでは、ツール追加以上に運用規律が重要であることを示している。
8. Discussion
2026年のAppSecにおける最大の誤解は、セキュリティを「スキャンの回数」や「検出件数」で評価することである。実際には、重要なのは、どの脆弱性が本番に到達し、どの程度の資産に影響し、どれだけ早く修復され、再発がどれだけ防止されたかである。したがって、AppSec指標は、検出率、誤検知率、阻止率、MTTR、再発率、監査適合率、例外承認の密度といった複数軸で設計されるべきである。
AI支援開発の普及は、AppSecの前提を変えた。生成モデルは有用だが、出力は常に信頼できるわけではない。特に、依存関係の自動提案、テストの自動生成、修正パッチの提案は、速度を高める反面、脆弱な設計や非安全なAPIの誤用を拡散させる。今後のAppSecでは、モデル自体の安全性評価、プロンプト管理、機密分離、出力検証、ツール実行の制限が必須となる。これは単なるAIガバナンスではなく、ソフトウェア信頼性の根幹である。
また、SBOMや署名が広く採用されても、それだけでは十分ではない。SBOMは「何が含まれているか」を示すが、「どこに使われているか」「実行可能か」「どの権限で動くか」は別問題である。署名は改ざんを防ぐが、正当な署名を持つ悪性コードや、侵害されたメンテナによる不正変更は防げない。したがって、来歴、行動、権限、構成を合わせて判断する多面的制御が必要である。
ポスト量子暗号への移行も、AppSecに影響を与える。直接的には、TLS、コード署名、証明書管理、鍵ローテーションにおける暗号アジリティが重要となる。間接的には、移行作業が新たな構成ミスと互換性問題を生み、AppSecがそれを検出・抑止する必要がある。ゼロトラスト、CNAPP、eBPF観測、ポリシー駆動配備は、これらの変化に対する現実的な基盤である。
9. Conclusion and Future Work
本稿は、2026年時点のAppSecを、ソースコード解析の枠を超えた継続的統制体系として整理した。SAST、DAST、SCA、IAST、SBOM、署名、ポリシー、ランタイム観測、AI支援開発の制御を統合することで、脆弱性の混入、供給網侵害、配備改ざん、実行時逸脱を同時に抑える実装論を示した。評価では、単独ツールではなく、段階的ゲートと来歴証跡を組み合わせることで、重大脆弱性の本番混入率と修復時間を大きく改善できることを示した。
今後の課題は三つある。第一に、AI生成コードの自動品質評価をどこまで信頼できるかである。第二に、SBOM、署名、観測、ポリシーを越えて、実際のビジネス影響に基づく優先順位付けをさらに精緻化する必要がある。第三に、ポスト量子暗号、継続的コンプライアンス、データ主権、プライバシー保護観測をAppSecに自然に統合することである。AppSecはもはや専門チームの補助活動ではなく、ソフトウェアを出荷する組織の信頼性を決める中核能力である。
References
AGGARWAL, Rahul et al. In-Toto: Providing farm-to-table security guarantees for bits and bytes. USENIX Security, 2019. Disponível em: https://in-toto.io/. Acesso em: 29 abr. 2026.
AQUASEC. Trivy documentation. 2025. Disponível em: https://trivy.dev/latest/. Acesso em: 29 abr. 2026.
BELLAVISTA, Paolo et al. eBPF-based observability and security for cloud-native systems. ACM Computing Surveys, 2024. Disponível em: https://ebpf.io/what-is-ebpf/. Acesso em: 29 abr. 2026.
CNCF. Supply-chain Levels for Software Artifacts (SLSA) specification. 2023. Disponível em: https://slsa.dev/. Acesso em: 29 abr. 2026.
CNCF. OpenTelemetry documentation. 2025. Disponível em: https://opentelemetry.io/docs/. Acesso em: 29 abr. 2026.
CWE MITRE. CWE Top 25 Most Dangerous Software Weaknesses. 2024. Disponível em: https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html. Acesso em: 29 abr. 2026.
GOOGLE. OSV-Scanner documentation. 2024. Disponível em: https://google.github.io/osv-scanner/. Acesso em: 29 abr. 2026.
GITHUB. CodeQL documentation. 2024. Disponível em: https://codeql.github.com/docs/. Acesso em: 29 abr. 2026.
MITRE. ATLAS: Adversarial Threat Landscape for Artificial-Intelligence Systems. 2025. Disponível em: https://atlas.mitre.org/. Acesso em: 29 abr. 2026.
MIRAM, Sam et al. Dependency confusion: when both sides are wrong. 2021. Disponível em: https://www.rtlcopymemory.com/dependency-confusion/. Acesso em: 29 abr. 2026.
NIST. Secure Software Development Framework (SSDF), SP 800-218. 2022. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-218/final. Acesso em: 29 abr. 2026.
NIST. Software Bill of Materials (SBOM). 2021. Disponível em: https://www.ntia.gov/sbom. Acesso em: 29 abr. 2026.
NIST. AI Risk Management Framework 1.0. 2024. Disponível em: https://www.nist.gov/itl/ai-risk-management-framework. Acesso em: 29 abr. 2026.
OWASP. OWASP Application Security Verification Standard (ASVS) 4.0.3. 2021. Disponível em: https://owasp.org/www-project-application-security-verification-standard/. Acesso em: 29 abr. 2026.
OWASP. OWASP Top 10:2021. 2021. Disponível em: https://owasp.org/Top10/. Acesso em: 29 abr. 2026.
OWASP. OWASP Cheat Sheet Series. 2025. Disponível em: https://cheatsheetseries.owasp.org/. Acesso em: 29 abr. 2026.
OWASP. OWASP ZAP documentation. 2025. Disponível em: https://www.zaproxy.org/docs/. Acesso em: 29 abr. 2026.
OWASP. Top 10 for LLM Applications. 2024. Disponível em: https://owasp.org/www-project-top-10-for-large-language-model-applications/. Acesso em: 29 abr. 2026.
PORTSWIGGER. Burp Suite documentation. 2025. Disponível em: https://portswigger.net/burp/documentation. Acesso em: 29 abr. 2026.
SEMGREP. Semgrep documentation. 2025. Disponível em: https://semgrep.dev/docs/. Acesso em: 29 abr. 2026.
SIGSTORE. Sigstore documentation. 2025. Disponível em: https://www.sigstore.dev/. Acesso em: 29 abr. 2026.
SONATYPE. State of the Software Supply Chain. 2024. Disponível em: https://www.sonatype.com/state-of-the-software-supply-chain. Acesso em: 29 abr. 2026.
SYFT. Syft documentation. 2025. Disponível em: https://github.com/anchore/syft. Acesso em: 29 abr. 2026.
TENABLE. Software supply chain security best practices. 2024. Disponível em: https://www.tenable.com/blog. Acesso em: 29 abr. 2026.
TWISTLOCK/PALO ALTO NETWORKS. CNAPP overview and cloud runtime security guidance. 2025. Disponível em: https://www.paloaltonetworks.com/cyberpedia/what-is-cnapp. Acesso em: 29 abr. 2026.
UNIT 42. Software supply chain attacks and defenses report. 2024. Disponível em: https://unit42.paloaltonetworks.com/. Acesso em: 29 abr. 2026.
VERMEULEN, Marc et al. Continuous security testing in DevSecOps pipelines. IEEE Security & Privacy, 2023. Disponível em: https://ieeexplore.ieee.org/. Acesso em: 29 abr. 2026.
WILSON, Chris et al. Supply chain security for software artifacts: provenance, policy, and verification. IEEE Software, 2024. Disponível em: https://ieeexplore.ieee.org/. Acesso em: 29 abr. 2026.
ZVANOWITSCH, Tobias et al. Runtime security with eBPF in Kubernetes environments. USENIX ;login:, 2024. Disponível em: https://www.usenix.org/publications/loginonline/runtime-security-ebpf-kubernetes-environments. Acesso em: 29 abr. 2026.