SAST and DAST miss runtime API risk without identity context

At a glance

What this is: This analysis argues that SAST and DAST remain useful but are insufficient alone for API-first security because modern API failures depend on runtime identity, workflow, and data context.

Why it matters: It matters to IAM and security practitioners because API authorisation failures, token handling, and service-to-service access patterns now sit at the intersection of application security and identity governance.

By the numbers:

• APIs now drive more than 83% of internet traffic as internal and external integrations proliferate.
• 57% of enterprises report API related data breaches in the past two years.
• 99%, rly all enterprises, 99%, experience API related security issues annually.

👉 Read LEVO's full analysis of SAST, DAST, and API security risk

Context

APIs have become the connective tissue of modern software delivery, but the security model around them still lags behind how they are actually used. Static and dynamic testing each catch part of the problem, yet neither was designed for systems where identity, token state, workflow sequencing, and data movement determine whether a request is safe or exploitable. In API-first environments, the governance gap is often not visibility alone but contextual understanding of who or what is allowed to do what, when, and across which services.

That gap becomes sharper in programmes that already manage non-human identities, service accounts, and automation credentials. API testing that ignores runtime identity can miss broken object-level authorisation, privilege misuse, and workflow abuse, while also generating noise that slows remediation. This is a familiar failure mode in cloud and application security, but it is especially relevant where service-to-service access and machine identities now carry production authority.

Key questions

Q: How should security teams test APIs that depend on tokens, scopes and roles?

A: They should build tests around the actual identities and entitlements that call the API, then validate whether each token can only perform the actions it is supposed to perform. This means exercising positive and negative cases for object-level access, workflow state and delegated access, not only checking for generic runtime errors. Identity-aware testing gives more reliable assurance than black-box scanning alone.

Q: Why do SAST and DAST still miss broken object-level authorisation?

A: Because BOLA depends on whether a caller is entitled to a specific object at a specific moment, not just whether code looks unsafe or a live request succeeds. SAST cannot observe runtime entitlement, and DAST often lacks enough discovery and workflow context to exercise the exact access path. The failure is contextual, so the test must be contextual too.

Q: What are the signs that API penetration testing is missing real risk?

A: If a programme only tests a supplied endpoint list, reports many alerts without proof of exploit, or misses undocumented APIs, it is probably under-covering the true attack surface. Another warning sign is treating authorization failures as low-priority because they are not injection issues. Real risk shows up when testing can prove cross-user access or workflow abuse.

Q: Should organisations prioritise API discovery before deeper vulnerability testing?

A: Yes, when the estate is incomplete or fast-changing. If you cannot reliably identify all exposed APIs, deeper testing will understate risk because it will miss services that are live, reachable, and potentially sensitive but absent from the original scan plan.

Technical breakdown

Why SAST misses API authorisation failures

SAST examines source code, bytecode, or binaries before deployment, so it can identify insecure patterns, unsafe functions, and obvious hard-coded secrets. What it cannot reliably see is how a request behaves once tokens, roles, session state, and service-to-service relationships are enforced at runtime. API authorisation flaws often emerge across multiple services and decision points rather than inside a single function. That means static findings may describe a possible weakness while missing the real control failure that appears only when the API is exercised in production-like conditions.

Practical implication: use SAST to catch code-level defects early, but do not treat it as proof that API access control works correctly in production.

How DAST works against live APIs

DAST tests a running application from the outside by sending requests, observing responses, and comparing behaviour to expected security controls. For APIs, that requires handling authentication, endpoints, payload shapes, and workflow state so the test reflects real access paths rather than anonymous probing. The value is exploitability testing, not code inspection. The limitation is that DAST only sees what it can reach and understand, so discovery gaps, complex delegation chains, and multi-step business logic can leave blind spots even when the scanner is technically accurate on the requests it can make.

Practical implication: validate DAST coverage against live API inventory, authentication paths, and workflow complexity before trusting the findings.

Why API-native security needs identity and workflow context

APIs are not isolated endpoints. They are policy-enforced interactions across identities, services, data objects, and business workflows. Many of the most damaging API issues, such as broken object-level authorisation and workflow abuse, depend on whether a caller should have access to a specific object at a specific step with a specific token. That is why runtime-aware discovery, sensitive data mapping, and identity-driven analysis matter. Without them, teams test fragments of behaviour while the actual attack surface is defined by distributed access decisions.

Practical implication: pair testing with continuous discovery and identity-aware analysis so security controls follow the real API lifecycle.

Threat narrative

Attacker objective: The attacker objective is to use legitimate-looking API interactions to access data or execute actions beyond intended authorisation boundaries.

1. Entry occurs through exposed API surfaces that accept authenticated or semi-authenticated requests, often behind tokens or service credentials.
2. Escalation happens when access control, object binding, or workflow state is evaluated incorrectly across requests or services.
3. Impact follows when an attacker can read, modify, or abuse data and business actions through authorised-looking API calls.

NHI Mgmt Group analysis

Static and dynamic testing are necessary controls, but they are not identity governance for APIs. SAST and DAST tell teams different things about code and runtime exposure, but they do not model whether a service account, token, or delegated workflow should be allowed to reach a given object. That leaves a governance gap where security evidence exists, yet authorisation remains unproven. Practitioners should treat API security as an identity-and-policy problem, not only a testing problem.

API security now creates an NHI governance problem as much as an AppSec problem. Service accounts, API keys, and OAuth-bearing machine workflows frequently carry production authority across distributed systems. When those identities are not continuously inventoried and contextualised, test results become detached from the access reality they are supposed to validate. That is why API programmes increasingly need NHI visibility alongside application testing.

Runtime context is the named concept that separates useful testing from noisy scanning. In API-first environments, the real control boundary is not the endpoint itself but the combination of identity, object, and workflow state at the moment of execution. Security teams that cannot model runtime context will keep missing authorisation failures while overestimating the value of isolated findings. Practitioners should reframe API assurance around runtime context, not scanner output volume.

Broken object-level authorisation remains the archetypal API failure because it is a policy problem disguised as a request problem. The vulnerability appears simple in reports, but the real issue is that the system trusts a request to prove entitlement when entitlement is actually contextual. That is why static rules and generic runtime probes miss so many cases. Security leaders should evaluate whether their API controls can answer the entitlement question, not just whether they can flag anomalies.

The market signal here is that API security is converging with identity security. As automation, microservices, and cloud-native delivery expand, the distinction between application testing and credential governance keeps narrowing. API programmes that ignore machine identity will struggle to explain why exploitable paths remain after traditional testing. Practitioners should align AppSec, IAM, and NHI ownership around the same runtime attack surface.

What this signals

API security programmes are moving toward identity-centred assurance because runtime exposure now depends on who or what is calling the service, not only on what the code does. For NHI-heavy environments, that means continuous discovery, token governance, and workflow validation become part of the same control plane. The practical signal is simple: if testing cannot explain authorised machine access, it cannot explain API risk.

Runtime context debt: this is the growing gap between what scanners can observe and what distributed systems actually allow. Teams should expect more pressure to connect AppSec, IAM, and workload identity evidence into a single validation workflow. Without that connection, remediation will keep chasing findings instead of reducing exposure.

For practitioners

• Map API testing to real identity paths Inventory the service accounts, OAuth clients, API keys, and session types that actually reach production APIs, then tie each testing scope to those identities rather than to endpoint lists alone.
• Add workflow-aware test cases Prioritise multi-step business flows, object-bound actions, and delegated access paths where authorisation depends on request order, token state, or object ownership.
• Correlate findings with runtime discovery Use continuous API discovery and sensitive data mapping so SAST and DAST results can be validated against the current attack surface instead of stale specifications.
• Separate code defects from exploitability Route SAST findings into development remediation, but use DAST and runtime controls to confirm whether a weakness is reachable, authenticated, and materially exploitable in production.

Key takeaways

• SAST and DAST remain useful, but neither is sufficient on its own for API-first environments where authorisation depends on runtime identity and workflow state.
• API risk is increasingly an NHI governance issue because service accounts, tokens, and delegated workflows often carry the authority that scanners cannot fully model.
• Continuous discovery, identity-aware analysis, and workflow testing are the controls that turn API testing from noisy inspection into actionable assurance.

Key terms

• Dynamic Application Security Testing: Dynamic Application Security Testing evaluates a running application from the outside to identify weaknesses that only appear under real execution conditions. It is useful for validating authentication, session handling, and API behaviour, especially where configuration and integrations change how the system actually responds to attack.
• Static Application Security Testing: Static Application Security Testing is a method for finding security flaws by examining code, binaries, or configuration without executing the application. It is strongest when used early in development, where teams can fix issues before deployment and prevent avoidable defects from reaching production.
• Broken Object-Level Authorization: A failure to check whether an authenticated identity may access a specific object, record, or device. The request succeeds because the credential is valid, but the application does not enforce per-object entitlement. In NHI environments, this turns a legitimate token into cross-resource exposure.
• Runtime Context: Runtime context is the set of signals used to judge whether an AI agent's behaviour is appropriate while it is acting. It includes identity, data access, model behaviour, posture, and environment. In practice, it is the difference between checking permission and evaluating purpose.

What's in the full article

LEVO's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step explanations of how the platform handles authentication across OAuth, JWT, API keys, and mutual TLS.
• Detailed breakdowns of the runtime discovery and documentation workflow used to map live API surfaces.
• Operational examples of how specific findings are tied to real requests, real identities, and real data paths.
• The vendor's full treatment of how API security testing fits into CI and CD workflows at implementation stage.

👉 LEVO's full article includes the runtime testing workflow, architecture details, and the API-native controls behind its analysis.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and workload identity. It helps security practitioners connect identity control to the wider programmes they already run.