Why do vulnerability scanners miss business logic flaws?

Because a business logic flaw is not a pattern. A scanner matches signatures: known CVEs, vulnerable dependency versions, missing headers, common injection points. A broken tenant boundary or an out-of-order workflow abuse is made of individually well-formed requests, so there is nothing malformed to match against. The vulnerability lives in an assumption about how your application is meant to behave, and that assumption is not written anywhere as a detectable string.

What is code-aware application security testing?

Testing that reads the source code to understand the application before attacking it, rather than probing it blindly from the outside. Knowing the routes, auth flows, middleware chains and data flows means tests can be aimed at the logic that actually carries risk, including routes that never appear in a sitemap. It is different from static analysis: static analysis inspects the code and stops there, while code-aware testing uses the code to plan an attempt against the running application and then confirms what is genuinely exploitable.

Does continuous pentesting replace SAST and dependency scanning?

No, and treating it as a replacement is a mistake. Dependency scanning, secret detection and configuration checks are cheap, fast and good at breadth, and they should run on every commit. Continuous offensive testing answers a different question: whether a specific path through your application can actually be exploited. Most teams need both, running at different frequencies and catching different classes of problem.

How do you know a pentest finding is real?

By demanding proof rather than a severity label. Mjolnir returns findings marked verified in Odin with a working proof-of-concept exploit and a suggested code fix attached, so a developer can reproduce the issue before deciding how to fix it. Verification also matters at the other end of the lifecycle: findings move from reported to mitigating to ready for retest and only then to fixed and retested, so a remediation is confirmed rather than assumed.

Back on Articles page

8 June 2026

Your scanner didn't find it. Mjolnir did.

1 min. readBy Hans

Most security teams rely on automated scanners to catch vulnerabilities before they go live. The problem is that scanners are pattern matchers. They check for known signatures, run through a list of published CVEs, and call it a day. They do not reason about state. They do not chain findings together. And they do not test your business logic. That is the gap Mjolnir was built to fill.

What scanners are actually good at

Start with the fair version, because the straw man helps nobody. Scanners are good at breadth and repetition. Dependency scanning catches the vulnerable package you pulled in six months ago. Secret detection catches the key someone committed on a Friday afternoon. Configuration checks catch the missing security header and the storage bucket that was never meant to be readable. Signature-based detection catches the known injection point in a known framework version.

That work matters, it is cheap, and it should run on every commit. Nobody serious argues otherwise.

What they structurally cannot do

The limit is not effort or tuning. It is that most high-impact application vulnerabilities are not patterns. They are consequences of your specific rules.

Consider a multi-step approval flow. The first request validates that the caller belongs to the tenant. The second request completes the action, and because step one already ran, it trusts the record identifier that arrives in the body. Send the second request on its own, carrying a record identifier that belongs to another customer, and the check that was supposed to protect the boundary never runs.

Every individual request in that sequence is well formed. There is no vulnerable dependency, no published CVE, no malformed input, nothing to match against. The vulnerability lives in the assumption that step two only ever follows step one, and that assumption appears nowhere in the code as a string a scanner could find.

The same shape shows up across the surfaces that actually hurt. An IDOR that only appears when a workflow is driven out of order. A role check applied at the route but never on the underlying record. A billing endpoint that accepts a quantity the pricing logic later trusts. A token scope quietly widened by a refactor. In custody and signing systems the equivalent is sharper still: a boundary between an off-chain instruction and an on-chain action where authorisation is verified once and then reused.

Finding those requires two things a scanner does not have. An understanding of what the application is supposed to allow, and a willingness to attempt the thing that should not work.

How Mjolnir works differently

Mjolnir provides ongoing offensive testing against live applications to identify real, exploitable security issues.

From there it plans and executes. It generates targeted test cases against the functionality that carries real risk, producing verified findings with reproduction steps. Each run provides ongoing offensive testing against live applications, resulting in verified findings.

The output is the part that matters to an engineering team. Findings arrive with reproduction steps, so the first question a developer asks is how to fix it rather than whether it is real.

Not a checklist. An actual assessment.

Catching it before it merges

A pentest that runs after deployment still leaves a window. Gungnir closes it from the other side, reviewing pull requests with greater code awareness than a standard static scan. It provides security review for risky pull requests before they reach production.

That is the practical difference between finding a broken tenant boundary in review and finding it in production.

Continuous, not periodic

Traditional pentests typically occur on a scheduled basis. Between those engagements your attack surface changes with every deployment, and the report ages into a description of an application that no longer exists.

Mjolnir runs manually or on a schedule, so regressions and new issues surface as the code evolves. Findings land in Odin and move through a workflow where they are tracked and automatically retested once fixed. That last state is the one teams usually lack. A remediation marked done without verification is a finding you have stopped looking at, not a finding you have closed. The same applies to where the work lands, which is why findings are integrated into existing development tools rather than into a PDF.

Where this leaves your scanner

Keep it. Dependency, secret and configuration scanning solve real problems cheaply, and they are not competing for this job. Run them on every commit, and stop expecting them to answer a question they were never designed to answer.

Your scanner gives you the known patterns. Mjolnir gives you the findings your scanner was never built to catch, with the proof attached.

Frequently asked questions

Why do vulnerability scanners miss business logic flaws?: Because a business logic flaw is not a pattern. A scanner matches signatures: known CVEs, vulnerable dependency versions, missing headers, common injection points. A broken tenant boundary or an out-of-order workflow abuse is made of individually well-formed requests, so there is nothing malformed to match against. The vulnerability lives in an assumption about how your application is meant to behave, and that assumption is not written anywhere as a detectable string.
What is code-aware application security testing?: Testing that reads the source code to understand the application before attacking it, rather than probing it blindly from the outside. Knowing the routes, auth flows, middleware chains and data flows means tests can be aimed at the logic that actually carries risk, including routes that never appear in a sitemap. It is different from static analysis: static analysis inspects the code and stops there, while code-aware testing uses the code to plan an attempt against the running application and then confirms what is genuinely exploitable.
Does continuous pentesting replace SAST and dependency scanning?: No, and treating it as a replacement is a mistake. Dependency scanning, secret detection and configuration checks are cheap, fast and good at breadth, and they should run on every commit. Continuous offensive testing answers a different question: whether a specific path through your application can actually be exploited. Most teams need both, running at different frequencies and catching different classes of problem.
How do you know a pentest finding is real?: By demanding proof rather than a severity label. Mjolnir returns findings marked verified in Odin with a working proof-of-concept exploit and a suggested code fix attached, so a developer can reproduce the issue before deciding how to fix it. Verification also matters at the other end of the lifecycle: findings move from reported to mitigating to ready for retest and only then to fixed and retested, so a remediation is confirmed rather than assumed.