Skip to main content

Code to Runtime

apPosture is uniquely both a SAST and a DAST platform, and API Security uses that to answer a question point tools cannot: for each API endpoint, is it proven in your source, seen at runtime, or both?

Provenance​

Every endpoint carries a provenance label:

  • Code + Runtime - declared in source and observed live. The strongest signal: a real, running endpoint you also control the code for.
  • From source - present in code but not yet seen at runtime. Could be unreleased, unreachable, or simply untested - worth checking.
  • Runtime only - observed live but absent from source. Often a shadow or third-party endpoint, or one that drifted away from the codebase.

Why it matters​

A runtime-only endpoint handling PII is exactly the kind of thing a scanner that only reads code, or only probes traffic, will miss. By fusing the two, API Security surfaces the gap between "what we built" and "what is running" - and flags the sensitive, unauthenticated members of that gap as toxic combinations.

Proof-first auth state​

Auth state follows the same evidence-first rule as the rest of the engine. An endpoint is only marked proven public when a verified finding demonstrates unauthenticated access - it is never inferred from a status code. Until then it is "not provably authenticated," which is what feeds the toxic-combination verdict.

Where the signal comes from​

  • Source - SAST route/endpoint modeling from connected repositories.
  • Runtime - DAST traffic, plus optional runtime log correlation from your gateway or WAF.

The result is one KPI on the overview - code-to-runtime coverage - and a per-endpoint badge in the inventory drawer.

Last updated on