How should security teams validate application risk beyond code review?

Why live testing reveals risk that code review misses

Code review tells you what the source appears to permit, but live testing tells you what the deployed system actually exposes. The gap matters because runtime risk is shaped by identity boundaries, service-to-service trust, cloud configuration, and request paths that static review often cannot fully reconstruct.

A system can look sound in code and still be reachable, abused, or escalated once its auth flow, network exposure, tokens, and cloud controls are assembled in production-like conditions. That is why validation has to include behaviour under realistic deployment state, not just syntax and logic inspection.

Teams should think in terms of exploitability, not just code defects. A harmless-looking branch in source becomes a real issue only if it can be reached through an authenticated route, a misconfigured API, a permissive role, or a container and cloud setting that widens access at runtime. The live environment is where those combinations become visible.

What to test in the running application

The most useful next step is to test the application as an attacker or failure condition would encounter it: authenticated and unauthenticated paths, object access, privilege boundaries, session handling, and dependency behaviour. OWASP’s ASVS is useful here because it forces validation of authentication, session, and access control requirements against the deployed system, not the codebase alone.

That same runtime view should extend to service interactions and deployment controls. The OWASP Web Security Testing Guide helps teams probe how the application behaves under real requests, chained flows, and authorization checks, while NIST SP 800-190 Container Security is useful when risk depends on image, runtime, or orchestrator settings that code review cannot see.

When the application exposes APIs or service endpoints, runtime validation should confirm that access rules hold for real objects and functions, not only for intended design. If the live system allows broken object access, overbroad function access, or unsafe resource consumption, the practical risk is present regardless of how clean the source looks.

How to decide whether a finding is truly exploitable

A code-level issue becomes a security issue when it can be reached and combined with some operational weakness. That means the key question is not “does the code contain a pattern?” but “can this path be exercised in the deployed environment with meaningful impact?” If the answer is yes, the issue deserves treatment as application risk.

Testing should therefore confirm whether the control failure is real under production-like state: valid identities, real permissions, actual routing, deployed secrets, cloud metadata, and external dependencies. A flaw that exists only in theory is lower priority than a flaw that can be demonstrated through an authenticated request, a cross-service call, or a misconfiguration that widens access.

For teams already using code scanning, the practical rule is simple: static findings are hypotheses; live validation is evidence. If the runtime test shows no reachable path, no privilege gain, and no material data or action exposure, the code finding may be advisory. If the live test shows reachability or escalation, it is a true application risk.

Risk and Threat Considerations

Security teams that stop at code review can miss the actual attack surface created by deployed identity, service, and cloud relationships. The resulting risk is not just false positives, but false confidence, because exploitability often emerges only after systems are integrated and exposed in a real environment.

Failure mechanism: A latent code weakness becomes exploitable when runtime conditions supply the missing ingredients, such as reachable endpoints, excessive privilege, weak service trust, or permissive cloud configuration. Attackers then work through the exposed path that static review did not fully model.

Impact: The result can be unauthorized access, privilege escalation, lateral movement, data exposure, or abuse of business functions that the source code alone did not appear to permit.

Practitioner Guidance

What to prioritise: Validate the paths that can produce real security impact first, especially authentication, object access, privileged actions, and service-to-service calls. These are the places where runtime behaviour most often diverges from what code review suggests.

What to verify: Confirm the application under test uses production-like identities, permissions, configuration, and dependencies. If the test environment is too clean, you will miss the very misconfigurations and access combinations that create exploitability.

Practitioner takeaway: The right question is whether the deployed system can be meaningfully abused, not whether the source looks suspicious; runtime validation is what separates theoretical defects from real application risk.

Related resources from NHI Mgmt Group

• How should security teams extend software composition analysis beyond application code to reduce supply chain risk?
• How should security teams implement risk-based code review in high-velocity delivery?
• What do security teams get wrong about relying on manual code review for modern application security?
• How should security teams validate AI-assisted code security findings in application security programs?