AWSで考えるAI駆動Positive WAFと脆弱性到達可能性検証

先に結論

この構想は、公開Web Applicationの継続的防御を二つのLoopへ分ける。Fast LoopではApplicationの正常HTTP仕様を抽出し、AWS WAFで表現可能な制約へ変換する。Slow Loopでは新しい脆弱性情報を収集し、その脆弱性が対象Applicationで成立するか、外部入力から脆弱な処理へ到達できるか、補完統制で遮断できるかを証跡付きで評価するのだ。

中心に置くのは、AIが自由に作ったWAF Ruleではない。Code、OpenAPI、Validator、Testから得たEvidenceをApplication Security Contractへ正規化し、決定論的なCompilerがAWS WAFのRule候補とIaCを生成する。Amazon Bedrockは曖昧な関連付けと意味解釈を補助し、本番変更はTest、Count、観測、人間承認、限定Blockを通す。

AWS Security Agentは2026年6月以降、AWS Continuumの一部として案内されている。Code Review、Penetration Test、Finding Revalidationは、任意のCVEを直接判定する専用Engineではない。本構想では、独自のCVE収集・SBOM照合・Test Contract生成を置き、その外側からApplicationを動的検証するAdversarial Validatorとして使う。¹²

本稿は2026年9月4日時点の公式資料に基づくArchitecture Proposalである。AWSの既成機能、この記事で提案する自作Component、PoC用の独自指標を区別して読む必要があるのだ。

構想の基本思想

Positive Securityは、「既知の悪い通信」を列挙するだけでなく、「Applicationが受理する正常通信」を定義し、その外側を観測または拒否する考え方である。Path、Method、Content-Type、Parameter、Length、enumなど、Request単体から確定できる通信形状が主な対象になる。

Evidence-driven Reachabilityは、「発火しないと思う」という説明を避け、SBOM、Version、Code/Data Flow、WAF Log、Origin Log、Regression Test、動的検証を組み合わせて判定する考え方である。ただし、観測できなかったことだけを非到達の証明にはしない。Telemetryの欠落と、本当に到達しなかった状態を分けなければならない。

重要な境界

Pathや型が正常でも、BOLA/IDOR、Business Logic Abuse、認証・認可不備は通過し得る。Positive WAFはApplication Authorizationの代替ではない。

HTTP攻撃面をRequest上の位置で整理する

画面上の「入力フォーム」と、HTTP上で値が格納される場所は別の概念である。HTMLの入力値は実装次第でQueryにもBodyにもなる。

分類	例	AWS WAFの主な検査対象	自動化適性
Static Path	/products	UriPath	高
Path Parameter	/products/123	UriPathとRegex Pattern Set	高
HTTP Method	POST /orders	Method	高
Query Parameter	?page=3	SingleQueryArgument	高
JSON Body	{"quantity":3}	JsonBody	中
Form URL Encoded	quantity=3&id=10	Body	中〜低
multipart/form-data	入力値とFile	Body	低

JSON Bodyを「高」ではなく「中」としたのは、AWS WAFのJSON inspectionが完全なJSON Schema Validatorではないためである。AWS WAFはJSON要素のKey、Value、Included Pathを抽出してMatch Statementへ渡せる。一方、公式文書は不正JSONを完全には検証しない場合があると明記している。Required、未知Field、型、数値Rangeを契約どおりに強制するには、複数Statementへの分解、Parser failure時のFallback、Application側の再検証が必要なのだ。³

実装	HTTP表現	WAF設計
<form method="GET">	Query String	各引数をSingleQueryArgumentで検査しやすい
POST + application/x-www-form-urlencoded	Body文字列	JSONのようなField単位抽出がなく、Regex等が複雑になる
POST + multipart/form-data	Multipart Body	BoundaryやFileを含むため厳密なPositive Ruleには不向き
JavaScriptのfetchやaxios	Query、JSON Bodyなど	送信Codeを解析して実際のHTTP表現を確定する

Body inspection sizeにも上限がある。Application Load BalancerとAWS AppSyncでは先頭8 KB、CloudFront、API Gateway、Amazon Cognito、App Runner、Verified Access、Amazon Bedrock AgentCore Gatewayでは既定16 KBで、設定により最大64 KBまで拡張できる。Oversize Handlingを決めずにBody based Positive SecurityをBlockへ移してはいけない。⁴

Application Security Contractを中間に置く

AI出力とWAF設定を直接結ばず、中間にApplication Security Contractを置く。AIの責任をEvidenceの関連付けと意味解釈へ限定し、WAF生成をReview可能にするのだ。

endpoint:
  method: POST
  path: /orders

queryParameters:
  campaign:
    type: string
    pattern: "^[A-Z0-9]{8}$"

requestBody:
  contentType: application/json
  fields:
    productId:
      type: integer
      required: true
    quantity:
      type: integer
      minimum: 1
      maximum: 99
      required: true
    deliveryType:
      type: string
      enum: [normal, express]

evidence:
  route: src/routes/order.ts
  validator: src/schema/order.ts
  test: tests/order.test.ts

evidenceTier: high

Contractには値制約だけでなく、location=query、location=body、contentType、jsonPointerなどのTransport情報を持たせる。ただし、ContractからAWS WAFへの変換が決定論的でも、意味を完全に保存できるとは限らない。Compilerは各制約をrepresentable、partially_representable、application_onlyへ分類し、損失がある場合は自動Block候補から外す必要がある。

推奨アーキテクチャ

役割分担は次のとおりである。

Component	役割	位置付け
Static Extractor	OpenAPI、AST、Route manifest、Validator、Testから決定的に情報を取る	自作
Amazon Bedrock	Frontend、Backend、Test間の関連付けや曖昧部分を構造化する	AWS managed AI service
Application Security Contract	正常HTTP仕様、Evidence、表現可能性、変更差分を保持する	自作の中間表現
WAF Compiler	ContractからAWS WAF RuleとIaCの候補を決定論的に作る	自作
AWS WAF	Requestを観測し、承認済みRuleをCountまたはBlockで実行する	AWS service
Vulnerability Collector	KEV、NVD、Vendor Advisory、EPSSを正規化する	自作
AWS Security Agent	Code Review、Pentest、Finding Revalidationを行う	AWS Continuumの一部

既存CI/CDへAmazon Bedrockを組み込む

BedrockはPipeline基盤ではなく、既存Build Runnerから呼ぶInference APIとして扱う。CodeBuild、GitHub Actions、GitLab CI、Jenkinsなどの違いは本質ではない。

1. CI/CD用Roleには対象ModelまたはInference Profileへのbedrock:InvokeModelなど、必要最小限の権限だけを付与する。
2. git diffからRoute、Validator、DTO、Form、Test、OpenAPIの変更を検出する。
3. Static Extractorで機械的に取れる情報を先にJSON化する。
4. BedrockへはFrontendとBackendの関連や不整合など、意味解釈が必要な部分だけを渡す。
5. Structured OutputsでContract DeltaをJSON Schemaに固定する。⁵
6. WAF Compilerは通常のCodeとして実装し、同じ入力から同じRule候補を生成する。

Bedrockから直接wafv2:UpdateWebACLを実行させない。生成物はGit/IaCに残し、Policy Diff、Change Management、Rollback経路を維持する。

Token消費をRepository SizeからChange Sizeへ近づける

大規模Repositoryを毎回LLMへ投入しないことが重要である。固定System PromptやContract Schemaは、採用ModelとAPIが対応する場合にPrompt Caching候補になる。Amazon BedrockのPrompt CachingはImplicitとExplicitがあり、Model/APIごとに対応方式、最低Token数、TTLが異なるため、Cache hitを保証する機能として扱ってはいけない。⁶

優先順位	情報源	LLM利用
1	OpenAPI、JSON Schema、generated manifest	原則不要
2	AST、Router declaration、Validator metadata	原則不要
3	Unit/Integration Test	必要箇所のみ
4	Frontend Form、fetch、axios	関連付けに利用
5	生Source全文	最後の手段

AWS WAF Ruleへ変換できる範囲

Contract	AWS WAFでの表現候補	注意点
Static Path	UriPath	許可PathとDefault actionの組合せを設計する
Path Parameter	UriPathとRegex Pattern Set	EncodingとText TransformationをTestする
Method	Method	Pathとの組合せで評価する
Query Parameter	SingleQueryArgument	同名Parameterが複数ある場合は全値をORで評価する
JSON Field	JsonBodyとIncludedPaths	完全なSchema検証ではなく、Match Statementへの入力抽出である
urlencoded/multipart	Body	範囲を限定し、Application側検証を主にする

Source原稿ではEvidence一致度を1.00、0.90のようなConfidenceで表していた。しかし、この値は統計的に校正された確率ではない。誤解を避けるため、PoCではEvidence Tierと停止条件に置き換える。

Evidence Tier	例	扱い
High	Server-side Validator、契約、境界値Testが一致	Count Deploy候補。Blockは観測と人間承認後
Medium	Server-side Validatorのみ、またはTest不足	CountとReview
Low	Frontendのみ、推論のみ	Findingとして扱い、Blockしない
Conflict	Evidence同士が矛盾	自動処理を停止する

Deploy順序はContract Diffで変える

ApplicationとWAFの更新順序を固定すると、新規Pathや制約変更時に自己DoSを起こし得る。Contract DiffをADD、REMOVE、RELAX、TIGHTENへ分類する。

変更	安全側の順序
Path追加	WAFで先に許可し、ApplicationをDeploy
Path削除	ApplicationをDeployし、WAFの許可を削除
制約緩和	WAFを先に緩和し、ApplicationをDeploy
制約強化	Applicationを先に強化し、WAFを強化

この順序だけで安全が保証されるわけではない。旧Clientとの互換性、Blue/Green間のVersion差、Rollback時の旧Contractも含めて計画する。AWS WAF変更はStagingで検証し、ProductionではCountで観測してから限定Blockへ移す。WCUはCheckCapacityで事前確認する。⁷⁸

攻撃RequestのOrigin到達削減をPoCで測る

Source原稿のOASRはAWSや業界標準のMetricではなく、本稿で定義するPoC指標である。名称はOrigin Attack-Request Suppression Ratioとし、次のように扱う。

OASR = 1 - (
  Positive WAF導入後にOrigin到達を確認した攻撃Test Request数
  /
  BaselineでOrigin到達を確認した同一攻撃Test Request数
)

Baselineと比較時は、同一Versionの凍結Corpus、同一Transport条件、固有Request IDを使う。送信失敗、Timeout、TLS Error、WAF Log欠落は分母・分子へ黙って入れず、inconclusiveとして別集計する。

たとえばBaselineでOrigin到達を確認した10万件のうち、未定義Path 6万件、入力仕様違反2万件をWAFで遮断し、2万件がOriginへ到達したならOASRは80%となる。

注意

OASR 80%は、Cyber Riskが80%低下したことや、脆弱性が80%消えたことを意味しない。Corpus構成に依存する到達Request数の削減率であり、BOLA、認証、Business Logicなど契約内攻撃は残る。

PoCではPathのみ、PathとParameter、Body制約追加後を同一Corpusで比較すると、各Controlの限界効果を説明しやすい。

新規CVEの到達可能性を検証する

脆弱性FeedをそのままExploit生成へ渡さない。先にComponent/Version、Configuration、Protocol、認証前提、入力位置、脆弱な処理までのData Flowを構造化し、自社Applicationとの適用可能性を絞る。

AIに必須とするのは「成立条件の抽出」「自社Applicationとの対応付け」「防御確認用Test Contractの候補作成」である。動的PayloadはVendor/CERTの公開済み検証情報、非破壊Trigger、承認済みCurated Corpus、明示的に許可したAWS Security Agent Pentestの順に扱う。

Status	意味
NOT_APPLICABLE	対象Component、Version、Configurationを利用していない
NOT_REACHABLE	外部入力から脆弱Codeへの経路がないことをCode/Data FlowとTestで確認
MITIGATED	経路はあるが、WAFなどの補完統制で対象Vectorの遮断を確認。Patch不要を意味しない
REACHABLE	成立条件を満たす入力が脆弱Componentまで到達可能
UNKNOWN	Evidence不足、Telemetry gap、Test不能で判断できない

HTTP 403だけでは証跡として弱い。WAF LogのBLOCK、Test固有Request ID、ALB/Application Log、送信側のTransport結果を相関する。それでも「Origin Logにない」だけでは非到達を証明できないため、Log coverage、Clock、Sampling、別経路を確認する。完全なNOT_REACHABLEには、外部TestだけでなくCode/Data Flow上の経路不在も必要なのだ。

AWS Security AgentをValidatorとして組み込む

AWS Security AgentはBedrock/WAF生成機構の代替ではない。Agent SpaceごとにRepository、Review、Penetration Test、Findingなどを管理し、Codeと稼働Applicationを攻撃者視点で検証する第2層である。⁹

領域	自作Bedrock + Compiler	AWS Security Agent
正常仕様抽出	主担当	文脈情報として補助
Positive WAF生成	主担当	中心機能ではない
PR Security Review	補助	対応Repositoryで利用
Custom Security Requirements	Contractへ反映	Review基準として利用
Staging Pentest	中心機能ではない	主担当
BOLA/Business Logicなど	WAFだけでは困難	動的検証の対象
Finding Revalidation	独自Regression Testで補助	既存Findingを再検証
CVE Feed/SBOM照合	主担当	専用Feed照合機能とは扱わない

接続RepositoryではPR Reviewを構成でき、On-demand Code ReviewはRepository全体を対象にできる。Penetration Testは検証済みDomainを対象とし、Productionではなく本番同等のTest環境が推奨される。公式Quickstartは多くのTestが16時間以内に完了すると案内しているため、Commitごとの同期GateではなくStaging Deploy後のSlow Loopへ置く方がよい。¹⁰¹¹¹²

Finding Revalidationは、修正後に選択した既存FindingのValidation Stepsを再実行し、ActiveまたはResolvedを返す。新しい脆弱性を探索する処理ではないため、任意のCVE Test Contractを直接渡す機能として書いてはいけない。¹³

Fast LoopとSlow Loopを分ける

Fast LoopはPR/Buildごとに、変更差分、Contract、WAF Rule、IaC、WCU、Regression Testを確認する。秒〜分単位を目標にし、深い動的攻撃検証を同期させない。

Slow LoopはStaging Deploy後、CVE公開時、定期Scheduleで動かす。SBOM/VEX照合、Security Regression Test、Penetration Test、Finding Revalidationを実施し、結果を次のContract、Application修正、WAF補完統制へ戻す。

想定実装手順

1. Route数が限定され、JSON APIを持つStaging Applicationを一つ選ぶ。
2. WAF Log、CloudFront/ALB Access Log、Application Log、Test Runnerへ共通Request IDを残す。
3. Method、Path、Parameter、Body、Content-Type、型、範囲、enum、Evidence、表現可能性を持つContract Schemaを定義する。
4. OpenAPI、Route manifest、Validator、Testから決定的に抽出するStatic Extractorを作る。
5. 変更Endpointと関連Sourceだけを選ぶChange Detectorを作る。
6. CI/CD RunnerからBedrock Runtimeを呼び、Structured OutputsでContract Deltaを得る。
7. 固定FixtureでModel/Prompt変更時のAnalyzer Regression Testを行う。
8. ContractからAWS WAF Primitiveへの変換Tableと、表現損失の分類を実装する。
9. CheckCapacity、IaC validation、Rule Testを行う。
10. ADD、REMOVE、RELAX、TIGHTENを判別するDeployment Plannerを作る。
11. ProductionではCountから始め、未説明Violationと正常Requestへの影響を確認する。
12. 同一の凍結Attack CorpusでOASRを段階測定する。
13. CISA KEV、NVD、Vendor Advisory、EPSSから情報を取得し、Provenance付きで正規化する。
14. SBOM/VEX、Version、Configurationを照合し、対象外候補を先に除外する。
15. Protocol、Method、Path class、Parameter location、PreconditionをCVE Test Contractへ構造化する。
16. 承認済みTest PatternをStagingへ送り、WAF、Origin、TransportのEvidenceを相関する。
17. Agent Space、Repository接続、Security Requirements、PR Review、Staging Pentestを設定する。
18. Code FixまたはWAF補完統制後に既存FindingをRevalidateし、内部Reachability Statusと分けて記録する。
19. Contract Version、Generated WAF、Policy Diff、CI Result、WAF/Origin Log、CVE Source、Security Agent Findingを監査可能に保存する。

CI/CD全体構成

一般的なCI/CDの本線はSource、Build、Test、Staging、Security Gate、Productionへ流れる。図中のSecurity GateはAWSサービス名ではなく、生成したWAF Rule、IaC、WCU、Test結果、Findingを評価してPipelineを進めるか判断する論理Stageである。

図中	実装内容	主な実行タイミング
1〜6	Change Detector、Static Extractor、Bedrock、Contract、WAF Compiler、WCU/IaC検証、Deployment Planner、CountからBlock	PR/Build
7〜9	Vulnerability Collector、SBOM/VEX照合、CVE成立条件分析	CVE公開時、定期取得
10	CVE Test ContractとSecurity Regression Test	対象CVE検知後
11	AWS Security AgentのPentest、Finding、Revalidation	Staging、Scheduled Slow Loop
12	Reachability判定とEvidence保存	Test/Pentest完了後

Fast Loopは「変更に追従してWAF候補を作り、RuleとIaCをSecurity Gateで検証する」。Slow Loopは「新しい脆弱性が対象環境で成立するかを、許可されたStagingで試す」。両者を分けることで、通常開発の速度と深いSecurity Validationを両立しやすくするのだ。

制約・リスク

リスク	対策
AIの誤解釈で正常通信をBlock	Static抽出を優先し、Evidence Tier、Structured Outputs、Count、Regression Test、人間承認を使う
FrontendとBackendの仕様不一致	自動決定せずConflict Findingとして止める
WAF Body inspection limit超過	Oversize Handlingを明示し、Application/API Gatewayなど別Controlを併用する
不正JSONを完全に検証できない	AWS WAFを完全なSchema Validatorとせず、Application側検証を残す
BOLA/IDORなどがWAFを通過	Application Authorizationと動的Testで補完する
一つのPoCをBlockして安全と誤認	MITIGATEDとNOT_REACHABLEを分け、別Vector、別Endpoint、内部経路を確認する
Security Agent PentestがCIを遅延	PR ReviewはFast Loop、Pentest/RevalidationはSlow Loopへ分ける
Rule数/WCUが増加	Rule consolidation、Regex Pattern Set、CheckCapacity、Rule Group capacity planningを行う
補完統制をPatchの代替と誤認	MITIGATEDはPatchまでの時間を稼ぐ状態として扱う

運用上の原則

動的攻撃検証は、所有・管理権限があり、明示的に許可されたStagingまたは検証環境だけを対象にする。第三者環境へ自動的に攻撃Requestを送らない。

関連する一般原則は、AI駆動開発はWAFの「ポジティブセキュリティ」を実用段階へ進める、AI時代にWAFはどう変わるべきか、API化の次に来る問題で整理している。本稿はそのAWS実装構想と、脆弱性ReachabilityのSlow Loopへ焦点を当てた。

一次資料

補助的に参照した一次資料:

• AWS Security Agent: Product page
• AWS Security Agent: API Reference
• AWS Security Agent: Security requirements
• Amazon Bedrock: Converse API
• AWS WAFV2: FieldToMatch
• OWASP API Security Top 10:2023: API1 Broken Object Level Authorization
• OWASP Cheat Sheet Series: Insecure Direct Object Reference Prevention
• CISA: Known Exploited Vulnerabilities Catalog
• NIST: National Vulnerability Database
• FIRST: Exploit Prediction Scoring System
• OASIS: Common Security Advisory Framework Version 2.0

OASRの80%は計算方法を示すIllustrative Exampleであり、実環境の保証値ではない。実測値は、対象Applicationと凍結したAttack Corpusに対して求める必要がある。

Footnotes

1. AWS, Introducing AWS Continuum for security at machine speed ↩

2. AWS, How AWS Security Agent works ↩

3. AWS, Request components in AWS WAF ↩

4. AWS, Oversize web request components in AWS WAF ↩

5. AWS, Generate valid JSON structured output with Amazon Bedrock ↩

6. AWS, Prompt caching for faster model inference ↩

7. AWS, CheckCapacity ↩

8. AWS, Testing and tuning your AWS WAF protections ↩

9. AWS, Create an Agent Space ↩

10. AWS, Review code security findings in pull requests ↩

11. AWS, Create a code review ↩

12. AWS, Quickstart: Run a penetration test ↩

13. AWS, Revalidate penetration test findings ↩