Notifications
Clear all
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.
NHIMG editorial — based on content published by Cycode: Application Security Best Practices and Requirements
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
- Systems with least-privileged AI access had a 17% incident rate versus 76% for over-privileged systems, making poorly scoped AI access 4.5x riskier.
Questions worth separating out
Q: What breaks when application secrets are not governed like identities?
A: Application secrets become durable access paths instead of controlled credentials.
Q: Why do service accounts and tokens create more risk than many teams expect?
A: Because they often carry standing privilege, operate quietly, and remain valid long after the business need changes.
Q: How can security teams tell whether secret management is actually working?
A: Look for fewer plaintext secrets, narrower reuse, faster rotation, and a shrinking set of credentials that remain valid across multiple systems.
Practitioner guidance
- Implement application secret lifecycle controls Inventory API keys, database passwords, certificates, and service tokens across code, pipelines, container images, and cloud integrations.
- Extend least privilege into build and runtime identities Review every CI/CD service account, deployment token, and workload identity to confirm it only reaches the systems required for its function.
- Add automated secrets detection to developer workflows Scan repositories, pull requests, images, and configuration files for embedded credentials before code merges.
What's in the full article
Cycode's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step secure coding and SAST implementation guidance for development teams that need concrete rollout details.
- Expanded treatment of dependency risk management, including SCA and SBOM practices for application supply chains.
- Operational examples for secrets detection in repositories, CI/CD pipelines, and container images.
- Cycode's own implementation framing for its application security platform and workflow integrations.
👉 Read Cycode's application security best practices for secure development and identity controls →
Application security and identity controls: where teams still fall short?
Explore further
20/08/2026 6:29 pm
Application security is increasingly an identity governance problem. The article is strongest when it treats secrets, access, and least privilege as core security controls rather than implementation details. That is the right framing because modern applications authenticate through machine identities far more often than through humans. For IAM and NHI programmes, the conclusion is clear: application security now depends on who and what can authenticate into the delivery chain.
A question worth separating out:
Q: Should organisations prioritise secret rotation or access review first
A: They should do both, but access review should come first when unknown or over-privileged identities already exist. Rotation reduces exposure window, but review reduces entitlement sprawl and clarifies ownership. If a team rotates secrets without fixing who can use them, it preserves the same risk pattern with a fresher credential.
👉 Read our full editorial: Application security best practices fail without identity controls
