Notifications
Clear all
Topic starter
18/08/2026 2:29 pm
TL;DR: Most API vulnerabilities are written during development, not discovered at deployment, according to Cycode’s analysis, and AI-era research shows 81% of organisations lack full visibility into AI use across the SDLC and 62% of latest-LLM code contains at least one exploitable vulnerability. The decisive control point is the developer workflow, where authorization flaws, hardcoded secrets, and shadow APIs first enter the system.
NHIMG editorial — based on content published by Cycode: What Is API Security? Risks, Best Practices, and the Code-First Approach
By the numbers:
- 81% of organisations lack full visibility into how and where AI is used across the SDLC.
Questions worth separating out
Q: How should security teams implement API security in the software delivery lifecycle?
A: They should place controls where the risk is introduced.
Q: Why do APIs with weak object-level authorization create such a large risk?
A: Because the attack is usually just a parameter change, not a noisy exploit.
Q: What do security teams get wrong about shadow data?
A: Many teams treat shadow data as a discovery problem when it is also a governance problem.
Practitioner guidance
- Move authorization checks into code review Require object-level and function-level authorization checks to be validated in pull requests, with SAST rules that flag missing or inconsistent access control before merge.
- Scan every commit for hardcoded secrets Run secrets detection automatically on human and agent-authored changes, then block merges that introduce tokens, API keys, or OAuth client secrets into the repository.
- Inventory shadow APIs before runtime Map undocumented endpoints from code, repositories, and deployment manifests, then assign an owner and review access paths before the endpoint can exchange data or tokens.
What's in the full article
Cycode's full blog covers the operational detail this post intentionally leaves for the source:
- Full OWASP API Security Top 10 walkthrough with code examples for each risk class
- Implementation guidance for SAST, DAST, SCA, and secrets detection across the ADLC
- MCP security discussion, including how prompt injection changes tool exposure risk
- Practitioner mapping of API security controls to specific development pipeline stages
👉 Read Cycode's analysis of API security across the ADLC →
API security in the ADLC: are your controls catching issues early?
Explore further
18/08/2026 3:17 pm
API security is now an identity governance problem as much as an application security problem. APIs carry authentication decisions, service tokens, and delegated permissions that behave like non-human identities, even when they are embedded in software. If those credentials are created in code and never governed through lifecycle controls, the organisation has an identity problem hiding inside its application stack. Practitioners should treat API authentication and authorization as part of identity governance, not just secure coding.
A question worth separating out:
Q: How can organisations govern AI-generated API code safely?
A: They should apply the same controls to agent-authored code as to human-written code, with no exceptions. That means policy checks on every commit, automated secrets scanning, dependency scanning, and review of generated authentication logic. If AI can create endpoints and scopes faster than humans can inspect them, governance has to become machine-enforced.
👉 Read our full editorial: API security starts in code, not at the gateway
