Notifications
Clear all
Topic starter
06/07/2026 9:43 am
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.
NHIMG editorial — based on content published by Oligo Security: Proving Compliance at Runtime
By the numbers:
- 90–99% of vulnerabilities flagged by static scanners involve libraries or functions that never execute at runtime.
- FedRAMP can extend remediation SLAs from 72 hours to up to 180 days when runtime non-execution evidence supports risk adjustment.
- Runtime observability can reduce vulnerability noise by 90–99%.
Questions worth separating out
Q: How should security teams decide which vulnerabilities matter when runtime data is available?
A: Teams should prioritise vulnerabilities that are both present and executed, because runtime evidence separates theoretical exposure from active risk.
Q: Why do static scans create so much noise in modern environments?
A: Static scans overstate risk because they infer exposure from artefacts such as SBOMs, manifests, and dependency trees.
Q: How do compliance teams use runtime evidence in an audit?
A: Compliance teams use runtime evidence to show current control effectiveness, especially when proving that a vulnerable component did not execute during the review period.
Practitioner guidance
- Prioritise findings by runtime execution, not by package presence Use observed load and function-call data to decide which CVEs are genuinely in scope before opening remediation work.
- Preserve runtime evidence for audit retrieval Store timestamped records that show library load status, function invocation, and anomalous behaviour so auditors can validate control effectiveness without recreating the evidence later.
- Map scan noise to risk acceptance thresholds Define when a static finding can be downgraded because runtime non-execution is proven, and document the criteria used to make that decision.
What's in the full article
Oligo Security's full article covers the operational detail this post intentionally leaves for the source:
- How Deep Application Inspection distinguishes executed code paths from dormant dependencies in live environments.
- The specific FedRAMP, PCI DSS 4.0, and SOC 2 clauses the vendor maps runtime evidence to in audit workflows.
- Examples of how runtime findings were reduced in customer environments, including backlog reductions and compliance handling.
- Sensor overhead and deployment considerations for teams evaluating runtime inspection in production.
👉 Read Oligo Security's analysis of runtime compliance and evidence-based vulnerability management →
Runtime compliance evidence: what IAM and GRC teams need now?
Explore further
06/07/2026 9:59 am
Build-time theory is the wrong control model for runtime compliance: Static artefacts assume that the presence of a dependency means meaningful exposure, but runtime systems only create risk when code actually executes. That assumption fails in dynamic environments where libraries sit idle, execution paths vary, and audit evidence decays quickly. The implication is that compliance teams must stop treating inventory as proof of risk.
A few things that frame the scale:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
- Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months.
A question worth separating out:
Q: When should organisations treat a scan finding as lower priority?
A: Organisations should lower priority only when they can prove non-execution in the relevant production context and can retain that proof for review. If the environment is changing quickly, a stale report is not enough. The decision should be documented so it can survive audit and incident review.
👉 Read our full editorial: Runtime compliance evidence is replacing build-time theory
