Teams end up with too many false positives and spend time chasing issues that are not actually exploitable in their environment. A package may appear vulnerable, but if the application never uses that code path, it may not warrant urgent action. Without runtime context, scanners can create noise, slow developers down, and distract from risks that can really be reached.
Why This Matters for Security Teams
Container scanning only becomes useful when findings are sorted by whether they can be reached in the deployed workload. Without that filter, teams treat every vulnerable library as equally urgent, even when the affected function is never loaded or the container is blocked by policy. That creates alert fatigue, slows remediation, and can distort risk decisions across engineering and security.
Practitioner guidance increasingly aligns with control objectives such as NIST SP 800-53 Rev 5 Security and Privacy Controls, which emphasize continuous monitoring, risk-based response, and configuration accountability rather than blind ticket generation. In a mature program, a scanner is not judged by the size of its output, but by whether it helps security teams prioritize exploitable exposure in the current deployment state.
In practice, many security teams encounter the cost of poor tuning only after developers have already lost confidence in the scanner and started ignoring high-volume findings.
How It Works in Practice
Reachability tuning asks a simple question: can the vulnerable code actually be executed from the deployed application path? runtime context goes further and checks whether the workload is running with the conditions needed for exploitation, such as exposed ports, mounted secrets, network reachability, privilege level, or service-to-service trust relationships. Together, these signals help separate theoretical vulnerability from actionable risk.
Effective programs usually combine several layers:
- Software composition analysis to identify vulnerable packages and versions.
- Call graph or static analysis to estimate whether the vulnerable function is referenced.
- Runtime telemetry to confirm what code paths, processes, and network edges are active in production.
- Policy gates that use severity plus exposure instead of severity alone.
- Exception handling for libraries that are bundled but unreachable in the current build or runtime profile.
This is especially important in containerized systems because images are often reused across environments, patched asynchronously, or deployed with different entrypoints and environment variables. A finding that looks severe in the image repository may be irrelevant in a hardened runtime where the package is never invoked. Conversely, a medium-severity issue may become urgent if the workload is internet-facing, runs with elevated privileges, or handles sensitive tokens.
Security teams should align scanning with deployment metadata, orchestration data, and alert routing so that developers receive only the findings that matter for their service. Guidance from CIS Controls also supports asset visibility and secure configuration as prerequisites for meaningful vulnerability management. These controls tend to break down when images are promoted across multiple clusters with inconsistent environment variables and no reliable inventory of what code paths are actually enabled.
Common Variations and Edge Cases
Tighter reachability analysis often increases operational overhead, requiring organisations to balance better prioritisation against scan complexity and pipeline latency. That tradeoff is worth it for high-volume container estates, but best practice is evolving for how much runtime evidence should be required before suppressing a finding.
Some teams use repository-only scanning for early developer feedback and reserve reachability and runtime enrichment for pre-production or production gates. Others apply stricter tuning only to internet-facing services, privileged workloads, or applications that process regulated data. There is no universal standard for this yet, and the right threshold depends on release speed, blast radius, and how much runtime observability the platform already provides.
Edge cases matter. A library may be unreachable today but become exploitable after a feature flag is enabled, a sidecar is added, or an attacker gains partial code execution. Likewise, a package may be unreachable in one image variant but fully reachable in another because of different startup commands or mounted plugins. That is why suppression rules should be time-bound, reviewed, and tied to deployment context rather than accepted as permanent.
For teams building governance around software supply chain risk, the practical aim is not to eliminate all findings. It is to make sure the scanner reflects what an attacker can actually reach in the running container, not just what exists somewhere in the image layer.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS-Controls set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-1 | Asset visibility is required to know which container findings matter. |
| MITRE ATT&CK | T1611 | Container-related runtime abuse often depends on execution context. |
| CIS-Controls | 7 | Continuous vulnerability management needs environment-aware prioritisation. |
Maintain accurate workload inventories before deciding which vulnerabilities are truly in scope.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
