An external test is only as good as the asset list it was handed. So B-52 works the perimeter out itself — from the address ranges you announce, the names that still resolve to them, and what actually answers on each address — and puts that list in front of you before anything is tested. You authorise what is in scope. Nothing outside it is touched.
The run
On an application there is one target and the question is what it does. On a perimeter the target is the question.
Phase one
The address ranges you announce, the names that resolve into them, the certificates issued for those names, and the services that answer on each address. Four sources, reconciled against each other, because each one holds hosts the others do not.
Phase two
What discovery returned is put in front of you and the scope is agreed in writing against it, host by host. In the fully autonomous model that sign-off is the last human action of the engagement.
Phase three
Every host inside the authorised scope is worked for version, configuration and exposure. This phase produces candidates. Nothing leaves it as a finding, and nothing is reported from it.
Phase four
Each candidate is proved or dropped. On a perimeter that means reaching the thing itself — the console that accepts the session, the endpoint that returns the record — rather than matching a banner against a version table.
Phase five
Findings are written up and land in your dashboard as they are confirmed, each with the exchange that proved it, rather than arriving together at the end.
Phase six
The last phase runs on the finished report and can send it back to reporting. It is where a host that is only a banner gets separated from a host that is a way in.
Phase one, in detail
Four sources, and none of them is the spreadsheet. The address ranges an organisation announces are public routing data. The names that resolve into those ranges are public DNS. The certificates issued for those names are public log entries. And what answers on a given address is a question only asking can settle — a service can be live at an address that no name has ever pointed at, which is precisely the host that never reached anybody’s inventory. B-52 reconciles all four and hands you the result as a scope proposal, not as a finding. What goes into the scope is your decision, taken before anything on those hosts is touched.
Class and boundary
The perimeter is what somebody with no credential and no position inside your network can reach. What sits behind it is another class, and B-52 covers those too.
Every address in the authorised scope: the services listening on it, their versions and configuration, the remote-access and management interfaces reachable on them, transport security, and the pre-production systems that reached the public internet without anyone intending them to.
A web application served from a perimeter host is its own class, with its own roles and its own test set. The external assessment reports that it is published and identifies what it is; the application assessment works the flows inside it.
AdjacentWhat an attacker does after landing is the internal network class. The two are scoped apart because the questions are different: one asks how somebody gets in, the other asks how far they get once they are.
Out of scope for the platform entirely, in every class. It is the only exclusion, and it is stated the same way everywhere on this site.
Who this page is for
Both are answered here. The order they should read in is not the same.
The boundary
Everything else inside the authorised scope runs without checking in. The boundary is the same in all three delivery models.
| State | What it means | What follows |
|---|---|---|
| Destructive or state-changing actions in production | A perimeter host is a production host by definition. Anything that would alter or remove what is on one, rather than demonstrate that it could be altered, stops here. | Stops and waits, in writing. |
| Persistence and movement past the entry host | This is the gate that bites on an external engagement. Reaching a host is inside the scope you signed; using it to reach the next one is not, until you say so. | Stops and waits, in writing. |
| Live credentials or real customer data | An endpoint that returns real records is proved by the fact that it returned one, not by collecting what it would return next. | Stops and waits, in writing. |
| Everything else inside the authorised scope Terminal | Discovery, the scope proposal, scanning, exploitation, chaining and reporting. | Runs without asking. |
The entry host
On an application assessment the run stays on one target and the gates rarely come up. On a perimeter there is a specific moment where a proved finding becomes a foothold and the next step is a segment of your network that was never in the conversation. That step is gate two, and it is a written decision taken beforehand rather than a judgement made mid-run. Approving it covers the boundary for that engagement rather than one action at a time, and the audit trail records what was permitted, when, and by whom. Where the gate was never released, that is legible too — a reviewer can see what was refused as plainly as what was allowed.
What a run returns
Read from what B-52 returns on perimeter engagements rather than from a list of what a port scanner looks for. The first two rows are the ones an inventory cannot produce.
| Class | What it looks like on a real perimeter |
|---|---|
| Hosts that are on no inventory | A service answering at an address inside a range the organisation announces itself, which public DNS has never pointed a name at. It is live and it is reachable, and because it has no name it has never appeared on a list for anyone to test. |
| Names pointing at infrastructure somebody else can claim | A subdomain under your brand whose record still resolves to a cloud resource that was given up. Whoever registers that resource next serves whatever they like, under your name, to people who have every reason to trust it. |
| Pre-production systems on the public internet | Staging, test and development hosts published without anyone intending them to be, authenticating against the same identity provider as the system they mirror. |
| Management and monitoring interfaces | Dashboards, consoles, build systems and gateways reachable from the internet without authentication, or with a credential that was never changed from the one it shipped with. |
| Software past the end of its support life | An application server or appliance still serving a public host after its vendor stopped issuing fixes for it, together with the handler and component defects that are known-exploitable on the version that answers. |
| Secrets inside what the host already serves | Keys, client secrets and tokens sitting in the JavaScript, source maps and configuration files that a public host hands to anybody who asks for them. Nothing has to be breached to read these. |
| Remote access and identity endpoints | Virtual private network portals, virtual-desktop gateways and single sign-on endpoints. On a perimeter these are the front door rather than a side effect, and they are worked as the front door. |
| Transport and mail-domain configuration | A login flow served without transport security, cipher suites still accepted that should no longer be, and the DNS records that decide whether a stranger can send mail in your name. |
Hosts that are on no inventory
Names pointing at infrastructure somebody else can claim
Pre-production systems on the public internet
Management and monitoring interfaces
Software past the end of its support life
Secrets inside what the host already serves
Remote access and identity endpoints
Transport and mail-domain configuration
Three of them, worked
The same three exposures read twice: as the asset list has them, and as the run finds them.
Methodology
Each is cited at the version current on the date beside it. This is the one class where a guide written in 2008 is still the right citation, and the note says why rather than leaving you to wonder whether we checked.
| Standard | Version | What it carries here |
|---|---|---|
| NIST SP 800-115 | Final, September 2008. Read 2026-09-13 | The structure of a technical assessment — planning, discovery, attack, reporting — and the handling rules for what the attack phase turns up. |
| Still the current edition: it has been neither withdrawn nor superseded. Citing something newer-looking in its place would be the error, not the caution. | ||
| PTES | Current | The engagement structure — scoping, authorisation in writing, and the shape of the report. |
| OWASP WSTG | v4.2, the current stable release | Where a perimeter host serves a web application, the test procedures for it come from here. The application itself is scoped as its own class. |
| v5.0 is in development and is not cited here until it is stable. | ||
| CVSS | v4.0, November 2023. Read 2026-09-13 | The severity vector on every finding, so your team can recompute the score against its own environmental metrics instead of taking ours. |
| The version FIRST currently publishes and maintains. | ||
NIST SP 800-115
Still the current edition: it has been neither withdrawn nor superseded. Citing something newer-looking in its place would be the error, not the caution.
PTES
OWASP WSTG
v5.0 is in development and is not cited here until it is stable.
CVSS
The version FIRST currently publishes and maintains.
Before a run starts
Deliberately excluded
Per finding
The request as sent and the response as returned, with the part that proves the defect marked. On a perimeter finding that is the session the console handed back, or the record the endpoint returned to nobody in particular.
Which address, which name resolved to it if any, which service and which port — so your team can match it against their own records, or establish that they hold none for it.
Written so the team that owns the host can run them without coming back to us first. A finding nobody can reproduce is a ticket that stays open.
Severity with its CVSS v4.0 vector, the CWE, and the public identifier for the defect class where one applies.
In the model with no auditor in it, findings pass a second automated gate before they are reported. It is a check on top of the exploit, not a substitute for it.
Where this sits
No vendor is named here — these are categories of work. The useful question is which of them ends with something proved.
| External vulnerability scanner | Attack surface management | Scheduled external pentest | B-52 | |
|---|---|---|---|---|
| What it works from | A target list you supply, and a signature catalogue. | Continuous discovery of what resolves to you. | An asset list agreed at scoping, worked by hand. | Discovery it runs itself, proposed back to you as the scope. |
| Finds hosts nobody listed | No. It tests what it was given. | Yes. That is the job it exists to do. | Where the scope and the hours allow for it. | Yes, in phase one, before the test set is written. |
| Proves a finding by reaching it | No. It reports what a response pattern matched. | No. Discovery is not exploitation. | Yes. | Yes, and the exchange that proved it arrives with the finding. |
| What a finding costs you to confirm | Triage. A share of them are not real. | Nothing, because there is nothing yet to confirm. | Usually nothing; it was proved. | Nothing. It arrives proved. |
| Cadence | Continuous. | Continuous. | When it is scheduled and staffed. | The interval you set, or the pipeline that built the release. |
| Whose signature it carries | None. | None. | The firm that ran it. | Security Brigade’s, in the two models with an empanelled auditor in them. |
What it works from
Finds hosts nobody listed
Proves a finding by reaching it
What a finding costs you to confirm
Cadence
Whose signature it carries
On discovery
The row above saying that attack surface management does not exploit is not a criticism of it — it is the boundary between two products, and Security Brigade publishes one on each side. ShadowMap discovers: it watches what resolves to you, continuously, and tells you when the estate changes. B-52 tests what it finds. The direction runs one way and the subscriptions are separate, which is deliberate rather than commercial: a discovery product that also decided what to attack would be taking the scope decision that belongs to you.
Filing
The delivery model decides whether the output can be filed, not the coverage. All three work the same estate the same way.
| Obligation | What it asks for, and which model produces it |
|---|---|
| PCI DSS v4.0.1, requirement 11.4.3 | External penetration testing at least once every twelve months, and after any significant infrastructure or application upgrade or change. The second clause is a cadence requirement rather than an annual one, and a run triggered by the change itself is what satisfies it. |
| Requirement text read 2026-09-13. The v4.x requirements have been in force since 31 March 2025. | |
| SEBI CSCRF | Annexure L of the circular dated 20 August 2024 names infrastructure alongside applications, APIs, operating systems, databases and cloud in the scope of a VAPT. Where the filing names an empanelled auditor, take the expert-verified or the human-led model. |
| Read 2026-09-08. | |
| A periodic external or perimeter assessment | Any of the three delivery models covers the testing itself. What differs between them is whose signature the report carries. |
| Evidence of remediation | Each finding carries through open, fixed, retested and closed, and closes on a retest that cannot reproduce it. |
PCI DSS v4.0.1, requirement 11.4.3
Requirement text read 2026-09-13. The v4.x requirements have been in force since 31 March 2025.
SEBI CSCRF
Read 2026-09-08.
A periodic external or perimeter assessment
Evidence of remediation
On empanelment
Security Brigade holds the CERT-In empanelment, and under that framework it is the testing that has to be empanelled rather than only the firm invoicing for it. So an external engagement delivered in the expert-verified or the human-led model produces a report that can be filed under it, and one delivered fully autonomously does not. Nothing about which hosts were tested or how far the run went changes between the three.
Worked example
Each step read alone is a row a triage queue would push down the list. Read in sequence, they are how somebody gets in.
| Link | Alone | In sequence |
|---|---|---|
| 1 An address with no name | A host inside an announced range, answering on a port nobody expected. | On no inventory, so nothing had ever tested it. |
| 2 A console with no login | A monitoring dashboard reachable without authentication. | It is also a client that will make requests on the network’s behalf. |
| 3 A request made from inside | A server-side fetch to an address of the tester’s choosing. | The console reaches the internal services the perimeter exists to keep unreachable. |
| 4 A live token in the response | A credential returned in a response body. | It authenticates to the internal API, and the chain has crossed the perimeter. |
Measured
The benchmark was run the only way that settles the question. B-52 and Security Brigade’s expert assessment team worked the same targets in parallel, and both sets of findings were pooled into one denominator, each item counted once. B-52 reached 90–95% of that pooled set. Part of what it reached was absent from the team’s own output, which is why the pooled set is larger than either side produced alone.
One scan is one target, and the entry tier is $500. A perimeter is more than one target, so an external engagement is scoped against what discovery returns — which is a conversation, and a short one.