Business Logic Testing
Traditional SAST tests for patterns. This tests for behaviour: it derives your application's security-critical invariants from source, then proves where they break with a working exploit.
Six classes pattern scanners miss
State management
Invalid transitions
Invalid state transitions, or state checks that were never written.
Authorization logic
Privilege escalation
Flawed permission models and the escalation paths they open up.
Race conditions
Concurrency
Logic that holds in sequence and fails when two requests arrive at once.
Data validation gaps
Rule bypasses
Business rules bypassed through input sequences nobody anticipated.
Workflow violations
Out of order
Operations the application permits in an order it should not allow.
Invariant violations
Broken assumptions
Assumptions about data consistency that the code stops honouring.
Four phases, one pipeline
Business logic testing is the logic-flaw arm of the whitebox pentest. Discovery runs as the final phase of the SAST pipeline, and every finding is validated and reproducible before it ships. No exploit, no report.
Phase 01 · Discovery
Discovery Agent
Reads your code end-to-end and defines your business invariants, the security-critical rules unique to this application: multi-tenant data isolation, checkout totals that must never go negative, role boundaries, rate-limit enforcement, state transitions that should not be skippable.
Phase 02 · Violations
Violation Search
Walks the codebase looking for the places each invariant breaks. Missing authorization checks on admin endpoints, tenant filters that fall to parameter tampering, payment flows validating the amount client-side only.
Phase 03 · Confirm
Confirm Violations
Each candidate is confirmed against the actual code to rule out false positives. Only confirmed violations advance to the exploit phase.
Phase 04 · Exploit
PoC Exploits
Every confirmed finding gets a full proof-of-concept with step-by-step reproduction: the exact requests, parameter values and sequencing needed to demonstrate it in a running environment.
Findings emit as SARIF 2.1.0 and merge with SAST, secrets and SCA through the same canonical deduplication: one dashboard, reproduction steps attached.
The same class, opposite correct behaviour
Business invariants are not generic patterns. They describe what your application is supposed to do: the rules that hold for your data, your tenants, your workflows.
Application type · Banking
Strict multi-tenant isolation
Account balances, transaction logs and user records must never cross a tenant boundary. Any path that lets one tenant observe another is a finding.
Application type · Social media
Tiered visibility by audience
Some information is meant to be platform-wide. The invariants are about what stays private to a user, what is visible only to followers, and what is fully public.
A pattern-based scanner cannot tell those two apart. Keygraph derives the invariants from your source, then the whitebox pentest exploits the places they break.
See where your invariants break
Schedule a technical demo and watch it run against your staging environment: it derives your application's invariants, confirms the violations, and builds a proof-of-concept for every finding.