Notifications
Clear all
Topic starter
28/08/2026 12:04 pm
TL;DR: API growth, shadow APIs, unclear ownership, CI/CD enforcement gaps, and false positives are making application security harder to operationalise, according to Pynt. The core issue is not just tooling complexity, but the governance gap between discovery, accountability, and developer-led testing that leaves exposures untracked.
NHIMG editorial — based on content published by Pynt: API security visibility, ownership, and CI/CD testing gaps
By the numbers:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
Q: How should security teams govern APIs that change frequently?
A: Security teams should treat fast-changing APIs as continuously governed assets, not quarterly review items.
Q: Why do shadow APIs create such a large security gap?
A: Shadow APIs bypass ownership, policy enforcement, and change control, so defenders cannot reliably classify the data they expose or the identities that can reach them.
Q: How should security teams implement API security testing in CI/CD pipelines?
A: Start by automating the endpoints that carry privileged actions, sensitive data, or access decisions.
Practitioner guidance
- Build a continuous API inventory Discover production, pre-production, and undocumented APIs continuously, then attach each endpoint to a named owner, system, and data classification.
- Make security tests release gates Treat high-risk API security checks as deployment blockers in CI/CD, not optional notifications.
- Map API credentials to NHI lifecycle controls Inventory API keys, tokens, and service account bindings alongside the applications they support, then apply rotation, revocation, and offboarding workflows to each credential class.
What's in the full article
Pynt's full article covers the operational detail this post intentionally leaves for the source:
- Day-to-day API security workflow challenges that AppSec teams face when inventories, ownership, and testing all move at different speeds.
- Practical discussion of why existing API security tools are difficult to adopt and how that affects developer collaboration.
- Examples of how false positives and missing context shape real-world API testing outcomes in CI/CD.
- The article's broader view on balancing automation with manual review in fast-moving development environments.
👉 Read Pynt's analysis of API security visibility, ownership, and CI/CD testing gaps →
Shadow APIs and CI/CD testing gaps: what AppSec teams need now?
Explore further
28/08/2026 12:04 pm
API security is now an identity governance problem disguised as an AppSec problem. The article is really describing unmanaged machine access, not just incomplete testing. When APIs are deployed without inventory, ownership, or lifecycle control, the associated tokens, keys, and service accounts inherit the same governance gap. That makes API security part of the NHI control plane, where visibility and revocation matter as much as code scanning. Practitioners should treat undocumented APIs as identity risk surfaces, not just development oversights.
A question worth separating out:
Q: What is the difference between API documentation and API ownership?
A: Documentation tells you what an API does, while ownership tells you who is accountable when risk appears. Ownership is the stronger control because it enables remediation, decommissioning, and credential lifecycle management. Without it, security findings cannot be routed to the right team and stale APIs linger in production.
👉 Read our full editorial: API sprawl and shadow APIs are exposing AppSec governance gaps
