Runtime API security outgrows shift-left scanning and schema checks

At a glance

What this is: This analysis argues that build-time scanning and schema enforcement are not enough to secure modern APIs because business logic flaws, runtime drift, and integration complexity emerge outside the pipeline.

Why it matters: IAM and security teams should care because APIs increasingly carry identity, authorisation, and workload trust decisions that static tools cannot fully validate before release.

👉 Read Salt's analysis of why build pipeline security does not solve API security

Context

Shift-left security reduces risk when it is used for the kinds of problems that can actually be detected early, but API security does not fit neatly into that model. Build pipelines can validate dependencies, schemas, and known vulnerability patterns, yet they cannot reliably prove that an API behaves safely once real users, services, and credentials interact with it. For identity programmes, that gap matters because authorisation, privilege enforcement, and service-to-service trust often only fail in runtime.

The core governance problem is not whether scanning has value. It is whether organisations confuse build-time coverage with complete assurance. In API-heavy environments, that confusion leaves identity-aware controls, business logic checks, and runtime behavioural baselines underdeveloped. The result is a security programme that can look mature in CI/CD while still missing the conditions attackers exploit in production.

Key questions

Q: How should security teams validate APIs beyond build-time scanning?

A: They should combine build-time testing with runtime behavioural monitoring. Build-time tools still matter for dependencies, schemas, and known vulnerability patterns, but they do not verify whether an API behaves correctly once real identities, data, and workflows are involved. The practical test is whether the service can detect abnormal sequences, authorisation abuse, and drift after deployment.

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. They do not reliably capture undocumented endpoints, workflow logic, state transitions, or business rules. That means an API can pass schema checks and still allow privilege escalation, data exposure, or broken authorisation in production.

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. If the control is effective, suspicious traffic should be slowed, challenged, or blocked before it reaches core systems, while legitimate integrations continue to function normally.

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.

Technical breakdown

Why build-time scanning stops short in API security

Static application security testing, dynamic application security testing, and software composition analysis all have bounded visibility. They are effective at identifying known patterns, such as vulnerable dependencies, exposed misconfigurations, and some classes of input validation problems. They are far less effective where the risk depends on context, sequence, or user state. APIs often hide their real behaviour behind business workflows, and those workflows are not fully represented by source code alone. That is why a build pipeline can confirm conformance without proving safety. The technical limitation is not tooling quality alone. It is that many API failures only appear when the system is live, stateful, and integrated with identity and access controls.

Practical implication: Treat build-time scanning as a control gate, not a final assurance model, and pair it with runtime API behaviour monitoring.

Why schema validators miss drift and business logic abuse

Schema validation checks whether requests and responses match a declared contract, usually an OpenAPI or Swagger specification. That helps catch malformed payloads and some structural inconsistencies, but schemas rarely describe every field, rule, or downstream condition that matters to security. APIs also drift from their documentation over time, especially in fast-moving DevOps environments. Even when a schema is accurate, it cannot reliably express business logic abuse such as privilege escalation, broken object-level authorisation, or sensitive workflow bypass. In practice, schema enforcement is a form of positive security, but only for what is explicitly modelled. Anything implicit, undocumented, or changed at runtime remains outside its reach.

Practical implication: Use schema validation for contract enforcement, but do not treat it as a substitute for runtime detection of logic abuse.

Why runtime baselining is the control that closes the gap

Runtime baselining observes how an API normally behaves under real load, real identity, and real transaction patterns. Instead of asking whether the request format is valid, it asks whether the behaviour makes sense for the application, user, or workload. This matters because many API attacks are not malformed requests but legitimate-looking requests used in unexpected sequences. Behaviour analysis can surface anomalous access patterns, unusual privilege use, and interactions that violate the intended business process. For identity and access teams, this is the point where API security becomes an authorisation and governance problem, not just an application testing problem. Runtime context is what static analysis never gets.

Practical implication: Build detection around behavioural baselines so you can catch abuse that looks valid at the request level.

Threat narrative

Attacker objective: The objective is to use a trusted API path to trigger behaviour that bypasses intended access controls or exposes data and functions the pipeline never verified.

1. Entry occurs through a valid-looking API request or a pipeline-borne application change that passes static checks and schema validation.
2. Escalation happens when the attacker or misuse pattern exploits undocumented logic, drift, or weak authorisation paths that the build pipeline never modelled.
3. Impact follows when the API behaves in an unintended way, exposing data, bypassing controls, or enabling business logic abuse at runtime.

NHI Mgmt Group analysis

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.

Runtime behaviour is the missing control plane for API authorisation risk. Static tools can identify some vulnerable code paths, but they cannot reliably evaluate whether an API honours business rules, identity context, or transaction sequencing under load. This is where the identity intersection becomes explicit, because APIs are increasingly the enforcement point for service identities, delegated access, and machine-to-machine trust. Teams should read this as a signal that runtime authorisation monitoring is now a core governance control, not an optional enhancement.

Schema validation creates a false sense of completeness when documentation and implementation drift apart. OpenAPI and Swagger help define contracts, but they do not guarantee that the contract reflects what is really running. That gap grows in organisations with weak documentation discipline, fragmented development ownership, or multiple build pipelines. The practitioner implication is that policy and assurance must account for undocumented fields, shadow endpoints, and changed workflow logic rather than only the published schema.

API security maturity now depends on the ability to see business logic abuse, not just CVEs. The article is right to distinguish between known vulnerability scanning and the deeper problem of abuse that follows allowed paths. That shift mirrors a broader trend in security governance: the hardest problems are increasingly those that look compliant at the technical layer but fail at the behavioural layer. Teams should treat runtime baselining as the evidence standard for what their APIs actually do.

What this signals

API security programmes are moving from release confidence to behavioural confidence, and that shift has direct implications for identity-aware controls. If an API is the enforcement point for service identities, delegated access, or machine-to-machine trust, then runtime authorisation monitoring becomes part of identity governance rather than a separate application security concern.

API drift debt: when the live service no longer matches the documented contract, static testing loses much of its assurance value. Teams should expect more pressure to prove what production actually does, not what the build said it would do, and to align runtime monitoring with identity context and business process evidence.

For practitioners

• 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.
• Baseline identity-sensitive API activity. Track which service accounts, tokens, and delegated identities normally invoke each API and alert on unexpected combinations, volumes, or transaction order.

Key takeaways

• Build-time scanning reduces risk, but it cannot prove that an API will behave safely once real identities and workflows are in play.
• Schema validation and dependency scanning are necessary controls, yet they miss drift, undocumented behaviour, and business logic abuse.
• Runtime baselining is becoming the decisive control because it measures how APIs actually behave under production conditions.

Key terms

• Runtime Behaviour Baseline: The expected pattern of activity for an identity while it is operating in production. It goes beyond entitlement lists by comparing actual actions, timing, and access paths, which is critical when valid credentials can still be abused.
• API Endpoint: A network-accessible route that lets a client interact with a resource or operation. In practice it combines the resource location, the HTTP method and the security contract that decides who or what may use it.
• Business Logic Abuse: Business logic abuse occurs when an attacker uses a valid API in a way the application designer did not intend, such as exceeding limits, chaining actions, or misusing workflow assumptions. The API is functioning technically, but governance and policy are failing at the intent layer.
• Positive Security Model: A positive security model allows only known-good behaviour and blocks everything else. In API programmes it is often implemented through schemas or allowlists, but that approach only works for what can be explicitly modelled, leaving runtime context and undocumented behaviour outside its protection boundary.

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.

👉 Salt's full post expands on the limits of scanning, schema checks, and runtime blind spots in API protection.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. Explore how identity governance principles apply when machine and service identities become part of your control surface.