Runtime validation is overtaking code review in application security

At a glance

What this is: This is a commentary on why application security must move beyond source code review to runtime validation of real systems.

Why it matters: It matters because IAM, NHI, and application teams increasingly share the same failure modes at service boundaries, where permissions, tokens, and integrations determine whether a weakness becomes an exploit.

By the numbers:

• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read TENZAI's analysis of why runtime validation matters more than code review

Context

Modern application security fails when teams assume source code review is enough. Many defects only become exploitable once services, identity providers, cloud settings, and runtime behaviour interact under pressure, which means the real control boundary sits far beyond the repository.

The article is really about the governance gap between what code appears to allow and what production systems actually permit. That gap matters to identity programmes because service accounts, API keys, tokens, and access controls often define the attack path more clearly than the code itself.

Key questions

Q: What breaks when appsec relies on code review alone?

A: Code review alone misses the environment where most real exploits happen. Applications can look clean in source control but still fail at runtime because cloud permissions, service trust, identity boundaries, and integrations expand the attack surface. The result is false confidence. Teams need validation that checks whether the deployed system can actually be compromised, not whether the code looks safe.

Q: Why do service accounts matter so much in application security?

A: Service accounts often define how one component trusts another, which means they can open or close the attack path. If those identities are over-scoped, stale, or poorly monitored, an attacker can move from a single application foothold into adjacent systems. That makes machine identity governance a core appsec control, not an administrative detail.

Q: How do security teams know if runtime validation is working?

A: Look for evidence that testing changes decisions, not just reports. If runtime validation consistently finds issues that static review misses, forces environment hardening, or blocks releases until identity and access assumptions are corrected, it is working. If it only produces findings without changing deployment behaviour, it is cosmetic.

Q: Should organisations treat identity controls as part of application security?

A: Yes, because the practical exploit path often depends on identity scope, not just code quality. Application security that ignores service accounts, tokens, and inter-service permissions leaves the most important trust boundaries untested. The right model is cross-functional: appsec validates the logic, while IAM and NHI governance validate the authority the application actually has.

Technical breakdown

Why source-level scanning misses runtime exposure

Source scanning is useful for finding obvious anti-patterns, but it cannot see how an application behaves once deployed. Runtime exposure depends on identity context, network reachability, configuration drift, and how services authenticate to each other. A secure-looking code path can still fail if an API gateway, workload identity, or cloud permission set widens access after deployment. This is why many exploits are not code bugs in isolation but control failures across layers. Practical implication: validate security in production-like conditions, not just in the repository.

Practical implication: test application behaviour after deployment, where identity and configuration create the real blast radius.

Identity boundaries are part of application security

Modern applications are stitched together by service accounts, tokens, certificates, and delegated permissions. Those identities often outlive the code change that introduced them, which makes them a persistence layer as much as an access layer. When identity boundaries are weak, attackers do not need elegant exploit chains. They need one permissive integration or one over-scoped token. That is why IAM, PAM, and NHI governance belong inside appsec conversations rather than alongside them. Practical implication: treat service identity scope as a first-class application control.

Practical implication: review service identities, token scope, and inter-service trust as part of every application security assessment.

Why production testing reveals what secure design cannot

Production testing exposes how defences interact under realistic pressure. Rate limits, monitoring, segmentation, privilege boundaries, and error handling often neutralise issues that look severe in theory. The reverse is also true: a harmless-looking code pattern can become critical when paired with permissive access or a fragile service mesh. That is the core reason adversarial validation matters. It measures whether the system can actually be compromised, not whether it looks secure on paper. Practical implication: pair code analysis with controlled runtime attack simulation and environment validation.

Practical implication: add adversarial validation to verify whether existing controls break the attack chain in practice.

Threat narrative

Attacker objective: The objective is to turn a seemingly safe application into a compromised runtime environment by exploiting the gap between source-level assurance and production reality.

1. Entry occurs when attackers reach a deployed application through exposed services, weak API security, or an overly permissive integration path rather than through the source repository itself.
2. Escalation follows when identity boundaries, service permissions, or cloud configuration allow the initial foothold to reach additional systems or data.
3. Impact lands when runtime interactions expose sensitive functionality, data, or administrative control that code review never revealed.

NHI Mgmt Group analysis

Runtime validation is becoming the real control plane for application security. Source analysis still matters, but it no longer answers the question practitioners care about most: can this system be compromised in the environment it actually runs in? Identity providers, cloud permissions, and service interactions now determine exploitability as much as code quality does. Teams that keep treating runtime as a secondary concern will miss the point where attacks become real.

Identity boundaries are the hidden fault line in modern appsec. Service accounts, API keys, and delegated tokens define how applications trust one another, and that trust is often broader than anyone intended. This is where application security intersects directly with IAM and NHI governance, because a vulnerable path often emerges from over-scoped machine identity rather than from defective logic. Practitioners should therefore review service trust as aggressively as they review source.

Adversarial validation exposes the difference between theoretical and operational security. A codebase can look clean while deployment settings, monitoring gaps, and runtime permissions leave the system open. Production-blind appsec: this is the failure mode where tools verify syntax and patterns but not whether defences survive a real attack chain. The practical conclusion is simple: teams need testing that proves whether controls stop compromise, not just whether code looks compliant.

AI-assisted development is raising the cost of relying on static assurances alone. When code is produced faster, insecure patterns can spread faster, and the screening burden shifts to runtime controls and environment validation. That does not make secure coding irrelevant. It does mean the governing question changes from 'did we catch the flaw?' to 'did we stop the exploit path?' Teams should re-centre appsec on execution conditions, not developer intent.

Security programmes need a control map that crosses code, identity, and cloud layers. NIST-CSF, NIST SP 800-53, and MITRE ATT&CK all fit this conversation because the risk is systemic rather than isolated. The article’s core message is that resilience is forged where controls intersect, not where they are documented. Practitioners should build assurance models around runtime reach, privilege scope, and exploit containment.

What this signals

Application security teams should expect more pressure to prove exploitability at runtime, especially as AI-generated code accelerates delivery and narrows the window for manual review. The practical response is to move validation earlier and deeper, combining static analysis with attack-path testing and identity-aware control checks.

Production-blind assurance: the control gap is not whether the code compiles cleanly, but whether the deployed environment survives realistic abuse. That is where IAM, secrets governance, and application hardening converge, and where teams can least afford blind spots. See also MITRE ATT&CK Enterprise Matrix for mapping runtime tactics to control failures.

Programmes that already manage service identities centrally will be better placed to absorb this shift because they can test privilege scope, token exposure, and trust boundaries as part of release governance. For identity-heavy applications, the next maturity step is not more scanning, but better proof that the deployed system cannot be used the way an attacker would use it.

For practitioners

• Add runtime adversarial validation to appsec reviews Test deployed systems in production-like environments to see whether authentication, service boundaries, and cloud settings still hold under attack pressure.
• Map service identities to application trust boundaries Inventory service accounts, API keys, tokens, and certificates used by the application, then verify that each one is limited to the minimum inter-service reach required.
• Re-test risky integrations after every deployment change Prioritise external APIs, internal service mesh links, and identity provider integrations because those are the places where safe code becomes unsafe execution.
• Pair static scanning with exploit-path validation Use code scanning to reduce obvious defects, then confirm whether compensating controls, segmentation, and runtime monitoring actually stop compromise.

Key takeaways

• Code review is necessary, but it is not sufficient to determine whether a modern application is secure in practice.
• Runtime failures often emerge where identity boundaries, cloud configuration, and service interactions overlap, not where source code looks weak.
• Security teams should pair static analysis with adversarial validation and machine identity governance to verify exploit resistance after deployment.

Key terms

• Runtime validation: A control practice that tests how an AI system behaves while it is connected to real tools and data, rather than only reviewing configuration or design documents. It matters because agentic systems can appear safe on paper and still fail when prompted, chained, or given access to connected services.
• Machine Identity: The digital identity of a machine, device, or workload — such as a server, container, or VM — used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
• Production-blind assurance: Production-blind assurance is the false confidence that comes from proving code quality without proving runtime security. It describes programmes that scan for patterns and defects but do not test whether deployed controls, access boundaries, and operational conditions stop a real attack chain.

What's in the full article

TENZAI's full analysis covers the operational detail this post intentionally leaves for the source:

• Specific examples of how production runtime behaviour exposes weaknesses that source scanning cannot see
• The article's discussion of why identity boundaries, cloud configuration, and service interactions create real exploit paths
• The practical implications of AI-generated code for application security programmes and validation workflows
• The source's examples of where runtime testing reveals issues that look harmless in theory

👉 TENZAI's full post expands on the runtime failure patterns, identity boundaries, and deployment pressures behind this argument

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, IAM, and secrets management. It helps practitioners connect identity controls to the broader security programme that modern applications depend on.