The vulnerabilities a scanner can’t see

The flaws that cost companies the most are rarely the ones with a CVE. They are baked into how the application is supposed to work: a coupon that stacks when it should not, an invoice that belongs to another tenant, a refund that credits the wrong wallet, a checkout that lets you set your own price.

These are business-logic flaws, and they are invisible to signature-based tools for a simple reason: nothing about the request looks malicious. The payload is valid. The syntax is clean. The server does exactly what it was told. The bug is that it should never have been told to.

Why signatures miss them

A scanner recognises patterns it has seen before: an apostrophe that breaks a query, a script tag that reflects, a path that traverses. Business logic has no such pattern. “Change the invoice id from 1042 to 1043” is indistinguishable from normal use. There is no signature for “this user should not be allowed to do this.”

Finding these flaws requires understanding intent, not syntax. What is this endpoint for? Who is supposed to call it? What invariant is it quietly assuming, and what happens when you break that assumption?

How we test for intent

SpikeFlare reasons about the application the way an attacker does. It maps roles and objects, forms hypotheses about the rules the app assumes, and then tries to violate them: reading an object it should not own, replaying a state change, stacking an operation that was meant to be idempotent.

Crucially, a language model is good at imagining these attacks and bad at judging whether they worked. So the model only proposes. A deterministic oracle, measuring real state change on the server, is the only thing allowed to confirm. That division of labour is what lets us go after logic flaws without drowning you in false positives.

It is also where the real damage lives. An attacker does not need a zero-day when your checkout will accept a negative quantity.