A runtime finding is a security issue discovered in a live or pre-production running application, usually through active testing rather than static analysis. These findings are valuable because they point to exploitable behaviour, but they are most useful when linked to code, owners, and surrounding risk context for remediation.
Expanded Definition
Runtime findings are security observations made against an application while it is executing, whether in a staging environment or a live service. They differ from static code findings because they expose behaviour that only becomes visible when configuration, inputs, dependencies, authentication flows, or state transitions are actually exercised. That makes them especially valuable for uncovering issues such as unsafe deserialisation paths, access control failures, session handling flaws, or injection conditions that do not surface reliably in source-only review.
In practice, a runtime finding is most useful when it is tied to evidence: the request, response, stack trace, process state, affected asset, and the business function that was reached. NIST’s NIST Cybersecurity Framework 2.0 is relevant here because it frames security outcomes around identification, protection, detection, response, and recovery, which is the same lifecycle teams need when turning a runtime signal into a remediated issue. Definitions vary across vendors on whether a runtime finding must come from dynamic analysis, a production monitor, or an application security test, so the term should be read as evidence of executed behaviour rather than as a narrow tool category. The most common misapplication is treating every runtime alert as a confirmed vulnerability, which occurs when teams skip validation and owner mapping before assigning remediation priority.
Examples and Use Cases
Implementing runtime finding workflows rigorously often introduces triage overhead, requiring organisations to balance fast exploitation insight against the cost of validating noisy or environment-specific results.
- A dynamic scan against a payment workflow detects an unauthorised state change that only appears after multi-step form submission.
- Application instrumentation shows an API returning sensitive object data after a role switch, confirming an access control issue only visible during execution.
- A pre-production test reveals command injection triggered by a runtime-only configuration path that static analysis did not flag.
- Security testing identifies secret exposure in memory or logs during startup, which points to operational handling problems rather than source code alone.
- Findings are correlated to an owning service team and ticketed with reproduction steps, affected endpoint, and risk context so remediation can be tracked.
For teams building repeatable triage processes, the NIST CSF control perspective helps anchor these findings to real response workflows rather than treating them as isolated test artefacts. A runtime finding becomes actionable only when it can be reproduced, scoped, and assigned to the right control owner.
Why It Matters for Security Teams
Runtime findings matter because they close the gap between theoretical weakness and demonstrable exposure. Many issues appear low confidence in source review but become urgent once an attacker can reach them through a real request chain, authenticated session, or misconfigured service path. That makes runtime evidence essential for prioritisation, especially in applications with layered identity checks, API gateways, feature flags, or agentic workflows where execution context changes the threat profile.
This term also intersects with identity and non-human access because a runtime finding may expose token misuse, overbroad service credentials, or broken authorisation in machine-to-machine flows. Where organisations use automated agents, the finding may reveal that an AI agent or service account can perform an action beyond its intended scope, which is a governance issue as much as a vulnerability. The operational value of a runtime finding is that it can be linked to impact, not just weakness, which helps security teams decide whether to patch, contain, or redesign a workflow. The NIST Cybersecurity Framework 2.0 is useful here because it encourages disciplined handling of detection and response, not just discovery. Organisations typically encounter the true cost of runtime findings only after an exposed path is exercised in production, at which point remediation, rollback, and verification become operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST AI RMF and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM | Runtime findings arise from monitoring and testing executed system behaviour. |
| NIST SP 800-53 Rev 5 | RA-5 | Vulnerability scanning and assessment support validating findings in running systems. |
| NIST AI RMF | GOVERN | AI systems need governance over runtime evaluation and issue escalation. |
| OWASP Non-Human Identity Top 10 | Runtime findings often expose service credential and token abuse in NHI paths. | |
| NIST SP 800-63 | AAL2 | Runtime issues may reveal weaknesses in authentication assurance and session handling. |
Correlate runtime findings to detection processes and validate them through monitored evidence.
Related resources from NHI Mgmt Group
- What is the difference between runtime protection and NHI lifecycle management?
- What is the difference between code scanning and runtime identity monitoring?
- Why are runtime environments riskier than repository scans for NHI governance?
- When should organisations use runtime authorization for AI agents?
