TL;DR: Static scans produce 90 to 99 percent noise because they flag libraries and functions that never execute, while runtime inspection shows which code is actually live in production, according to Oligo Security. That shift turns compliance from assumption-based paperwork into evidence-based decision-making, especially where FedRAMP, PCI DSS 4.0, and SOC 2 depend on current execution context.
At a glance
What this is: This is an analysis of why runtime evidence is overtaking build-time artefacts in compliance, because static scans and SBOMs often describe what was shipped rather than what is actually running.
Why it matters: For IAM, GRC, and security teams, the shift matters because audit evidence based on execution context is more defensible than inventory alone when access, exposure, and remediation decisions depend on current system behaviour.
Context
Compliance evidence is only useful when it reflects the system state that auditors and defenders are actually judging. Build-time artefacts such as SBOMs, scan reports, and patch tickets can describe what was packaged, but they do not prove what executed in production.
That gap matters most in dynamic environments where a vulnerable library may exist in a dependency tree without ever running, or may run only in limited code paths. In identity and security programmes, this is the same problem that appears whenever governance relies on static assumptions instead of observed behaviour.
The article frames runtime evidence as the answer to that mismatch. For compliance-led teams, the practical issue is not whether a control exists on paper, but whether it can prove current exposure, execution, and exploitability at audit time.
Key questions
Q: What breaks when compliance is based only on build-time scans?
A: Teams end up certifying theoretical exposure instead of actual execution. Static reports can show that a vulnerable component exists, but they cannot prove whether the risky function ever runs in production. That creates noisy backlogs, stale audit evidence, and remediation work that may not reduce real risk.
Q: Why does runtime evidence matter for FedRAMP, PCI DSS 4.0, and SOC 2?
A: Because those frameworks depend on defensible proof that controls reflect current operating conditions. Runtime evidence shows what was loaded, executed, or anomalous in production, which is far more useful than a point-in-time inventory when auditors ask whether a vulnerability was actually relevant.
Q: How can security teams tell whether a static vulnerability finding is actually relevant?
A: They should check whether the vulnerable library is loaded, whether the risky function is called, and whether runtime behaviour supports real exploitability. If execution never occurs in production, the finding may be technically true but operationally low value, and it should be treated accordingly.
Q: What should organisations do when audit evidence is stale by the time review starts?
A: Move from document collection to continuous evidence capture. Runtime telemetry gives auditors fresh proof of current execution, reduces rework, and makes it easier to justify risk-based decisions when the environment has changed since the scan, ticket, or SBOM was produced.
Technical breakdown
Runtime evidence versus build-time artefacts
Build-time artefacts capture a software package at release, not the state of the application after deployment. A static scanner can only infer exposure from the presence of code, dependencies, or configurations, which is why it often overstates risk when vulnerable functions never execute. Runtime evidence changes the evidence model by observing actual execution, so the question becomes whether a library was loaded, whether a function was called, and whether behaviour changed in production. That distinction matters because compliance findings become defensible facts instead of assumptions derived from inventory.
Practical implication: Treat runtime observation as the evidentiary layer that validates or invalidates static findings before they enter audit and remediation workflows.
Why static compliance noise breaks operational trust
The article argues that static scanning creates 90 to 99 percent noise because it treats theoretical reachability as proof of risk. That noise has a governance cost: teams spend time triaging alerts that are technically possible but operationally irrelevant, while auditors receive stale artefacts that may already be out of date. Runtime compliance evidence reverses the burden of proof by showing whether the vulnerable path is active. In practice, that is the difference between a paper finding and an auditable execution record.
Practical implication: Use runtime evidence to suppress non-actionable findings and focus remediation capacity on code that is genuinely live.
How runtime evidence supports FedRAMP, PCI DSS 4.0, and SOC 2
The compliance value of runtime evidence comes from its ability to support current-state judgments about exposure and monitoring. FedRAMP can use non-execution evidence to justify longer remediation windows when a vulnerability is not active in production. PCI DSS 4.0 benefits because risk-ranked vulnerability management depends on more than CVSS style theoretical severity. SOC 2 is also implicated because monitoring, logging, and operational control require evidence of what actually happened in the environment, not a snapshot assembled after the fact.
Practical implication: Map runtime telemetry to the specific control evidence your auditors ask for, rather than relying on static scan exports as a substitute.
Breaches seen in the wild
- ShadowRay 2024: Attackers took over internet-exposed Ray AI clusters via the disputed CVE-2023-48022, exposing cloud keys, AI API tokens and GPU compute.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Runtime evidence is becoming the decisive compliance control because build-time theory cannot prove present risk. Static inventories, SBOMs, and scan reports are useful only up to the moment the application changes or the runtime path diverges from what was packaged. Once execution becomes the evidentiary standard, compliance stops being an argument about what might be vulnerable and becomes a question of what is demonstrably live. The practitioner takeaway is that evidence quality now matters as much as policy coverage.
Build-time theory creates a compliance backlog because it confuses theoretical reachability with operational exposure. The article's 90 to 99 percent noise claim is not just a tooling complaint, it is a governance signal that triage volume is being driven by assumptions rather than execution facts. That kind of noise weakens audit credibility and pushes teams into remediation churn that does not reduce real exposure. The practitioner takeaway is that evidence models must be tuned to runtime reality, not dependency presence.
Runtime compliance evidence is a named governance pattern worth adopting as a control concept. It means the organisation can show, from live execution, which code paths were active, which were inert, and which anomalies deserve escalation. That is materially different from an inventory-first model because the control assertion is grounded in observed behaviour. The practitioner takeaway is to treat runtime proof as the source of truth for audit readiness and exposure prioritisation.
FedRAMP, PCI DSS 4.0, and SOC 2 all assume environments can be observed at the point of operation, not only at build time. The article shows that assumption still underpins modern assurance programmes even as application behaviour becomes more dynamic. Where the evidence is stale, the governance decision is stale too. The practitioner takeaway is to align compliance testing, exception handling, and backlog prioritisation to current execution evidence.
Control maturity now depends on whether teams can convert runtime telemetry into repeatable audit artefacts. The strategic shift is not simply from static to dynamic scanning, but from periodic proof creation to continuous proof capture. That changes how compliance, AppSec, and GRC teams collaborate because the evidence becomes operational output, not a once-a-year audit project. The practitioner takeaway is to build evidence pipelines, not just remediation queues.
What this signals
Runtime compliance evidence: compliance programmes are shifting from static artefacts to live execution proof, which changes what counts as defensible audit support. Teams that still treat SBOMs and scan outputs as primary evidence will keep producing stale findings that do not map cleanly to current exposure.
The operational signal is straightforward: triage quality improves when the evidence layer can say whether code was actually loaded and executed. That turns compliance into a continuous control conversation instead of a retrospective paperwork exercise.
For practitioners
- Prioritise runtime evidence over static artefacts Use live execution data to decide which findings are actually in scope before feeding them into audit, remediation, or exception processes.
- Map evidence to framework-specific controls Tie non-execution, loaded library status, and anomalous behaviour to the exact compliance clauses your auditors will test, rather than presenting raw scan output.
- Reduce noisy findings with execution context Suppress theoretical vulnerabilities that never run in production and redirect engineering effort to code paths that are demonstrably active.
- Use runtime proof in remediation prioritisation Rank backlog items by observed execution and exploitability so that operational effort tracks real exposure instead of dependency presence.
Key takeaways
- Static compliance artefacts are increasingly poor evidence because they describe build-time states rather than the code paths that are actually active in production.
- The article's core risk signal is noise, with static scanners reportedly flagging large volumes of libraries and functions that never execute.
- Runtime evidence changes prioritisation by giving GRC and security teams a defensible basis for scope, remediation, and audit readiness.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while SOC 2 (AICPA) defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest protection | Runtime evidence helps verify current-state protection and exposure rather than relying on stale build artefacts. |
| DE.CM-09 — Vulnerability scanning | The article is about replacing noisy static scanning with runtime evidence that improves vulnerability relevance. | |
| Recommendation — Use current execution evidence to validate whether runtime exposure controls are operating as intended. Augment vulnerability scanning with runtime telemetry so triage reflects live exploitability, not dependency presence. | ||
| NIST SP 800-53 Rev 5 | CA-7 — Continuous Monitoring | The core theme is continuous observation of production systems to produce defensible compliance evidence. |
| RA-5 — Vulnerability Monitoring and Scanning | The article contrasts static vulnerability results with runtime proof of actual exposure. | |
| Recommendation — Apply continuous monitoring to collect runtime evidence that supports audit and risk decisions. Use vulnerability monitoring to separate theoretical findings from issues that are truly active in production. | ||
| SOC 2 (AICPA) | CC7.2 — Monitor system components and detect anomalies | SOC 2 monitoring expectations align directly with runtime evidence and anomaly detection in production. |
| Recommendation — Collect timestamped runtime evidence that demonstrates monitoring and anomaly detection over production components. | ||
Key terms
- Runtime compliance evidence: Evidence captured from live system behaviour that can be used to support compliance, audit, and risk decisions. It replaces assumptions about what might be running with observed facts about what did run, what was loaded, and what anomalies appeared in production.
- Build-time theory: A compliance and security model that relies on packaged artefacts, scan output, or inventories produced before deployment. It is useful for baseline documentation, but it becomes unreliable when it is treated as proof of current exposure or runtime relevance.
- Deep Application Inspection: Deep Application Inspection is an execution-aware inspection approach that observes application behavior at the library and function level. It helps teams identify which code paths run in production, so prioritization can focus on verifiable risk rather than on static assumptions that may never materialize.
- Non-execution evidence: Proof that a vulnerable component or function was not invoked in production during the relevant period. For compliance teams, this can reduce false positives and help justify risk-based remediation decisions when static tools overstate exposure.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on July 6, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org