When reachability analysis stops at pre-production, teams can miss how software behaves after deployment. Packages may be unused in testing but loaded in production, and some threats only emerge at runtime, including malware or exploits executed in memory. The result is weaker prioritization and blind spots where real exposure appears only after release.
Why pre-production checks alone give a false sense of safety
reachability analysis is meant to separate code that is merely present from code that can actually be executed, which makes it useful for prioritisation. The problem is that build-time or test-time checks only see a narrow slice of behaviour. A package can look unreachable in CI yet become reachable through feature flags, new configurations, dynamic loading, runtime plugins, or environment-specific paths after release. That gap matters because the security team may deprioritise a component that later becomes part of the real attack surface. The NIST SP 800-53 Rev 5 Security and Privacy Controls guidance is useful here because it treats control effectiveness as an operational issue, not just a pre-deployment checkbox.
In practice, many teams discover this mismatch only after production behaviour, not test coverage, reveals that the analysis was incomplete.
How runtime behaviour changes the reachability picture
Pre-production analysis usually has better source visibility than runtime operations, but it cannot reliably account for every execution path that appears once software is deployed. Modern applications often change shape in production through configuration, dependency resolution, service discovery, container orchestration, or code paths that are dormant until a specific input, user role, or external event activates them. That means reachability is not just a property of the codebase; it is a property of the deployed system and its operating context.
For security teams, the practical failure is not that pre-production checks are useless, but that they are incomplete if treated as the only authority. A package can be non-reachable in a test suite and still matter if it is loaded by a runtime mechanism that the test environment never exercised. Likewise, exploitability may depend on in-memory execution, reflective loading, or other conditions that only exist after deployment. When that happens, the analysis underestimates exposure and can distort patching priority, exception handling, and risk acceptance decisions.
A useful way to think about this is to ask whether the analysis covers the same execution environment that attackers would see. If the answer is no, then the reachability result is at best provisional. Good practice is to combine pre-production signals with production-aware evidence such as runtime inventory, actual dependency loading, and monitoring of executed paths. This is especially important when teams rely on SBOM-style data or vulnerability scoring to decide what to fix first, because the ranking is only as good as the execution context behind it.
- Check whether runtime configuration can enable code paths that are absent in testing.
- Verify whether dynamically loaded components, plugins, or optional modules are part of production execution.
- Correlate reachability results with deployed asset and dependency inventories rather than build outputs alone.
Where organisations stop at pre-production checks, the main breakdown is not detection failure in the lab but misclassification of what is actually live in production.
When the analysis breaks down in real environments
Tighter pre-release validation often improves hygiene, but it can also create overhead if teams treat every inferred execution path as equally trustworthy, requiring organisations to balance speed against production reality. The answer becomes less reliable when software uses late binding, remote configuration, generated code, containers with different images than staging, or environment-specific secrets and access rules that change which modules load.
This is also where consensus is uneven. Some teams assume that high test coverage is enough to prove reachability decisions, while others insist that only runtime observation can validate exposure. The more defensible position is that both are partial views. Pre-production checks are best at finding candidates; production evidence is best at confirming which candidates are materially reachable. When those views disagree, the production view should generally win unless there is a documented reason to trust the test environment as behaviorally identical.
Another edge case is malware or exploit code that never appears as a normal dependency during testing but becomes relevant through memory-only execution or post-compromise loading. In those cases, a static reachability result can be technically correct for the packaged artifact and still operationally misleading for the deployed service.
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, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.RA-1 — Asset Vulnerabilities Are Identified and Documented | Reachability gaps create misread exposure around deployed software paths. |
| Recommendation — Validate real runtime exposure before using reachability results to prioritise remediation. | ||
| CIS Controls v8 | 2 — Inventory and Control of Software Assets | Production-only reachability depends on knowing what is actually deployed and loaded. |
| 7 — Continuous Vulnerability Management | Pre-release checks miss runtime exposure that continuous review can surface. | |
| Recommendation — Maintain authoritative software inventory across build and production environments. Reassess vulnerability priority after deployment using production evidence. | ||
| MITRE ATT&CK | T1195 — Supply Chain Compromise | Runtime-dependent exposure can arise when deployed components differ from tested ones. |
| Recommendation — Map deployment-specific loading paths to reduce blind spots in execution exposure. | ||
| NIST SP 800-53 Rev 5 | placeholder | |
| Recommendation — placeholder | ||
Practitioner Guidance
What to prioritise: Treat pre-production reachability as a screening step, not the final decision. The priority is to identify where production may alter execution, because those are the places where false negatives create the most risk.
What to verify: Confirm whether the production build, configuration, and loading behaviour match the analysed environment. If the deployed system can load code, modules, or dependencies differently from test, the reachability result needs production corroboration before it drives remediation priority.
Decision rule: If a component is unreachable only in pre-production but can be activated by runtime configuration or deployment context, classify the result as conditional rather than safe. If you cannot prove the deployed path, do not use the pre-production finding as the sole basis for de-prioritising exposure.
Practitioner takeaway: The critical mistake is confusing “not seen in tests” with “not reachable in production”; the first is an observation about the lab, while the second is a claim about real exposure.
Related resources from NHI Mgmt Group
- What breaks when recovery depends on the same privileged accounts used in production?
- What breaks when security teams rely only on scanning and pre-runtime checks?
- What breaks when mobile security depends only on static analysis?
- What breaks when SAST is used without reachability analysis in AI-generated code?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
