Proof methodology

A finding is raised only when it is proven.

Most tools report what might be wrong. apPosture raises a finding only after it confirms the issue with real, in-band evidence - so engineering can trust the queue and act without re-triaging.

The ladder

Confirmed - reachable - likely - inferred

Every finding carries an honest status. We never label something "proven" without evidence, and we never silently downgrade a real risk.

Confirmed

A real, in-band exploit succeeded - DOM-XSS executed a marker, SQLi was confirmed differentially or by an arithmetic oracle, a blind class was confirmed out-of-band. Ships with a PoC request/response.

Reachable

Static/SCA evidence shows the vulnerable code is actually imported and reachable from an entry point - prioritized over dead code, but not the same as a proven exploit.

Likely

Strong but not in-band proof (for example a one-account BOLA where no clean anonymous boundary exists). Routed to triage, never over-claimed as confirmed.

Inferred

Modelled from facts (IaC, source, dependency graph) but not yet exercised by a scan - shown as a blind-spot to go and prove.

Confirmation

How a gap earns proven

  • Differential - same request, two states; only a real flaw changes the response in the predicted way.
  • Arithmetic oracle - the app evaluates an expression only an injection would (e.g. 7919 * 7907 = 62615533).
  • Marker execution - DOM-XSS is confirmed by executing a benign nonce, not by matching a pattern.
  • Out-of-band (OAST) - blind classes confirmed via a callback; off by default for air-gapped installs.
  • Cross-engine - DAST + SAST + SCA agreement on the same root cause raises confidence and dedupes to one issue.
[confirmed] SQL Injection · /api/orders oracle: arithmetic (62615533) · evidence: PoC req/resp [confirmed] DOM-XSS · /search marker executed [reachable] CVE-2024-… lodash imported · on request path [likely] BOLA · /api/users/{id} (1-account, no anon boundary) [inferred] Public RDS (IaC fact - go prove)
Discipline

Safe by design - and severity-honest

Safe probes only

Benign markers and nonces, read-only where possible. No real outbound exploit, no destructive verbs (DELETE/PUT/transfer), no DoS or bursts against live targets.

No over-claim, no under-rate

Parser-confirmed is not RCE; reachable is not proven. But a method-invoking SpEL/EL injection is critical RCE, and file-read / cloud-metadata SSRF is critical - severity reflects real impact.

Benchmark & accuracy

The one number you can verify yourself

Our headline accuracy comes from the public OWASP Benchmark 1.2 - an open, ground-truth suite of 2,740 Java test cases with known true and false positives. It is the one accuracy claim you can reproduce.

What it measures

True vs false positives across every vulnerability category, scored cross-category - not cherry-picked per class.

Our result

100% precision, 99.4% recall on the SAST run against the public suite - a Youden index near 1.0.

What it is not

A Java SAST ground-truth, not a claim about every language, engine or real-world app. Your codebase is the real test - which is what the PoC is for.

Run it against your own applications during a controlled PoC and compare.

Want to see the evidence on your own app?

We will prove a finding end-to-end in your environment - request, response and attack chain.