Does autonomous pentesting replace a vulnerability scanner?

Not usefully. They answer different questions. A scanner asks whether a recognisably dangerous construct is present, which covers published dependency advisories, misconfigurations and injectable sinks, and it does that across a wide estate cheaply. Autonomous pentesting asks whether a prohibited action succeeds against the running application, which is where access control and workflow flaws live. Dropping the first to fund the second can leave a gap in coverage that the scanner was addressing.

Why can a clean scan sit alongside a real vulnerability?

Because a scanner works from a general catalogue of dangerous constructs, and your application's own rules are not in it. That only a billing role may change a plan, or that an order belongs to one organisation, is usually enforced by code rather than declared anywhere a tool can read. When such a rule is not enforced, there is often no dangerous construct present to match. Something that should have been present is absent.

What does a finding from autonomous pentesting look like?

A record of an attempt that succeeded, rather than a pattern that matched. In practice that tends to mean the request sequence used, the account or tenant it was made from, what came back, and enough detail for somebody to repeat it. The practical difference is what you do with it: a matched pattern still needs someone to work out whether it is reachable, while an attempt that worked has already answered that question for the specific path it took. It says nothing about the paths a given run did not reach. Where findings are retested after a fix, re-running the same attempt provides a direct way to establish whether that exploit path is still working.

What does autonomous pentesting not cover?

Its coverage is bounded by the context available to it. Configuration that exists only in a cloud console or a third-party dashboard, the behaviour of external services, and business rules that live only as undocumented assumptions can fall outside its view, and may need human or specialised testing. Access matters too: testing a tenant boundary means holding credentials for more than one tenant, and testing a billing transition means an environment where that transition can be attempted safely.

Which should a small team run first?

Start with whichever failure you would least like to find out about late. If your estate is wide and shallow, many services and repositories with no baseline across them, scanning covers that ground cheaply and little else does. If the risk that would hurt most sits in your own authorisation, tenancy or billing logic, that is the class a catalogue cannot describe, and something that attempts the action is the better first purchase. One precondition is easy to miss either way: testing by attempting an action needs an environment where that action can safely be attempted, so it is worth sorting that out before buying something that depends on it.

Back on Articles page

28 August 2026

Autonomous Pentesting vs Vulnerability Scanning: What Each Finds

12 min. readBy Borg

Teams usually arrive at this comparison trying to work out whether one of these replaces the other. They do not, and the more useful question is which one answers which question.

A vulnerability scanner asks whether something recognisably dangerous is present. A published advisory against a declared dependency. An injectable sink reachable from user input. A credential committed to a configuration file. A storage bucket left readable. These are properties that can be expressed as rules and evaluated without anyone reasoning about what your particular application is supposed to do.

Autonomous pentesting asks whether security weaknesses can actually be exploited against the running application. For example, rather than asking whether a pattern resembling an access-control bug is present, it can test whether this account can in fact read that record.

Those two questions can have different answers on the same codebase, and success in one does not establish success in the other. A clean scan can coexist with a broken authorisation boundary, because that boundary may never have been expressed as a pattern for a scanner to match. What follows is what each approach reaches, where each stops, and when each is the better use of the next unit of effort.

Why a clean scan and a real vulnerability can coexist

The reason is that the two are measuring different things, and only one of them is written down anywhere.

Many vulnerability scanners work from a catalogue of known weaknesses or detectable conditions. Somebody has described a dangerous construct, vulnerable component, or insecure configuration in a way the tool can evaluate: this call on untrusted input, this dependency at this version, this header absent, this permission set to public. When the relevant condition is present, the tool can flag it. The catalogue is general because it has to be, and that generality is what makes it possible to apply the same checks across many codebases.

An application's own rules are not in that catalogue. That only an account with a billing role may change a plan. That a support agent may read a ticket but not the card on file. That an order belongs to exactly one organisation. These are specific to your product, and in most codebases they are enforced by code rather than declared anywhere a tool can read. A violation of one of them often looks like ordinary working code, because there is no dangerous construct present. Something that should have been present is absent.

That is the whole of the gap, and it is not a criticism of scanning. A missing check has no signature, so an instrument built on signatures has little to match. Reaching that class means executing the action and observing what happened, which is a different kind of tool for a different kind of work.

What a vulnerability scanner reaches

Start with the case for scanning, because it is a strong one and it tends to get undersold in comparisons like this.

Scanners cover the classes where a weakness can be described once and then checked everywhere. Software composition analysis reads your declared dependencies and matches them against published advisories. Static analysis examines source without executing it and flags constructs associated with known weaknesses, such as an unparameterised query, deserialisation of untrusted input, or a secret in a configuration file. Cloud posture scanning checks resources against a baseline. Dynamic scanning exercises the running application with generic payloads and reports what came back.

Three things follow from that shape, and they are advantages rather than consolations.

Placement is often cheap. Many scanners can be integrated early in development and run repeatedly as the codebase changes, with feedback landing close to the change that caused it.

Breadth is genuinely wide. A team with a large estate of services, hosts and repositories can establish baseline coverage across all of it without manually deciding where to look first. That breadth is one of scanning's strongest advantages.

Advisory tracking is work you should not be doing by hand. A dependency that was fine last month can acquire a serious advisory this month with no change to your code at all. That is a monitoring problem, and automation solves it properly.

The limits are real too, and worth knowing in the specific rather than the abstract.

Reachability is the first. A matched pattern is not the same as an exploitable path. Some analysers can say whether a match is reachable from an entry point at all, and that distinction tends to do more for a triage queue than almost anything on a datasheet.

Accuracy varies more than a single figure would suggest. NIST's SATE V report (NIST SP 500-326) evaluated static-analysis tools across both synthetic and real-world Java code and reported substantially different results depending on the dataset and metric used. On the synthetic Java test cases, the evaluated tools achieved precision ranging from 78 to 94 percent, averaging 85 percent. On the real-world Java track, NIST's stricter useful-precision measure ranged from 22 to 79 percent across the tools evaluated, averaging 61 percent. NIST cautions that synthetic cases are smaller and less complex than production software, so results from those tests should not be treated as a direct prediction of what a team will see on its own code. The OWASP Benchmark illustrates the same trade from another angle: on the Java v1.2 benchmark, FindSecBugs v1.4.6 reported a 96.84 percent true positive rate and a 57.74 percent false positive rate. These figures illustrate why coverage and false-positive rates need to be considered together, and where a given tool sits on that trade depends on the tool, configuration and workload.

Application-specific rules are the third limit, and the one this comparison turns on. Some analysers let you author custom rules, and encoding the invariants you can express cleanly is worth doing. That approach still has limits, because many application-specific invariants are difficult to express completely as static patterns in the first place. There is more on that boundary in SAST and business logic vulnerabilities.

What autonomous pentesting reaches

Autonomous pentesting works from the other end. Rather than matching a construct in source, it operates against the running application, attempts actions that should not succeed, and reports the ones that did.

The mechanics matter because they determine the coverage. Reading the repository indicates where the interesting paths are: which endpoints resolve a record from a caller-supplied identifier, where a tenant boundary is enforced, which transitions a workflow permits. Executing against the running application is what turns a candidate into an answer. A finding is the record of an attempt that worked, which is why it can carry the steps needed to reproduce it.

Chaining is where this diverges most from a scan, and the mechanics are easier to follow hypothetically. Suppose an endpoint discloses an internal identifier that was not meant to be visible. On its own that is low severity, and a reasonable team might defer it. If a second endpoint accepts that identifier as sufficient proof of ownership, the pair can become an authorisation bypass or, depending on what the second action permits, a much more serious compromise. Neither half necessarily matches a dangerous pattern on its own. The severity lives in the relationship between them, and finding it means having tried the second request with the output of the first.

Retesting is the other structural difference. Re-running the same attempt against the deployed change provides a direct way to establish whether the attempted exploit path is still working, rather than relying solely on reasoning about the diff.

The limits belong in the same section, and they are not small.

Context bounds coverage. Reasoning from the repository and the running application means anything represented in neither can fall outside the view: configuration that exists only in a cloud console or a third-party dashboard, the behaviour of an external service, a rule that lives only as an undocumented assumption. Those may still need human or specialised testing.

Access bounds coverage too. Testing a tenant boundary means holding credentials for more than one tenant. Testing a billing transition means an environment where that transition can be attempted safely. Coverage tends to track how much of the application the testing configuration can actually reach, which is a setup question as much as a capability one.

And it does not substitute for a researcher reasoning about an unusual architecture. The systematic half is the part automation handles well: enumerating every endpoint that resolves a record by identifier, checking which of them carry an ownership check, and re-running that after each change is patient work. Someone looking at a strange design and forming a hypothesis nobody catalogued is a different exercise.

Where each approach sits

The comparison is more useful between categories of approach than between named products, because most teams past a certain size run several of these at once.

Approach	What it answers well	Where it stops
Dependency and configuration scanning	Whether a declared component carries a published advisory, or a resource sits outside a known-good baseline	Says less about whether the vulnerable path is reachable in your application, so a matched advisory still needs triage
Static analysis	Whether a known-dangerous construct is present in source, cheaply enough to run on every commit	Analyses source rather than exercising the application, so application-specific authorisation and workflow invariants that are not expressed as detectable conditions can remain outside its coverage
Dynamic scanning	How the running application responds to generic payloads, with no need for source access	Coverage depends on how much of the application the configuration reaches, so routes, states and multi-step flows outside it stay untested
Custom static rules	Invariants you can express as a pattern, checked continuously once written	Covers only the invariants somebody wrote down, which is usually a minority of the ones that matter
Autonomous pentesting with code context	Whether a prohibited action succeeds against the running application, including cross-tenant and multi-step cases	Reasons from the repository and what is reachable at runtime, so anything configured outside those sources, or needing credentials it does not hold, can fall outside its view

None of those rows is a criticism of the others. They answer different questions, and a team running only one of them has a gap shaped like whichever ones are missing. Where the feedback lands also differs, which is the subject of full pentest vs PR security review.

The classes that sit on one side of the line

Three classes come up repeatedly in multi-tenant software, and they share a property. The code runs as written, and what was written was incomplete.

Object-level authorisation. A handler resolves a record from an identifier the caller supplied. The query is parameterised, the input is validated, the session is real. If the handler never confirms that the requesting account owns that record, the endpoint returns somebody else's data. At the level a pattern can inspect, the request is hard to distinguish from a legitimate one, because the only thing wrong is a relationship between a user and a record that was never checked.

Tenant isolation. Whether organisation A can reach organisation B's records depends on how your particular tenancy model is enforced across your particular service boundaries. There is no general rule for it because there is no general tenancy model. Testing it means holding two tenants and trying.

Workflow and state abuse. Whether a checkout can reach a paid state without a payment event, whether an invitation can be accepted twice, whether a cancelled subscription still authorises an export. These depend on your state machine, and a tool with no model of that machine has little basis for calling any single transition wrong.

The methodology for finding these by hand is a separate exercise, covered in how to test business logic vulnerabilities.

When a scanner is the better use of the next unit of effort

There are situations where scanning wins that comparison, and a page that cannot name them is not much use.

If your estate is wide and shallow, scanning wins on coverage. Many services, hosts and repositories with no baseline across them is a breadth problem, and breadth is what scanning is for.

If nothing is currently automated, dependency and advisory monitoring can be a high-value place to start. A published advisory against a dependency you actually ship is a concrete issue with a known remediation path, and finding those by hand does not scale.

If most of your risk sits in components you did not write, the same holds. An application that is mainly integration work has a different risk profile from one carrying a large custom authorisation layer, and the instrument should follow the profile.

If there is nowhere a test can safely attempt a state change, that is worth sorting out before buying something that needs one. Testing by attempting the action needs somewhere to act.

Where Borg fits

Borg's Mjolnir tests the running application. It reads the repository to decide which paths are worth attacking, executes against the deployed system, reports findings with reproduction steps, and retests once a fix lands. Gungnir applies a narrower version of the same approach to a pull request diff, before the change reaches production. Huginn tracks the external attack surface as it changes. Findings from all three collect in Odin, the dashboard, and route into the tracker your engineers already use. There is a fuller description in what continuous pentesting means, and the routing is covered in how Borg pushes findings to Linear, Jira and GitHub.

The limits stated earlier apply to all of it. Code-aware testing is bounded by the context available to it, so configuration held outside the repository and the running application, and behaviour belonging to external services, may still need human or specialised testing. It does not remove the case for keeping a scanner running, and it does not stand in for a researcher reasoning about an unusual architecture.

Conclusion

The search behind this comparison usually assumes one of these is the modern version of the other. They are two instruments answering two questions, and a team running only one has a gap in the shape of the other.

Keep the scanner. It covers the classes that can be described once and checked everywhere, and it covers them cheaply. Add something that attempts the action when the risk that would hurt most sits in your own authorisation, tenancy or workflow logic, because that is the class a catalogue cannot describe. If you are unsure which of those two describes your application, a walkthrough against your own system tends to be the shortest route to the answer.

Frequently asked questions

Does autonomous pentesting replace a vulnerability scanner?: Not usefully. They answer different questions. A scanner asks whether a recognisably dangerous construct is present, which covers published dependency advisories, misconfigurations and injectable sinks, and it does that across a wide estate cheaply. Autonomous pentesting asks whether a prohibited action succeeds against the running application, which is where access control and workflow flaws live. Dropping the first to fund the second can leave a gap in coverage that the scanner was addressing.
Why can a clean scan sit alongside a real vulnerability?: Because a scanner works from a general catalogue of dangerous constructs, and your application's own rules are not in it. That only a billing role may change a plan, or that an order belongs to one organisation, is usually enforced by code rather than declared anywhere a tool can read. When such a rule is not enforced, there is often no dangerous construct present to match. Something that should have been present is absent.
What does a finding from autonomous pentesting look like?: A record of an attempt that succeeded, rather than a pattern that matched. In practice that tends to mean the request sequence used, the account or tenant it was made from, what came back, and enough detail for somebody to repeat it. The practical difference is what you do with it: a matched pattern still needs someone to work out whether it is reachable, while an attempt that worked has already answered that question for the specific path it took. It says nothing about the paths a given run did not reach. Where findings are retested after a fix, re-running the same attempt provides a direct way to establish whether that exploit path is still working.
What does autonomous pentesting not cover?: Its coverage is bounded by the context available to it. Configuration that exists only in a cloud console or a third-party dashboard, the behaviour of external services, and business rules that live only as undocumented assumptions can fall outside its view, and may need human or specialised testing. Access matters too: testing a tenant boundary means holding credentials for more than one tenant, and testing a billing transition means an environment where that transition can be attempted safely.
Which should a small team run first?: Start with whichever failure you would least like to find out about late. If your estate is wide and shallow, many services and repositories with no baseline across them, scanning covers that ground cheaply and little else does. If the risk that would hurt most sits in your own authorisation, tenancy or billing logic, that is the class a catalogue cannot describe, and something that attempts the action is the better first purchase. One precondition is easy to miss either way: testing by attempting an action needs an environment where that action can safely be attempted, so it is worth sorting that out before buying something that depends on it.