SI-7(17): Runtime Application Self-protection

SI-7(17): Runtime Application Self-protection requirement means you must implement runtime controls inside your applications that detect, block, or contain exploitation attempts while the app is running. To operationalize it quickly, define which apps need RASP, deploy an approved RASP capability (agent, library, or platform feature), route events to your SIEM, and retain evidence that protection is enabled and monitored. ¹

Key takeaways:

• Scope the requirement to specific high-risk applications and runtime environments, not “all software everywhere.”
• Implement a RASP mechanism that can detect and respond during execution, then integrate alerts into incident response.
• Keep assessor-ready evidence: architecture, configuration, coverage, tuning decisions, and runtime event records. ²

A lot of programs treat “application security” as pre-release testing only: SAST, DAST, dependency scans, and a secure SDLC. SI-7(17): runtime application self-protection requirement closes a different gap. It expects you to add runtime safeguards that can observe the application from the inside (or tightly coupled to it) and take action while attacks are happening.

For a CCO, GRC lead, or Compliance Officer, the fastest path is to turn SI-7(17) into a control statement with clear scope, a named owner, an implementation procedure, and recurring evidence artifacts. Then you confirm the capability is deployed, tuned, and monitored in production-like environments where exploitation risk is real.

This page gives requirement-level implementation guidance you can assign to engineering, security operations, and application owners. It focuses on what an assessor will ask, what evidence you need to retain, and how to avoid the common failure mode for SI-7(17): claiming “we do AppSec” but lacking proof of runtime self-protection coverage and operational monitoring. ¹

Regulatory text

Excerpt (control enhancement): “Implement {{ insert: param, si-07.17_odp }} for application self-protection at runtime.” ¹

Operator interpretation: NIST is requiring a runtime mechanism that contributes to self-protection of the application during execution. The placeholder indicates an organization-defined parameter (ODP). In practice, you must define your standard for “runtime self-protection” (what capabilities count, where it must be deployed, what actions it can take, and how it is monitored) and then implement it for in-scope applications. ¹

Plain-English meaning (what SI-7(17) is really asking)

SI-7(17): runtime application self-protection requirement expects your application stack to:

1. Detect malicious or unsafe behaviors at runtime (example: injection patterns, risky deserialization flows, abnormal file or process behaviors, policy violations).
2. Respond during execution (example: block a request, terminate a session, rate limit, quarantine a container, trigger step-up auth, or fail closed for a protected action).
3. Generate actionable telemetry so Security Operations and the app team can investigate and improve detections.

This is not the same as a WAF alone. A WAF is often outside the app boundary and can be bypassed with internal calls, service-to-service traffic, or logic-level abuse. SI-7(17) is satisfied by a RASP pattern where the app, runtime, or in-process instrumentation participates directly in detection/response.

Who it applies to

Entity types: federal information systems and contractor systems handling federal data. ¹

Operational context where assessors focus:

• Internet-facing and partner-facing applications (web, API, mobile backends).
• Applications processing regulated or mission data (PII, case data, financial workflows).
• Systems with frequent deployments (CI/CD) where control drift is a realistic risk.
• Microservices and event-driven architectures where “perimeter-only” controls are incomplete.

Practical scoping rule: start with applications where exploitation yields privilege, data exfiltration, or transaction fraud. Document the rationale for what is in scope now vs. later, and tie it to your system boundary and authorization boundary documentation. ²

What you actually need to do (step-by-step)

1) Define your organization-defined parameter (ODP) for SI-7(17)

Write a short standard that answers these questions:

• Which apps must have runtime self-protection? (criteria: public exposure, data classification, criticality, threat model)
• What capabilities count? (examples: in-process instrumentation; runtime policy enforcement; exploit detection and blocking; tamper detection; runtime integrity checks)
• Where must it run? (prod only, or prod + staging; containers; serverless; managed runtimes)
• What response actions are required? (block, alert-only, session kill, quarantine)
• What logging is required and where does it go? (SIEM, ticketing, on-call paging)
• Who owns tuning and exceptions? (app owner vs. security engineering)

Deliverable: “SI-7(17) Runtime Application Self-Protection Standard” mapped to your system inventory. ¹

2) Pick an implementation pattern that fits your architecture

Common patterns that can satisfy SI-7(17) when properly deployed and monitored:

• RASP agent/library integrated into application runtime (Java, .NET, Node, etc.).
• eBPF/sidecar or host-level runtime security that can enforce app-relevant policies (best when coupled to app identity and transaction context).
• Platform-native runtime protection features in a PaaS or service mesh, if they provide in-runtime detection/response and not only edge filtering.

Selection criteria for compliance operators:

• Can it block (not just detect) in at least the highest-risk paths?
• Can it generate high-fidelity events you can prove are monitored?
• Can you show coverage across the in-scope app inventory?
• Does it support change control and configuration as code?

3) Implement coverage and prove it with an inventory-based approach

Operationalize with a simple coverage matrix:

In-scope app	Runtime environment	RASP method	Mode (block/alert)	Logging destination	Owner	Exception?

Rules for operators:

• Every in-scope app must have a row.
• “Planned” is not a control. If it’s not deployed, it’s a gap with a remediation date and risk acceptance.

4) Integrate with detection, incident response, and engineering workflows

Minimum operational hooks:

• SIEM ingestion for RASP alerts/events.
• On-call routing for high-confidence blocks and integrity violations.
• Ticket creation for tuning items and false positives.
• Playbooks that explain what responders do when RASP triggers (triage, confirm, contain, collect artifacts, decide on tuning).

This is where many programs fail audits: they install tooling but cannot show that anyone reviews alerts or that alerts drive response.

5) Tuning, exception handling, and change control

You need a controlled way to adjust rules without creating blind spots:

• Define what requires security approval (disabling protections, changing block to alert-only, adding allowlists).
• Maintain an exception register with compensating controls (example: WAF rule + additional auth + increased monitoring) and an expiration/renewal process.
• Tie config changes to your normal change management and SDLC gates.

6) Validate operation continuously

Validation approaches that produce strong evidence:

• Attack simulation in staging (safe payloads) to show detection works.
• Unit/integration tests that confirm instrumentation loads and policies are active.
• Runtime health checks that confirm agent present, policy loaded, and telemetry flowing.

For serious operators: build a “RASP coverage” dashboard from inventory + deployment telemetry so drift becomes visible quickly.

Required evidence and artifacts to retain

Keep evidence that proves both design and operating effectiveness:

Design / governance

• SI-7(17) control statement, owner, scope criteria, and ODP definition. ¹
• Architecture diagrams showing where RASP sits in the request path for representative applications.
• Approved tool selection record (what pattern, why it meets runtime self-protection).

Implementation

• App inventory with RASP coverage matrix (see table above).
• Configuration baselines (policy files, agent configs, deployment manifests, IaC snippets).
• Change records for enabling/disabling protections.

Operations

• SIEM integration proof (log source onboarding, parsing rules, sample events).
• Alert routing configuration and on-call runbooks.
• Samples of runtime events and associated tickets/incidents.
• Exception register with approvals and compensating controls.

If you use Daydream for control operations, store these as recurring evidence tasks tied to the SI-7(17) control owner so you always have “last period” artifacts ready for assessors, not a scramble.

Common exam/audit questions and hangups

Expect these questions in an assessment aligned to NIST SP 800-53:

• “Which applications are in scope for SI-7(17), and how did you decide?” ²
• “Show me runtime self-protection enabled in production for App X.” (screenshots alone are weak; prefer config + deployment proof + telemetry)
• “Is it blocking or alert-only? Who approved alert-only mode?”
• “Where do the events go, who reviews them, and show evidence of review?”
• “How do you prevent drift after deployments or runtime upgrades?”
• “How do exceptions work, and what compensating controls exist?”

Hangup to avoid: describing perimeter controls (WAF) or SDLC controls (SAST/DAST) as your answer. They can be supporting controls, but SI-7(17) is explicitly runtime self-protection.

Frequent implementation mistakes (and how to avoid them)

1. Tool installed, not operationalized.
   Fix: require SIEM integration, alert routing, and a runbook as part of “done.”

2. No scope rationale.
   Fix: document scoping criteria and map to system boundary and data sensitivity. ²

3. Alert fatigue leads to silent disablement.
   Fix: enforce change control for disabling protections; track exceptions with expirations.

4. RASP only on one language/runtime.
   Fix: define acceptable alternatives per stack (agent/library vs. platform feature) and track coverage gaps explicitly.

5. No evidence of blocking decisions.
   Fix: record which rules are in block mode, why, and what testing validated safe operation.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so treat risk as assessment-driven rather than penalty-driven. ¹

Risk implications you can describe to leadership without overstating:

• Runtime protections reduce dwell time for exploitation attempts by adding detection and containment inside the application.
• RASP telemetry improves incident investigations because it captures application context that perimeter tools often miss.
• Weak evidence (no coverage matrix, no monitoring proof) increases the chance of assessment findings even if teams believe protections exist.

Practical 30/60/90-day execution plan

First 30 days (foundation and scope)

• Assign a control owner and define the SI-7(17) ODP standard (scope criteria, acceptable patterns, logging, response actions). ¹
• Build the in-scope application inventory and draft the RASP coverage matrix.
• Select the initial RASP approach for your dominant stack and define success criteria (telemetry, blocking capability, drift control).

Next 60 days (deploy and integrate)

• Deploy runtime self-protection to the highest-risk applications first (internet-facing, sensitive workflows).
• Integrate events with SIEM and on-call, and publish the IR/runbook procedures.
• Implement change control hooks so disabling or downgrading protection requires approval and is logged.

Next 90 days (scale, tune, and harden evidence)

• Expand coverage across remaining in-scope applications; document exceptions with compensating controls.
• Tune detections based on observed false positives; record tuning decisions and approvals.
• Validate continuously (staging simulations, deployment checks) and generate assessor-ready evidence bundles in Daydream (control mapping, latest configs, sample alerts, and review records).

Frequently Asked Questions

Does a WAF satisfy si-7(17): runtime application self-protection requirement?

Usually no, because SI-7(17) is about application self-protection at runtime, which implies in-app or tightly coupled runtime enforcement. A WAF can be a compensating control for limited cases, but document the rationale and retain exception approvals. ¹

Can we run RASP in “alert-only” mode and still claim compliance?

Potentially, if your ODP allows it for certain apps and you can justify why blocking is unsafe. You still need evidence of monitoring, response, and a plan to move high-confidence detections to block mode where feasible. ²

What evidence is strongest for assessors?

A coverage matrix tied to your app inventory, configuration-as-code showing protections enabled, and SIEM records showing real runtime events with ticket/incident linkage. Screenshots help, but they rarely prove operating effectiveness by themselves.

How do we handle third-party applications we can’t instrument?

Treat them as exceptions and require compensating controls such as strong edge protections, strict authZ, segmentation, and heightened monitoring. Keep a vendor/third party record showing what you requested, what was technically possible, and the approved risk decision.

How do we prevent drift after deployments?

Make RASP enablement part of your deployment templates and CI/CD checks, then monitor for telemetry drop-offs. If your logs go quiet for an app, treat it as a control failure and investigate.

Who should own SI-7(17) day to day?

Security engineering typically owns the standard and tooling, while application owners own adoption and tuning for their services. GRC owns the control narrative, evidence cadence, and exception governance. ²

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5