Compare

Simulation, penetration test, vulnerability scan

Three things that get quoted against each other and answer different questions. Buying the wrong one is common, and expensive, because the report arrives and tells you something you already knew.

The short version

A scan finds known flaws. A penetration test finds out whether somebody skilled can get in. A simulation works out which of your gaps sit on a path to something you cannot lose.

Vulnerability scan

Answers: what known flaws exist on these systems?

Automated, cheap, and run continuously. It compares what you are running against a database of known issues and returns a list, usually a long one, ranked by a severity score that knows nothing about your business.

Its strength is coverage. It will find the unpatched thing on the server everyone forgot. Its limit is context: a critical on a machine nobody can reach outranks a medium on the one holding your customer records, because the scanner cannot see which is which.

Penetration test

Answers: can a skilled person actually get in, right now?

People, with permission, trying. They chain small things together, find what no scanner reports, and produce evidence that something is genuinely exploitable rather than theoretically vulnerable.

Its strength is proof. Nothing else produces it. Its limit is time and scope: a few weeks against an agreed boundary, at one moment, which is not the same as what your defences would stop next month.

Breach and attack simulation

Answers: if this attack ran, how far would it get?

A model of your estate, your controls and the things you cannot lose, with known attack paths run against it. Continuous, free to re-run, and it changes the moment you change a control.

Its strength is decision. It turns a list into an order of work. Its limit is that it is a model: it reasons from what you record and what your exports confirm, and it does not prove exploitability, because nothing is attacked.

What BreachForge actually does

You describe the estate once. The engine holds the attack paths, the control library and the scoring, and it runs server side, so nothing is installed and no system of yours is touched.

22

Attack paths

Real routes, from help desk social engineering and OAuth consent phishing to ransomware that destroys the backups. Each runs against your estate and stops where a control holds.

112

Controls, across eleven pillars

Identity, endpoint, network, cloud, application, data, infrastructure, security operations, resilience, third party and the human layer. Each recorded at a maturity level, not a tick.

1

Picture a board understands

Which paths reach your crown jewels, which controls would close them, and what the gap costs to shut. Not a severity score.

0

Systems touched

No agents, no scanning, no credentials handed over. Upload your configuration exports if you want the picture to rest on evidence rather than answers, and they are read in your browser.

Built to be run by a vCISO

Most organisations of fifty to five hundred people do not have a CISO, and many are served by someone who does the job across several clients. The platform is built for that, rather than adapted to it.

How the three fit together

They are stages, not alternatives, and each one makes the next worth paying for.

01

The scanner finds it. Continuous, cheap, and it produces a list far longer than anyone can work through. That is not a criticism: coverage is its job.

02

The simulation orders it. Which of those findings sit on a path to the payroll system, the customer records, the domain controller. The list becomes a fortnight of work rather than a year of it.

03

The test proves it. Now the fortnight of testing you are paying for is aimed at the paths that reach something, rather than at a scope drawn around whatever the budget covered.

04

The model updates. The fix lands, you change the control, and the paths change. That is the step a report cannot do, and it is why the picture is worth keeping after the engagement ends.

Side by side

Vulnerability scanPenetration testSimulation
The questionWhat is unpatched or misconfiguredCan somebody get inWhat does an attack reach
Touches your systemsYes, it probes themYes, activelyNo
How oftenContinuouslyOnce or twice a yearWhenever you change something
Typical costLow, often bundledThousands per engagementAn annual subscription
Proves exploitabilityNoYesNo
Shows business impactNoFor what was in scopeYes, by design
Tells you what to do firstBy severity score onlyFor what was testedBy what it reaches

What a model can and cannot tell you

It cannot prove exploitability. Nothing is attacked, so nothing is proven. Where a customer, an insurer or a certification scheme asks for evidence that a specific weakness can be used, that is a penetration test and we will say so rather than talk around it.

It can tell you what would be reached, and that is the harder question. A test tells you somebody got in through a particular door in a particular fortnight. A model tells you every door on a path to the things you cannot lose, and keeps telling you as the estate changes.

It reasons from what you record. That is why the evidence upload exists: your configuration exports are read in the browser and compared against what you ticked, and the disagreement is reported rather than quietly corrected. A model that agrees with you about everything is worth nothing.

See it against your own estate

Model it in an afternoon and watch twenty two attack paths run against what you actually have. No agents, no access, nothing installed.

Book a demo Why modelling, at length
BreachForge is a product of Cyber Spartans Ltd. This page describes categories of security testing in general terms. Where a scheme, contract or regulator names a specific form of assessment, that requirement takes precedence over anything described here.