Notifications
Clear all
Topic starter
01/08/2026 10:42 pm
TL;DR: Shift-left security can catch known issues in build pipelines, but static analysis, dynamic analysis, schema validation, and dependency scanning still miss business logic abuse, API drift, and production-only behaviour, according to Salt. Runtime baselining and behavioural analysis are becoming the decisive control layer for API security.
NHIMG editorial — based on content published by Salt: Michael Isbitski's analysis of shift-left security and API protection
Questions worth separating out
Q: How should security teams validate APIs beyond build-time scanning?
A: They should combine build-time testing with runtime behavioural monitoring.
Q: Why do schema validators miss important API security issues?
A: Schema validators only check what is explicitly documented in the contract, usually field structure and basic request shape.
Q: How can security teams tell whether API risk controls are actually working?
A: Look for reduced abuse volume, fewer successful automated attacks, and clearer visibility into which non-human clients are making requests and why.
Practitioner guidance
- Map API controls to runtime behaviour, not just pipeline outputs. Define which API paths require behavioural monitoring, stateful authorisation checks, and anomaly thresholds after deployment, especially where identity or delegated access is involved.
- Separate contract validation from abuse detection. Keep schema validators in the build process, but add runtime detection for broken object-level authorisation, workflow bypass, and abnormal request sequences.
- Inventory undocumented API functions and drift points. Compare the live service against published schemas and integration assumptions, then flag fields, endpoints, and workflow steps that exist in production but not in design artefacts.
What's in the full article
Salt's full article covers the operational detail this post intentionally leaves for the source:
- How Salt frames the limits of SAST, DAST, and SCA for API security in DevSecOps environments.
- The article's examples of schema validation failure modes, including API drift and undocumented fields.
- Salt's runtime-focused approach to spotting business logic abuse and abnormal API behaviour.
- The vendor's position on how pipeline tooling should fit into a broader API protection strategy.
👉 Read Salt's analysis of why build pipeline security does not solve API security →
API security runtime gaps: what build pipeline scanning misses?
Explore further
01/08/2026 10:52 pm
Build-time security has become a governance comfort blanket for API programmes. Organisations often equate passing pipeline scans with having controlled the risk, but the article shows that many of the most damaging API failures are behavioural, stateful, and dependent on runtime context. That means the real control boundary sits after deployment, not before it. The practitioner conclusion is simple: assurance must move from artifact inspection to live behaviour verification.
A question worth separating out:
Q: What is the difference between API testing and runtime API security?
A: API testing checks whether an endpoint meets design expectations before release. Runtime API security checks whether the live service continues to behave safely once it is exposed to real users, service identities, and production data. The difference matters because many API failures are not coding defects alone. They are behaviour and governance failures that only appear in operation.
👉 Read our full editorial: Runtime API security outgrows shift-left scanning and schema checks
