TL;DR: Application security still fails when teams rely on perimeter controls, point-in-time audits, and visible defenses instead of visibility into code, supply chain, runtime behaviour, and secrets exposure, according to Arxan Technologies. The real lesson is that breach resilience comes from assuming adversaries can already see inside the system and protecting the data and execution path anyway.
At a glance
What this is: This is a critique of fortress-style application security that argues visible perimeter defenses and compliance checks do not stop attackers who can exploit code, supply chain, runtime, and secrets weaknesses.
Why it matters: For AppSec and IAM teams, the message is that control points must shift from gatekeeping to continuous visibility, privilege containment, and runtime protection across software and identities.
Context
Application security fails when defenders assume the boundary is the main control surface. In modern environments, attackers more often exploit code flaws, insecure dependencies, exposed secrets, weak authentication paths, and runtime abuse after the perimeter is bypassed. That changes the problem from keeping adversaries out to limiting what they can do once they are inside.
The identity angle is real because application compromise often becomes credential compromise, privilege misuse, or secret exposure. Once an app, service account, token, or key is reachable, the security model depends on how tightly those non-human identities are scoped, rotated, and monitored. Fortress thinking fails when it treats access as a gate instead of a lifecycle.
Key questions
Q: What breaks when container security relies only on perimeter controls?
A: Perimeter-only security breaks because containers are not static assets behind a fixed boundary. Once an attacker reaches a workload through misconfiguration, exposed APIs, or weak credentials, the real risk becomes internal movement between services. Without internal segmentation and continuous visibility, teams may miss the compromise until sensitive systems are already exposed or the attack has spread.
Q: Why do certificate failures create broader identity and access risk?
A: Certificate failures matter because they can break authenticated connections, expose users to trust warnings, and disrupt services that depend on machine authentication. In practice, they undermine confidence in both external and internal access paths. When certificates are unmanaged, the same governance gaps that affect NHI credentials also affect browser trust and application availability.
Q: How do security teams know if runtime protection is actually working?
A: Look for evidence that suspicious behaviour is detected fast enough to contain it before the session or workload expands the blast radius. Effective runtime protection produces actionable alerts, ties them to containment steps, and shows that abnormal access can be limited during active execution, not only reviewed afterward.
Q: What is the difference between shift-left security and runtime application security?
A: Shift-left security finds weaknesses before release through code review, testing, and static analysis. Runtime application security watches production behavior during execution and stops attacks as they happen. The two are complementary, but they answer different questions. Shift-left reduces exposure before deployment, while runtime controls provide the live visibility needed for APIs, microservices, and AI workflows in production.
Technical breakdown
Why perimeter controls fail in application security
A perimeter model assumes the key security decision happens at the edge, so if the edge holds, the system is safe. That breaks down in application security because attackers routinely enter through code flaws, exposed APIs, compromised dependencies, or stolen credentials, then move inside the application trust boundary. Modern apps also depend on cloud services, containers, and external packages, which means the true attack surface is distributed across build, deploy, and runtime stages. Security that only watches the gate misses the places where trust is created and consumed.
Practical implication: move controls from the outer boundary to the code, dependency, and runtime layers where compromise actually occurs.
How code and supply chain weaknesses become runtime compromise
Static code, third-party libraries, and build artifacts can all carry security debt into production. Software composition analysis looks for vulnerable dependencies, but the deeper issue is that once a bad component ships, the runtime inherits its risk. That is why shift-left testing alone is incomplete. The article’s point is not that prevention is useless, but that prevention must be joined to continuous validation of what is actually executing, because packages, containers, and APIs can diverge from what teams thought they deployed.
Practical implication: treat build provenance, dependency risk, and runtime behaviour as one control chain rather than separate teams and tools.
Why secrets and white box cryptography matter after entry
Secrets are the shortest path from application access to broader compromise. If a token, API key, or embedded credential is exposed, the attacker no longer needs the perimeter to fail again. White box cryptography extends the same idea to hostile runtime environments by assuming code and keys may be observable, so protection has to survive exposure rather than rely on hiding implementation details. In other words, the control must still work when the attacker can inspect the system.
Practical implication: design credential protection and cryptographic controls for exposure resilience, not secrecy alone.
Threat narrative
Attacker objective: The attacker aims to reach application data and execution paths that perimeter controls were never able to protect on their own.
- Entry occurs through application-layer weakness, exposed interfaces, or social engineering that bypasses the outer wall.
- Credential or secret exposure then turns limited access into broader application trust, because the attacker can reuse tokens, keys, or privileged sessions.
- Escalation happens inside the environment through over-permissive access, weak runtime controls, or vulnerable dependencies that allow further abuse.
- Impact is data exfiltration, application compromise, or theft of protected assets despite the apparent strength of the perimeter.
NHI Mgmt Group analysis
Fortress security is a control illusion when the real attack surface sits inside the application lifecycle. A moat, firewall, or SIEM can look comprehensive while leaving code, dependencies, secrets, and runtime paths untouched. That is not a visibility problem alone, it is a governance problem about where the security boundary is defined. Practitioners should treat application trust as a lifecycle issue, not a perimeter event.
Application security now depends on protecting execution, not just blocking entry. Once an attacker reaches an app, the question becomes what they can do with tokens, service credentials, or privileged paths already present. That is why runtime controls, secrets management, and least privilege matter together. The control model must assume partial compromise and still preserve containment.
Supply chain exposure has become an application security issue, not a separate hygiene concern. Dependencies and build inputs can introduce the same blast radius as direct code flaws because they are part of the deployed system. The named concept here is runtime trust collapse: the point where static assurances stop mattering because the running application no longer matches the security story teams believed. Practitioners should govern code, build, and runtime as one trust chain.
Identity controls are now inseparable from AppSec in environments that rely on service accounts and tokens. If application access is mediated by non-human identities, then secret leakage, scope creep, and weak rotation become application security failures as much as IAM failures. That shifts responsibility from the perimeter team alone to the identity and software teams together. Practitioners should measure application resilience by how much damage a compromised credential can actually do.
What this signals
Runtime trust collapse: application teams need a model that assumes deployment does not equal safety. The practical shift is from defending the perimeter to defending code execution, dependency integrity, and the credentials the application uses while live.
Perimeter tools still have value, but they no longer define the security outcome for modern apps. The reader’s programme should focus on whether secrets, service identities, and third-party components are governed tightly enough to limit damage after first entry.
For practitioners
- Define the real application trust boundary Map where code, dependencies, APIs, secrets, and runtime permissions actually create trust, then align controls to those points instead of the network edge.
- Inventory and rotate exposed application secrets Identify tokens, API keys, certificates, and embedded credentials across source, CI, container images, and runtime environments, then remove standing exposure windows.
- Add runtime protection to shift-left testing Use continuous monitoring and application runtime controls so that deployed behaviour, not just pre-release scans, determines whether the system is safe.
- Treat third-party components as governed attack surface Track dependency provenance and update responsibility for each library, package, and image so supply chain risk is owned rather than assumed away.
Key takeaways
- Application security fails when teams treat the outer boundary as the main control, because attackers can enter through code, dependencies, secrets, and runtime paths.
- The strongest lesson is that compromise resilience comes from limiting what exposed applications, tokens, and components can do after entry.
- Practitioners should align AppSec with identity, supply chain, and runtime controls so the security model still works when the system is partially visible to an attacker.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article repeatedly links app compromise to exposed keys, tokens, and credentials. |
| NHI-07 — Long-Lived Secrets | The fortress model fails when credentials remain usable after initial compromise. | |
| Recommendation — Scan application pipelines and runtime environments for leaked secrets and revoke any exposed credentials immediately. Replace standing application secrets with short-lived credentials wherever runtime access is required. | ||
| MITRE ATT&CK | TA0006; TA0010 — Credential Access; Exfiltration | The article’s threat pattern is credential abuse followed by data theft after perimeter bypass. |
| Recommendation — Map application compromise to credential access and exfiltration techniques to improve detection coverage. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core governance issue is whether application access is actually constrained once inside the trust boundary. |
| Recommendation — Enforce entitlement review on application identities and limit permissions to the minimum required for each service. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article’s identity angle is strongest where app credentials and privileged accounts are overexposed. |
| Recommendation — Centralise account inventory for service identities and remove stale or unused credentials from production systems. | ||
Key terms
- Transient Trust Collapse: A failure mode where short-lived external input is treated as safe long enough to create lasting internal state. In practice, this means a request, peer message, or package install can trigger code execution, filesystem writes, or stored data growth before controls intervene.
- White-Box Cryptography: White-box cryptography is a design approach that tries to keep cryptographic keys and operations protected even when the software runs in a fully exposed environment. It embeds cryptographic logic into heavily obfuscated code and data structures so extraction and tampering become much harder.
- Software Composition Analysis: Software composition analysis is the inspection of dependencies and packages to identify known vulnerabilities in third-party or transitive code. It complements secret scanning by answering a different question: what exploitable software weaknesses are present in the container, regardless of whether credentials are embedded.
- Secrets Exposure: Secrets exposure is the accidental or uncontrolled disclosure of credentials such as API keys, tokens, certificates, and service passwords. In NHI programs, it matters because a leaked secret often behaves like a live identity, creating immediate access risk until it is revoked or rotated.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect application security failures to identity lifecycle controls across modern environments.
Published by the NHIMG editorial team on September 6, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org