Topic starter
20/08/2026 5:49 pm
TL;DR: Application security still breaks down when organisations treat code scanning, testing, and governance as sufficient while leaving secrets, access, and runtime identity controls weak, according to Cycode’s analysis. The practical lesson is that secure delivery now depends on treating applications, pipelines, and service accounts as an identity governance problem, not just a tooling problem.
Editorial analysis by NHI Mgmt Group, based on content published by Cycode: “Application Security Best Practices and Requirements”.
By the numbers:
- Security monitoring can reduce combined detection and response time to 241 days, compared with 321 days without automation.
Key questions
Q: What breaks when application security does not include identity controls?
A: Security breaks at the point where code safety ends and runtime access begins.
Q: Why do overprivileged service accounts increase the impact of secret leakage?
A: Because the leaked secret authenticates the service account as itself, and the entitlement set determines how far that identity can move.
Q: What are the signs that application identity controls are failing?
A: Common signs include secrets appearing in source repositories or build artefacts, service accounts with broad or persistent permissions, and access events that do not match expected workload behaviour.
Practitioner guidance
- Enforce continuous secret scanning across code and pipelines Scan repositories, build logs, container images, and deployment artefacts for exposed API keys, tokens, and certificates, then revoke and rotate immediately when found.
- Scope service accounts to task-level permissions Review every non-human identity used by applications and CI/CD systems, remove standing access that is broader than the workload needs, and separate privileges by environment.
- Treat credential rotation as a release control Require rotation for secrets that are introduced, modified, or detected outside policy, and connect rotation to deployment approval rather than a loose maintenance cycle.
Bottom line: Application security programmes fail when they ignore the identity layer that powers modern pipelines, services, and APIs.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:29 pm
Application security has become an identity governance problem disguised as a code-quality problem. Scanning and testing matter, but they do not govern who or what can act inside production once the application is running. The article’s real contribution is to show that secrets, service accounts, and API permissions are now first-order security assets. Practitioners should treat application security controls as part of IAM and PAM design, not as a parallel discipline.
A question worth separating out:
Q: Should teams prioritise secrets management or broader DevSecOps coverage first?
A: Teams should usually start with secrets management and dependency risk because those are high-frequency, high-impact failure points with the clearest path to compromise. Broader coverage only helps if the team can act on it. The best sequence is to close credential exposure first, then expand toward code and runtime prioritisation.
👉 Read our full editorial: Application security best practices fail without identity controls