Both are products of Security Brigade, and they answer two different questions. The flow between them runs in one direction, the subscriptions are separate, and B-52 works for a customer who has never bought ShadowMap.
Two jobs
Knowing that something is exposed and knowing what happens when it is attacked are two separate findings, and a product that does one well is not halfway to doing the other. Security Brigade sells one product on each side of that line.
| The question | ShadowMap | B-52 |
|---|---|---|
| What does it answer? | What resolves to your organisation today, and what changed since the last time you looked. | What happens when one of those things is attacked by somebody who is trying. |
| What comes out of it? | An inventory of what is exposed, and a record of how that set has changed. | A finding with the request, the response and the steps that reproduce it, a CVSS v4.0 vector and the CWE. |
| What starts it? | It watches continuously and tells you when the estate changes. | A scope you signed off, on the interval you set or on the pipeline that built the release. |
| Who decides what gets attacked? | Not this product. It reports what exists; nothing in it becomes a B-52 target on its own. | You do, in writing, before a run begins. |
| How is it bought? | Its own subscription. | Its own subscription. One scan is one application or target, from $500. |
What does it answer?
What comes out of it?
What starts it?
Who decides what gets attacked?
How is it bought?
One direction
Where a customer runs both, the handover is not a pipe. It is a person taking something ShadowMap surfaced and putting it into a scope B-52 is authorised to test.
No dependency
Nothing in B-52 requires a ShadowMap subscription. The application classes — web application, mobile app, API, thick client and secure code review — start from a target you name, and the card flow reaches them without a sales conversation.
The class where a buyer might assume otherwise is external network testing, and that class runs its own discovery. The perimeter is worked out from what actually answers rather than from the asset list you hand over, and what comes back to you first is a scope proposal — before anything is tested. The external network page sets out how that proposal is built and what you are agreeing to when you sign it.
A customer who has never heard of ShadowMap gets the same eleven coverage classes in the same three delivery models. There is no part of B-52 that is reachable only alongside ShadowMap.
The commercial shape
B-52 is an adjacent product rather than a ShadowMap module, and it sits outside a ShadowMap licence. The separation is deliberate: the scope decision belongs to you, and a testing product that inherited its targets from an inventory would be testing whatever appeared overnight.
Where a customer does run both, it is still B-52’s own schedule that decides when testing happens — the interval you set, or the pipeline that built the release. Continuous assessment covers the cadence, and the build gate covers the case where a result has to stop a release.
Approvals and audit trail records who approved what and when, and the autonomy boundary sets out where the platform stops on its own.
B-52 is bought on its own card flow for web application, mobile app, API, thick client and secure code review. External network, internal network, cloud, Active Directory, social engineering and LLM applications settle on a scoping call, and so does ShadowMap.