RASP（Runtime Application Self-Protection、ランタイムアプリケーション自己保護）

1. 概要

A. 定義および登場背景

RASPは、アプリケーションの実行環境（ランタイム）内部にセキュリティ計装（instrumentation）を組み込み、実際のコードが実行される瞬間のデータフローと実行コンテキストを観察して攻撃を検知・遮断するセキュリティ技術である。ファイアウォールやWAFがアプリケーションの「外側」からネットワーク要求を見て攻撃か否かを推定するのに対し、RASPはアプリケーションの「内側」で、その要求が実際にどのようなSQLクエリを生成し、どのファイルを開き、どのOSコマンドを実行しようとするかを直接見て判断する。

RASPが登場した根本的な背景は、「外側から要求だけを見ても攻撃か否かを確定できない」という外郭防御の構造的限界にある。WAFはHTTPペイロードから ' OR 1=1-- のような悪性パターンを推定するが、その要求が実際に危険なSQLになるかは、アプリケーションがパラメータをどのように組み立てるかにかかっている。同じ文字列でも、正常にエスケープされれば無害でありうるし、そのままクエリに連結されれば致命的でありうる。すなわち攻撃成立の「真実」はコードが実行される地点にのみ存在し、外郭装置はその真実を見ることなくパターンのみで推定するにすぎない。RASPはまさにこの「実行地点の真実」を直接観察するために生まれた。

もう一つの背景は暗号化・回避の普遍化である。今日ではトラフィックの大部分がHTTPSで暗号化されるため、外郭装置がペイロードを見るには別途の復号が必要であり、攻撃者はエンコーディング・難読化・分割送信でシグネチャを絶えず回避する。RASPはTLS復号が終わったアプリケーション内部で動作するため暗号化の影響を受けず、ペイロードがどのように偽装されていても最終的に危険な動作（危険関数の呼び出し）に到達する瞬間を捕捉する。ガートナーが2010年代初頭にRASPの概念を提示して以来、この技術は「アプリケーションが自らを守る」という発想で外郭防御の死角を埋める層として定着した。

B. 必要性

現代のアプリケーションは数百のオープンソースライブラリやフレームワークが絡み合っており、すべての脆弱性をソースレベルで除去することは難しく、マイクロサービス・API中心のアーキテクチャが普遍化するにつれて攻撃面は内部深くへ拡散した。外郭WAFだけでは、内部サービス間呼び出し（east-west）や、デシリアライズ・SSRFのように要求文字列だけでは判断しにくい攻撃を防ぎにくい。RASPは脆弱性がコードに残っていてもその脆弱性が実際に悪用される実行の瞬間に介入して被害を遮断するため、根本パッチが配布されるまでアプリケーション自体を防御線として立てることができる。これはDevSecOps・ゼロトラストの流れにおける「防御を資産（アプリケーション）に密着させる」という要求とも合致する。

特にサプライチェーン脆弱性が相次ぐ状況で、RASPの必要性はいっそう際立つ。Log4Shellのように広く使われるライブラリのゼロデイが公開されると、組織は数百のアプリケーションに散在する脆弱なバージョンを即座に入れ替えることは難しい。このときRASPは、その脆弱性が引き起こす「危険な行為」自体を実行地点で遮断し、パッチ適用が完了するまでの空白を埋めるランタイム防御線の役割を果たす。すなわちRASPは「脆弱性をなくす」技術ではなく「脆弱性が残っている間に悪用を防ぐ」補完策として、SBOM・脆弱性管理体系とともにサプライチェーンセキュリティの実行時点の統制を担う。

C. RASPの中核的特徴

RASPの特徴は三つに集約される。第一は実行コンテキスト認識（Context-aware）であり、ネットワーク要求の見かけではなく、その要求が引き起こした実際のクエリ・ファイルアクセス・コマンド実行を見て判断するため、誤検知が根本的に少ない。第二は自己防御（Self-protection）であり、外部装置に依存せず、アプリケーション自身が自らに入ってきた攻撃を認識・対応する。第三は暗号化非依存性・回避耐性であり、TLS復号後に内部で動作するため、トラフィック暗号化やペイロード難読化の影響を受けない。この三つの特徴が結合して、RASPは「脆弱にならざるを得ないコードを実行時点で守る」アプリケーション密着型の最後の防御線となる。

この三つの特徴は、要するにRASPが「防御の位置を資産に可能な限り近づけた」ことに由来する。伝統的なセキュリティは境界（perimeter）に防御を集中させたが、クラウド・マイクロサービス環境では境界がぼやけ、攻撃面が内部へ断片化した。RASPは防御地点をネットワーク境界ではなく、保護すべき資産（アプリケーション）そのものに置き、要求がどこから来たかによらず「その要求が資産の中で危険なことをしようとする瞬間」に介入する。これは「すべてのアクセスを信頼せず、資源に密着して検証する」というゼロトラストの思考と同じ文脈であり、RASPが単なるWAFの代替ではなく、セキュリティアーキテクチャの重心移動を反映する技術であることを示す。

2. RASPの全体構造と計装方式

RASPは特定の装置ではなく、アプリケーションランタイム（JVM・.NET CLR・Node.js など）内部にセンサー（sensor）を組み込み、機微な関数呼び出しをフックする（hooking）計装アーキテクチャとして理解すべきである。以下は、要求がアプリケーション内部を流れながらRASPが介入する全体構造図である。

flowchart LR
  C["クライアント（利用者・攻撃者）"] --> WAF["WAF（外郭推定防御）"]
  WAF --> APP
  subgraph APP["アプリケーションランタイム（JVM・CLR など）"]
    REQ["要求処理ロジック"] --> SENS["RASPセンサー（関数フック）"]
    SENS --> SINK["危険地点（SQL・ファイル・コマンド・デシリアライズ）"]
  end
  SENS -->|正常| SINK
  SENS -->|攻撃判定| BLK["遮断（例外発生・要求中断）"]
  SENS --> LOG["ログ・SIEM・ダッシュボード"]

上の構造で注目すべき点は、RASPがWAFの「次」、すなわち外郭防御を通過してアプリケーション内部まで入ってきた要求を対象に動作することである。WAFが広い網で一次的にふるい分けた後にも残る「正常に見えるが実際には危険な」要求、あるいは内部サービス間呼び出しのようにそもそも外郭を経ないトラフィックまで、RASPは資産内部で最後に検証する。したがってRASPとWAFは、同じ攻撃を重複して防ぐ無駄ではなく、異なる層でたがいの死角を埋める直列配置として理解すべきである。

RASP処理の出発点は「計装（Instrumentation）」である。セキュリティセンサーをアプリケーションの危険関数（JDBCクエリ実行、Runtime.exec、ファイル入出力、デシリアライズ など）の入口に組み込んでおき、その関数が呼び出される瞬間に引数（argument）と呼び出しスタックを検査する。核心は「要求のどの入力値がこの危険関数の引数へ流れ込んだか（taint tracking、汚染追跡）」を知ることである。利用者入力が何の浄化もなくSQLクエリ文字列へ流れ込み文法構造を変えるなら、RASPはこれをインジェクションと確定し、実行直前に遮断する。外郭装置が「この文字列は怪しい」と推定するのとは異なり、RASPは「この入力が実際にクエリ構造を変えた」という事実で判定するため精度が高い。

A. 計装（Instrumentation）方式 — エージェント・ライブラリ・ハイブリッド

RASPを貫く第一の設計決定は「どのようにアプリケーション内部にセンサーを組み込むか」である。エージェント（Agent）方式は、Javaの -javaagent オプションやJVMTI、.NETのプロファイリングAPIを用いてバイトコードを起動時点で書き換え（instrument）、危険関数へフックコードを自動挿入する。アプリケーションソースをまったく修正せずに適用でき、カバレッジが広いため商用RASPの主流をなす。ただしランタイム・フレームワークのバージョンに敏感であり、バイトコード操作がまれに互換性問題を引き起こしうる。

ライブラリ・SDK方式は、開発者がセキュリティライブラリを依存に追加し、コードで明示的に呼び出すか、フィルタ・インターセプタで接続する。介入地点を開発者が統制するため予測可能だが、適用範囲が開発者の接続した地点に限定され、コード修正が必要である。ハイブリッド方式は、エージェントで広く自動計装しつつ、中核トランザクションはSDKで精密に補強して両方式の長所を結合する。実務では、レガシー・サードパーティコードが多くソース修正が難しい環境ほどエージェント方式を、セキュリティ要求が非常に高い金融の中核取引経路ほどハイブリッドを選ぶ傾向がある。

計装方式の選択は、単なる技術的嗜好ではなく、運用組織の責任境界と配備モデルを分ける決定である。エージェント方式は運用・セキュリティチームがアプリケーションの起動オプションを変えるだけで適用されるため、開発チームのコード変更なしに「セキュリティチーム主導」で展開できる一方、バイトコードの書き換えが開発チームの意図しない動作を引き起こせば責任の所在が曖昧になる。ライブラリ方式は開発チームが依存と呼び出し地点を直接管理するため「開発チーム主導」のDevSecOps文化に適するが、数百のマイクロサービス全般に一貫して適用するには共通セキュリティライブラリのバージョンガバナンスが前提となる。したがって組織は、アプリケーションポートフォリオの技術的多様性とチーム構造をあわせて考慮し計装戦略を立てなければならない。

B. 検知地点（Interception Point）と汚染追跡

第二の中核原理は「どこをフックして何を根拠に判断するか」である。RASPはアプリケーションが外部資源と接する「シンク（sink）」—DBクエリ実行、OSコマンド実行、ファイルシステムアクセス、URL接続（SSRF関連）、オブジェクトデシリアライズ、スクリプト評価（eval）など—を集中的に計装する。そしてHTTPパラメータ・ヘッダ・クッキーのような「ソース（source）」から入ってきた信頼できない入力が、中間の浄化なしにシンクへ到達したかを汚染追跡（taint tracking）でたどる。

たとえばSQLインジェクションの判定で、RASPは単にクエリ文字列に OR 1=1 があるかを見るのではない。代わりに利用者入力がクエリの「データ」領域ではなく「構造（文法）」領域を変えたかをクエリ解析で確認する。正常にバインド変数（prepared statement）に結び付けられた入力は、いかに悪性の文字列であっても構造を変えられないため通過させ、文字列連結で構造が変わった場合にのみ遮断する。この方式は「値」そのものではなく「文脈上の役割」で判断するため、WAFがやむをえず被る「悪性に見えるが実は正常な入力」への誤検知を大きく減らす。

汚染追跡の精度は、すなわちRASPの検知品質を左右する。信頼できないソースから入ってきたデータに「汚染（taint）」の印を付け、そのデータが変数のコピー・文字列連結・関数引き渡しを経てシンクへ到達するまで印が伝播するようランタイムが追跡する。途中で適切な検証・エスケープ・エンコーディング関数を経れば印を解除（sanitize）し、もはや危険とみなさない。この伝播・解除の規則をどれほど精緻にモデリングするかによって誤検知・見逃しが分かれるため、商用RASPは主要なフレームワーク・ライブラリの浄化関数リストをあらかじめ内蔵し継続的に更新する。しかしカスタムの浄化ロジックや非標準のデータフローは追跡が途切れることがあり、組織固有の浄化パターンをルールで補強するチューニングが必要である。

C. 動作モード — モニタリングと遮断

第三の軸は「検知した攻撃をどのように処理するか」である。モニタリング（Monitoring）・検知モードは、攻撃を検知してログ・アラートのみ残し、要求は通過させる。導入初期、誤検知で正常取引が止まる事故を避けるため、一定期間このモードで観察することが定石である。遮断（Blocking）・保護モードは、攻撃判定時に該当する危険関数呼び出しに例外を発生させるか、要求処理を中断して被害を実際に防ぐ。遮断方式も「該当作業のみ拒否」するか「セッション・要求全体を終了」するかに細分でき、仮想パッチのように特定CVEへのピンポイントルールを即座に配備する運用も可能である。実務ではWAFと同様、検知モードで十分にチューニングした後、信頼水準が確保されたルールから遮断へ切り替える漸進的な成熟過程に従う。

遮断の方式にも設計判断が介在する。危険関数呼び出しに例外を投げて「該当作業のみ」失敗させれば、アプリケーションがこれを正常な誤りのように処理してサービスを継続できるが、攻撃者が反復試行で別の経路を探る余地が残る。逆に要求・セッション全体を即座に終了すれば防御は強力だが、誤検知時に正常利用者の取引がまるごと断たれる。したがって成熟した運用は危険度に応じて遮断の強度を差別化する。たとえばリモートコード実行につながりうるデシリアライズ・コマンド挿入はセッション終了で強く対応し、比較的影響が限定的なパストラバーサルの試みは該当作業のみ拒否しつつログを強化する、といった具合である。このようにRASPは「検知できる」を超えて「どう対応するか」をサービス特性に合わせて設計するポリシーの問題である。

D. RASP導入・運用ライフサイクル

RASPは導入時点よりも導入後の運用が成否を分けるという点でWAFに似ており、実務の定着手順はおおむね次の流れに従う。

1. 対象選定・計装適用: 保護価値の高いアプリケーションを選別し、エージェント／ライブラリ方式でセンサーを起動環境へ適用する。このときランタイム・フレームワークのバージョン互換性をまず検証する。
2. 性能ベースライン測定: センサー適用の前後の応答時間・CPU・メモリを負荷テストで実測し、オーバーヘッドが許容範囲かを確認し、過負荷経路は計装範囲から除外する。
3. 検知専用モード運用: ルールを遮断ではなくログのみで一定期間稼働し、実トラフィックでどの正常動作がルールに引っかかるか（誤検知候補）を観察する。
4. 誤検知チューニング・遮断切替: 観察した誤検知を分析して浄化規則・例外を調整し、信頼水準が確保されたルールから危険度に合う遮断強度へ順次切り替える。
5. 継続更新・連携: 新規CVE・攻撃トレンドに合わせてルールを更新し、ログをSIEM・SOARと連携して検知から対応まで自動化し、センサーバージョンを構成管理で追跡する。

この循環で核心は、WAFと同様に「遮断を急がないこと」である。検証なしに全面遮断から始めれば正常取引が止まってサービス信頼が崩れ、運用チームはセンサーをまるごと切ってしまう最悪の選択へ追い込まれる。RASPもまた「設置すれば終わり」ではなく、継続的なチューニングと性能観察を前提とする運用型の統制として扱わなければならない。

3. RASPの検知・対応処理フローと防御対象

RASPが実際に攻撃をどのように捕捉するか、一つの要求が内部で判定されるプロセス詳細図を見る。

sequenceDiagram
  participant U as 利用者・攻撃者
  participant A as アプリケーションロジック
  participant R as RASPセンサー
  participant D as 危険地点（DB・OS・ファイル）
  U->>A: HTTP要求（入力値を含む）
  A->>A: ビジネスロジック実行
  A->>R: 危険関数呼び出しのフック（hook）
  R->>R: "汚染追跡・文脈分析（入力→構造変更？）"
  alt 攻撃と判定
    R-->>A: "例外発生・呼び出し遮断"
    R->>R: ログ・アラート（SIEM）
  else 正常
    R->>D: 本来の作業を実行
    D-->>A: 結果を返す
  end

A. 主な防御対象の攻撃

RASPが特に強みを見せる領域は、要求文字列だけでは判断が難しい実行時点の攻撃である。SQLインジェクションは先に説明したクエリ構造の変更有無で、OSコマンド挿入（Command Injection）は Runtime.exec・ProcessBuilder 呼び出しの引数へ利用者入力が流れ込んだかで判定する。パストラバーサル（Path Traversal）はファイルアクセス関数へ ../ を含む利用者入力が到達したか、SSRFは外部接続先のURLが利用者入力で決まるかを見る。特に安全でないデシリアライズ（Insecure Deserialization）は、ペイロードが暗号化・難読化されるとWAFでは検知が非常に難しいが、RASPはデシリアライズ過程で危険なクラス（gadget）がロード・実行される瞬間を直接捕捉できる。

実戦でRASPの価値を証明した代表的事例がLog4Shell（CVE-2021-44228）である。2021年末にApache Log4jのJNDI参照脆弱性が公開されると、攻撃者たちは ${jndi:ldap://...} 文字列を ${${lower:j}ndi: のように細かく分割してWAFシグネチャを素早く回避した。しかしRASPは文字列の見かけではなく、アプリケーションが実際に外部LDAP/RMIサーバへJNDI参照を試みたり遠隔クラスをロードしようとする「行為」そのものを実行地点で遮断できたため、難読化の変種に関わらず同一に対応した。これは「パターンではなく行為で防ぐ」RASPの本質を象徴的に示した出来事としてよく引用される（ただしカバレッジは計装された経路に限定されるため、RASPがすべての変種を自動的に防ぐと断定することはできない）。

一つの要求の処理過程を具体化すると理解が明確になる。利用者が掲示板の検索窓に 製品名'); DROP TABLE users;-- を入力したとしよう。アプリケーションがこの値をバインドなしにクエリ文字列へ連結すると、JDBC実行の直前にRASPセンサーが呼び出しをフックし、元のクエリの文法構造（トークンツリー）と利用者入力が挿入された後の構造を比較する。入力により DROP TABLE という新たな文の構造が生じたことを確認すると、RASPはこれをインジェクションと確定し、クエリ実行に例外を投げてDBに達する前に中断させ、元の入力・呼び出しスタック・一致ルールをログに残す。外郭WAFが「怪しい文字列」と推定するのとは異なり、RASPは「クエリ構造が実際に変わった」という事実で判断する点が決定的な違いである。

B. RASPと類似・連携技術の比較

RASPは単独では完結せず、隣接技術との役割区分が重要である。以下の表は比較のまとめであるが、差が生じる理由もあわせて理解しなければならない。

区分	動作位置・時点	判断根拠	主目的	RASPとの関係
WAF	アプリ外・要求時点	要求ペイロードのパターン	外郭攻撃の遮断	広範な一次防御、相互補完
RASP	アプリ内・実行時点	実際の実行コンテキスト・汚染追跡	実行時点の攻撃遮断	精密な最後の防御
SAST	開発段階・静的	ソースコード解析	配備前の脆弱性発見	事前除去（予防）
DAST	テスト段階・動的	外部模擬攻撃の応答	配備前の脆弱性発見	事前発見（予防）
IAST	テスト段階・計装	内部計装（RASPと同種）	テスト中の脆弱性発見	計装技術を共有、目的は相違

最も混同されるのがIAST（Interactive Application Security Testing）との関係である。IASTはRASPと同一の計装・汚染追跡技術を使うが、目的が異なる。IASTはQA・テスト段階で脆弱性を「発見・報告」するのに使われ、RASPは運用段階で攻撃を「遮断」するのに使われる。すなわち同じエンジンをテストに使えばIAST、運用防御に使えばRASPになるわけである。多くの商用製品が一つの計装エンジンでIASTとRASPをともに提供する理由がここにある。

WAFとRASPの決定的な差は「外側から推定するか、内側で確認するか」である。WAFはすべての要求を広く一次的にふるい分けるが、アプリケーション内部ロジックを知らないため誤検知・見逃しが避けられない。RASPは狭いが深く、実際の実行結果で判断して精度が高い。両者は競争ではなく多層防御（Defense in Depth）の関係で、WAFで外郭を広く防ぎ、RASPで中核トランザクションを精密に補強し、そこにSAST/DAST/IASTのような開発段階の統制が加わるとき、アプリケーションセキュリティが完結する。

4. 深化 — 標準・市場動向とADRへの拡張

近年のアプリケーションセキュリティ市場で、RASPは独立製品から可観測性（observability）と結合したランタイムセキュリティプラットフォームへ再編されつつある。ガートナーはRASPの実行地点可視性の概念を拡張し、ADR（Application Detection and Response、アプリケーション検知・対応）を新興カテゴリとして提示するが、これはアプリケーションランタイムで収集した攻撃・行為データをEDR・XDRと連携し、検知から対応まで自動化しようとする流れである。すなわちRASPが「防ぐ」にとどまらず、攻撃の前後の文脈を追跡しセキュリティ運用（SOC）と結び付く方向へ進化している。

市場ではContrast Security、Imperva（旧Prevoty）、Dynatrace、Waratek などの商用ソリューションとともに、OpenRASP のようなオープンソース実装がJava・.NET・PHP など多様なランタイムを支援して裾野を広げてきた。特に多くの製品が一つの計装エンジンでテスト段階のIASTと運用段階のRASPをともに提供するが、これは「Shift-Left（開発中に発見）」と「Shift-Right（運用中に防御）」を単一の技術軸で結ぼうとする市場の方向性を示す。ただしポリグロットなマイクロサービスが普遍化するにつれ、言語別センサーを一貫して運用するガバナンスが新たな課題として浮上した。

標準・規制の面でもRASPの位置づけが上がっている。OWASPはRASPをアプリケーション防御技術として紹介し、デシリアライズ・インジェクションなどOWASP Top 10の脅威に対するランタイム緩和策として言及する。またPCI DSS v4.0は決済ページの改ざん検知と実行時点の保護を強化する方向で改定され、RASP類のランタイム保護がコンプライアンス対応手段として再注目されている。クラウドネイティブ環境では、コンテナ・サーバレスランタイム内に軽量センサーを組み込みワークロード保護（CWPP）と結合する試みが増えており、バイトコード計装の代替としてeBPFベースのランタイム可視性を活用しカーネルレベルでアプリケーション行為を観察する手法も台頭する。

想定される出題方向としては、▲WAFとRASPの動作原理・判断根拠の差を説明し多層防御の設計を提示せよ、▲RASPの計装方式（エージェント vs ライブラリ）のトレードオフを論ぜよ、▲Log4Shell などの事例でRASPの強みと限界を論ぜよ、▲IAST・DAST・SAST・RASPをライフサイクル（SDLC）の観点で比較しDevSecOps統合方案を提示せよ、などが有力である。

5. 考慮事項および示唆（技術士の観点）

RASPを成功裏に定着させるには、「製品導入」ではなく「性能・安定性・運用プロセス」のバランスの観点から接近しなければならない。技術士の答案では、次のトレードオフと戦略をあわせて論ずべきである。

• 性能オーバーヘッドと安定性のバランス: RASPはアプリケーション内部で関数呼び出しごとに検査を行うため、遅延・CPU負担が発生する。一般には一桁%程度のオーバーヘッドとして知られるが、トラフィック特性・計装範囲により偏差が大きいため、必ず負荷テストで実測し、中核経路のみを選別計装する戦略が必要である。バイトコード操作がアプリケーション安定性に影響しうるため、障害時にセキュリティより可用性を優先するか（フェイルオープン）、セキュリティを優先するか（フェイルクローズ）をサービス特性に合わせて明確に定義すべきである。

• カバレッジの限界の認識: RASPは計装されたランタイム・関数に限って防御するため、ネイティブコード・未計装フレームワーク・外部呼び出しは死角として残る。したがってRASPを万能防御と誤認せず、WAF（外郭）・セキュアコーディング・SAST/DAST（事前除去）と結合した多層防御の一層として位置づけるべきである。RASPがあるという理由でコードセキュリティを怠れば、かえって危険が蓄積する。

• 言語・フレームワーク依存性と運用負担: RASPはJVM・.NET など特定ランタイムに強く結合し、ポリグロット（多言語）マイクロサービス環境では言語別センサーを個別に管理する負担がある。ランタイム・フレームワークのアップグレード時にセンサー互換性を継続検証せねばならず、センサーバージョン・ルールを構成管理（Policy as Code）体系の中で追跡可能に保ってこそ監査・変更管理が成立する。

• DevSecOps・可観測性との統合: RASPは開発段階のIASTと計装エンジンを共有するため、「Shift-Left（事前発見）」と「Shift-Right（運用防御）」を一つの技術軸でつなぐ接点となる。RASPのログをSIEM・SOAR・XDRと連携すれば検知から対応まで自動化（プレイブック）が可能であり、ADRの流れと結合して攻撃の前後の文脈を追跡できる。CI/CDパイプラインでセンサー配備・ルール検証を自動化することが運用成熟の核心である。

• 漸進的適用と誤検知最小化の戦略: RASPはWAFより誤検知が少ないが0ではない。新規ルール・センサーは必ず検知専用モードで十分に観察し、正常業務が止まらないことを確認したうえで遮断へ切り替え、遮断範囲（該当作業のみ／セッション全体）を危険度に応じて差別適用すべきである。検証なしの全面遮断は正常取引を止め、運用チームがセンサーを切ってしまう最悪の選択へ追い込みうる。

• 連携技術および展望: RASPはゼロトラストの「資産密着防御」原則と合致し、CWPP・eBPF・ADRと融合しながらランタイムセキュリティプラットフォームへ収束しつつある。生成AIを活用した攻撃の自動変種が増えるほど、見かけではなく「行為」で判断するRASPの価値は大きくなる見通しである。ただし計装に基づく判定の根拠を運用者が理解・監査できるよう、説明可能性とログ体系をあわせて設計することが今後の課題として残る。

参考資料

• OWASP, "Runtime Application Self-Protection", https://owasp.org/www-community/controls/Runtime_Application_Self_Protection
• Gartner, "Application Detection and Response (ADR)" および "Runtime Application Self-Protection", https://www.gartner.com/en/information-technology/glossary/runtime-application-self-protection-rasp
• MITRE, "CVE-2021-44228 (Log4Shell)", https://nvd.nist.gov/vuln/detail/CVE-2021-44228
• PCI Security Standards Council, "PCI DSS v4.0", https://www.pcisecuritystandards.org/

---

一言まとめ: RASPはアプリケーションランタイム内部にセンサーを組み込み、利用者入力が危険関数の実行構造を変える瞬間を汚染追跡で捕捉・遮断する自己保護技術であり、暗号化・難読化に関わらず実行地点の「行為」で判断して誤検知が少ない一方、性能オーバーヘッド・言語依存・カバレッジの限界があるため、WAF・SAST/DASTと結合した多層防御の精密な層として運用すべきである。