Notifications
Clear all
Topic starter
06/09/2026 5:18 pm
TL;DR: API-heavy delivery has made traditional end-of-pipeline security too slow for modern release cycles, and LEVO argues that DevSecOps must embed testing, monitoring, and visibility directly into CI/CD to reduce exposure. The governance shift is no longer optional: security has to operate at the pace of software delivery, with APIs treated as first-class attack surfaces.
NHIMG editorial — based on content published by LEVO: From DevOps to DevSecOps, a shift in mindset over the software delivery lifecycle
By the numbers:
- 90% of internet-facing applications expose APIs, APIs, and more than 70% of security breaches involve APIs.
- 80% of modern apps depend on open source, ource libraries.
- Fixing a flaw in production costs up to 30x more than addressing it in development.
Questions worth separating out
Q: How should security teams govern API secrets across cloud and DevOps environments?
A: Security teams should treat API secrets as managed non-human identities, not developer convenience items.
Q: Why do API-heavy delivery pipelines increase security risk?
A: Because every new service, integration, and secret expands the attack surface faster than manual controls can keep up.
Q: What breaks when NHI secrets are stored in code or CI/CD systems?
A: You lose the containment boundary.
Practitioner guidance
- Map every API to an owner and trust path Build a live inventory of internal, partner, and shadow APIs, then assign business and technical ownership so each endpoint has an accountable control path.
- Classify pipeline credentials as governed NHIs Treat tokens, certificates, and API keys used in CI/CD as non-human identities with scope, rotation, and revocation rules, rather than as ordinary configuration.
- Embed security tests directly into release gates Run SAST, DAST, schema checks, and dependency validation in pull requests and pipelines so vulnerabilities fail fast before deployment.
What's in the full article
LEVO's full blog covers the operational detail this post intentionally leaves for the source:
- API discovery and inventory mechanics for internal, partner, and shadow APIs across hybrid environments
- CI/CD implementation details for pre-deployment validation, schema checks, and dependency scanning
- Runtime monitoring architecture using eBPF sensors without proxy overhead or full payload ingestion
- Operational guidance on aligning API security telemetry with developer workflows and incident triage
👉 Read LEVO's full analysis of DevSecOps for API security and runtime visibility →
API security in DevSecOps pipelines: are your controls keeping up?
Explore further
06/09/2026 5:19 pm
API security has become an identity governance problem as much as an application-security problem. The article is right to treat APIs as first-class assets, but the more important point for practitioners is that every API is also a trust relationship. Tokens, service accounts, certificates, and delegated integrations are all identities in practice, even when they are managed inside DevOps tooling rather than IAM platforms. That means security leaders should govern API access with the same discipline they apply to human access and NHI lifecycle management.
A question worth separating out:
Q: Should teams prioritise shift-left testing or runtime API monitoring first?
A: They should do both, but runtime monitoring becomes the deciding control once APIs reach production. Shift-left testing reduces defects before release, while runtime visibility catches drift, abuse, and access violations that only appear under live traffic.
👉 Read our full editorial: DevSecOps for API-heavy delivery is now a governance requirement
