Notifications
Clear all
Topic starter
01/08/2026 8:56 pm
TL;DR: Code review catches obvious defects, but modern application risk often emerges only at runtime, where identity boundaries, service interactions, cloud configuration, and deployment behaviour combine, according to TENZAI. The practical shift is from source-level pattern detection to validating whether a system can actually be compromised in production-like conditions.
NHIMG editorial — based on content published by TENZAI: Test in prod or live a lie
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.
Questions worth separating out
Q: What breaks when appsec relies on code review alone?
A: Code review alone misses the environment where most real exploits happen.
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.
Q: How do security teams know if runtime validation is working?
A: Look for evidence that testing changes decisions, not just reports.
Practitioner guidance
- 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.
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
👉 Read TENZAI's analysis of why runtime validation matters more than code review →
Runtime validation and identity boundaries: are appsec controls keeping up?
Explore further
01/08/2026 9:04 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Runtime validation is overtaking code review in application security
