Notifications
Clear all
Topic starter
06/09/2026 3:44 pm
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.
NHIMG editorial — based on content published by Arxan Technologies: The Shrek School of Application Security
Questions worth separating out
Q: How should security teams govern secrets and machine identities together?
A: Security teams should govern them as one lifecycle problem.
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.
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.
Practitioner guidance
- 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.
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.
👉 Read Arxan Technologies' application security analysis through the Shrek metaphor →
Perimeter security in AppSec: what is your team missing?
Explore further
06/09/2026 3:45 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Application security fails when teams trust the fortress model
