Application security fails when teams trust the fortress model

At a glance

What this is: The article argues that perimeter-first security gives false confidence while modern application attacks exploit code, supply chain, runtime, secrets, and insider-access weaknesses.

Why it matters: This matters because IAM, PAM, NHI, and application security teams all have to govern access and secrets in environments where attackers often bypass the front gate entirely.

By the numbers:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Arxan Technologies' application security analysis through the Shrek metaphor

Context

Application security fails when organisations treat perimeter controls as a substitute for internal visibility. A castle can look secure from the outside and still leak data through code flaws, exposed APIs, supply chain dependencies, or over-privileged accounts, which is why application security governance must extend into the build, deploy, and runtime layers.

This article uses the Shrek metaphor to argue for a control model based on visibility, continuous monitoring, and resilient protection rather than fortress assumptions. That framing matters for identity teams because application attacks often succeed through credentials, secrets, service accounts, and legitimate access paths rather than obvious perimeter breaches.

Key questions

Q: How should security teams govern secrets and machine identities together?

A: Security teams should govern them as one lifecycle problem. The credential, the identity, and the runtime permission should all have the same owner, the same revocation path, and the same audit trail. If those elements are split across different teams or tools, exposure lasts longer and accountability becomes harder to prove.

Q: Why do perimeter controls fail against application-level attacks?

A: Perimeter controls fail because application attacks often start after authentication, through exposed secrets, vulnerable dependencies, or legitimate but excessive access. Once an attacker uses a trusted credential or a vulnerable build path, the edge is no longer the meaningful boundary. Security has to follow the application’s internal trust relationships instead of stopping at the network edge.

Q: How do security teams know if app secret governance is failing?

A: Look for secrets with unusually long expiry dates, repeated re-creation of credentials, and application records that still authenticate after the original human owner has changed. If credential rotation happens but the entitlement itself remains untouched, the backdoor may survive in a different secret. Effective governance means tracking both the secret and the identity state behind it.

Q: Should organisations prioritise runtime protection or shift-left application security first?

A: They should treat them as complementary, but runtime protection becomes essential when exposure is inevitable. Shift-left controls reduce defects before release, while runtime controls contain damage after deployment and protect code, keys, and data in hostile environments. If the estate already includes exposed APIs, mobile apps, or cloud workloads, runtime protection deserves immediate attention.

Technical breakdown

Why perimeter controls miss modern application attack paths

Perimeter security assumes attackers must enter through a single defended boundary, but application environments are distributed across code repositories, CI/CD pipelines, containers, APIs, and cloud services. Once an adversary reaches any one of those layers, the front gate is no longer the main problem. Security teams therefore have to think in terms of trust boundaries inside the application stack, not just at the edge. In practice, attack paths often start with vulnerable code, leaked secrets, or third-party dependencies and then move into authenticated workloads that perimeter tools never inspect.

Practical implication: map application trust boundaries and control access at each layer instead of relying on edge defence alone.

How secrets and credentials create hidden access paths

The article’s strongest technical point is that secrets are the real gatekeepers of application access. API keys, tokens, certificates, and service account credentials allow attackers to authenticate as trusted systems, which makes stolen secrets more valuable than many classic exploit chains. In modern environments, those credentials may live in source code, config files, logs, pipelines, or runtime memory. Once exposed, they can be reused long after the original disclosure, unless teams have rotation, revocation, scoping, and detection mechanisms tied to the full lifecycle of the credential.

Practical implication: inventory secrets by lifecycle stage and enforce rotation, revocation, and scoped access for every credential type.

Why runtime protection matters after code has shipped

Static analysis catches some defects before release, but the article correctly notes that security cannot stop at build time. Runtime protection is needed because attackers exploit misconfigurations, stolen credentials, and behaviour that only appears when code is actually running. White box cryptography is one example of protecting sensitive data even when implementation details are exposed. That is especially relevant where applications run in hostile environments such as mobile devices, developer workstations, or cloud workloads that may already be partially compromised.

Practical implication: pair pre-deployment scanning with runtime controls that continue protecting code, data, and keys after release.

Threat narrative

Attacker objective: The attacker wants trusted access to applications and the data they process, ideally through credentials or insider paths that look legitimate to control systems.

1. Entry begins with application weaknesses such as exposed secrets, weak configuration, vulnerable dependencies, or socially engineered access rather than a direct perimeter break-in.
2. Escalation follows when the attacker uses legitimate credentials, excessive privileges, or insider access to move deeper into code, pipelines, or production environments.
3. Impact occurs when the attacker exfiltrates data, manipulates applications, or keeps access through reused credentials and weak monitoring.

NHI Mgmt Group analysis

Perimeter security is a governance comfort blanket, not a control model. The castle analogy is useful because many teams still measure security by what is visible at the edge rather than what is governable inside the application estate. That approach fails when the real attack surface sits in code, pipelines, dependencies, and authenticated services. Practitioners should treat internal trust boundaries as first-class security objects, not implementation details.

Secrets exposure is a non-human identity problem as much as an AppSec problem. API keys, tokens, certificates, and service accounts are the identities that applications actually use to act in production. When those credentials are hard-coded, logged, or left unrotated, the application inherits a standing access problem that looks like software but behaves like privilege. The named concept here is credentialed application trust drift, where application access gradually becomes harder to govern than human access. Teams should govern application credentials with the same discipline they apply to high-risk user access.

Runtime protection is the right answer when prevention cannot be perfect. The article’s white box cryptography point is sound because exposed code and hostile devices are normal conditions, not edge cases. Security architects should expect some secrets, binaries, or execution paths to be visible and design for containment under exposure. That shifts the discussion from preventing all inspection to limiting what inspection can yield. Practitioners should prioritise controls that preserve protection after deployment.

Developer behaviour is now a security control surface. The article is right to call out weak practices, noisy logging, and dependency sprawl because those are often the real paths to compromise. This is where application security and identity governance intersect: if developers can introduce or copy secrets freely, the organisation has no effective lifecycle control over machine access. Teams should therefore treat secure development behaviour as part of identity and access governance, not just application hygiene.

What this signals

Application teams should expect more attacks that begin with trusted credentials rather than exploit chains. That changes programme design: access governance, secret lifecycle control, and runtime monitoring need to be planned together, not owned as separate disciplines.

Credentialed application trust drift: application access becomes risky when secrets, service accounts, and developer workflows accumulate standing privileges faster than teams can govern them. The control answer is to make application identities visible, scoped, and revocable across the full delivery pipeline.

For identity programmes, the practical signal is clear. When applications can authenticate with long-lived credentials that are hard to inventory, the organisation is carrying hidden machine access that conventional user IAM reviews will not catch.

For practitioners

• Inventory application secrets by lifecycle stage Classify API keys, tokens, certificates, and service account credentials by where they exist, who can use them, and whether they are embedded in code, pipeline variables, logs, or runtime memory.
• Bind secret rotation to exposure events Rotate and revoke credentials immediately after code merges, developer handoffs, pipeline changes, or any detected leak so exposure does not become persistent access.
• Reduce trust in runtime dependencies Limit what third-party packages, containers, and APIs can access at runtime, and require signed provenance checks for the software supply chain.
• Instrument applications for anomalous credential use Alert on secrets used from unusual geographies, runtimes, or execution contexts, because legitimate credentials are a common attacker path.
• Extend access governance to developers Block uncontrolled secret creation in repositories and enforce secure defaults in CI/CD so developers cannot bypass governance by copying credentials into code.

Key takeaways

• Perimeter-first security gives teams a false sense of control when the real attack paths live inside code, dependencies, and authenticated services.
• Application secrets behave like non-human identities, so poor lifecycle governance turns credentials into persistent access rather than temporary configuration.
• The right response is layered: control secrets, monitor runtime behaviour, and govern developer workflows as part of identity and application security.

Key terms

• Application Secret: A credential used by an application to authenticate to another system or service. This includes API keys, tokens, certificates, and similar authenticators that often persist outside normal human login workflows and can create durable access if exposed or reused.
• Runtime Protection: Runtime protection is a control model that observes application behavior while software is running and blocks unsafe actions as they occur. In Java estates, it helps distinguish active exploit paths from dormant vulnerable code, which is essential when patching is delayed or impossible.
• SaaS Supply Chain Security: SaaS supply chain security is the practice of governing the trusted connections between cloud applications. It focuses on OAuth tokens, API integrations, third-party apps, and service accounts that can move data without changing code. The main concern is delegated access that outlives the original approval.
• 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.

What's in the full article

Arxan Technologies' full blog post covers the operational detail this post intentionally leaves for the source:

• The full narrative mapping each fairy-tale security failure to AppSec control gaps and runtime protection use cases.
• The specific application security capabilities the vendor associates with SAST, SCA, container security, and white box cryptography.
• The detailed examples of how shift-left controls, monitoring, and cryptographic resilience would be applied across the fictional castle environment.
• The full commentary on insider risk, supply chain exposure, and misconfiguration scenarios that sit behind the metaphor.

👉 Arxan Technologies' full post expands the castle, dragon, and runtime protection examples in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners build lifecycle control into access that software and services use in production.