Almost nothing that goes wrong in a cloud account is a service listening where it should not. It is a role holding a permission nobody audited, a secret that names resources it was never meant to name, or a key policy that says yes to something that should never have asked. B-52 works the identity layer first, and proves what a principal can reach by reaching it.
Worked example
Read alone, the first three are rows a posture report would file under low. The fourth is what they add up to.
| Link | Alone | In sequence |
|---|---|---|
| 1 A configuration file the application serves | A JSON file naming a project and a tenant. | It names resources that were never meant to be addressable by name. |
| 2 A client secret in a redirect | A parameter in a response header. | It authenticates as the application, to the identity service. |
| 3 The role that token can assume | A role with a name and a policy. | The policy grants more than the service holding it has ever needed. |
| 4 The keys that policy can use | A decrypt permission on a managed key. | Each key tested allowed it — including the one that encrypts the cluster’s own secrets. |
Measured
B-52 and Security Brigade’s expert assessment team were put on the same targets at the same time, and everything either of them found was pooled into one set with each item counted once. Against that pooled set B-52 reached 90–95%. Some of what it reached the team had not, which is the reason the pooled set is bigger than either side produced alone — and the reason the expert-verified model exists rather than being a compromise between the other two.
Class and boundary
AWS penetration testing, Azure penetration testing and the Google Cloud equivalent are one coverage class here, worked against whichever of them your estate actually runs on.
Identity and permission policy, key and secret policy, object storage, federated and pooled identity, managed and serverless services, the container platform’s configuration, and what the account is publishing to the internet.
What the workload itself does with a request is the web application or API class. A cloud assessment reports the configuration that lets a request arrive and the permissions it arrives holding.
AdjacentThe hosts, names and services reachable from the public internet are the external network class. Run together, the two answer the same question from both directions.
Physical, hardware and wireless testing are out of scope for the platform in every class. The provider’s own platform is not yours to authorise testing of, and is not assessed here.
Who this page is for
Both are answered here. What they should read first is not the same.
The run
The phase names are the platform’s. What each one means changes completely when the target is a set of permissions rather than a set of addresses.
Phase one
What the account actually contains: the principals, the roles and the policies between them, the resources those policies name, and which of it is published. Read from the account rather than from the architecture diagram, because the two diverge and only one of them is running.
Phase two
The discovered account is put in front of you, the scope is agreed in writing, and the benchmark and version the run is worked against are fixed. In the fully autonomous model that sign-off is the last human action of the engagement.
Phase three
Configuration and policy across the authorised scope, measured against the benchmark. This phase produces candidates. Nothing leaves it as a finding.
Phase four
A policy that says a principal may do something is a candidate. A principal that did it is a finding. This is the phase where the two are separated, inside the boundary you authorised.
Phase five
Findings land in your dashboard as they are confirmed, each with the call that was made, what answered, and which principal made it.
Phase six
The last phase runs on the finished report and can return it to reporting. It is where a permission that exists is separated from a permission that mattered.
Why phase four is the whole argument
Permission in a cloud account is the sum of several documents that were written at different times by different people, and the result is frequently not what any one of them intended. Reading them tells you what was meant. Making the call tells you what is true, and on a large account the two disagree in both directions: policies that look alarming and grant nothing usable, and policies that look routine and resolve into something that is not. Everything in the depth table below is worked the second way, which is also why a finding here arrives with the call that proved it rather than with a screenshot of a policy.
The boundary
Three actions need your written approval on every coverage class. On this one the distinction that matters is between establishing what a principal can do and doing it to something real.
| State | What it means | What follows |
|---|---|---|
| Destructive or state-changing actions | Anything that creates, alters or removes a resource, a policy or a record, rather than demonstrating that it could be. In an account that includes the audit trail itself. | Stops and waits, in writing. |
| Reading real data with a permission that was proved | Establishing that a role can decrypt or read is the finding. Decrypting a production record, or listing a customer’s objects, is the separate act. | Stops and waits, in writing. |
| Persistence and movement past the entry identity | Assuming a second role beyond the first, crossing into another account or subscription, or leaving anything behind that would outlast the engagement. | Stops and waits, in writing. |
| Everything else inside the authorised scope Terminal | Enumeration, policy resolution, benchmark measurement, proving reach against non-production resources, chaining and reporting. | Runs without asking. |
On the second row
A role that can decrypt with a master key is a finding whether or not anything was decrypted, and writing it up does not require holding anybody’s records. That is worth being explicit about, because the cloud is the class where the gap between demonstrating reach and exercising it is widest: one call proves the permission, and the next one puts real data somewhere it was not before. B-52 makes the first call and stops, and the report says which of the two happened for every finding in it.
What a run returns
Ordered by where they land rather than by where a checklist looks. The first two rows are the ones a port scan and a diagram both miss.
| Class | What it looks like in a real account |
|---|---|
| Identity and permission policy | Which principal can do what to which resource once every policy in the chain has resolved, and where a role holds more than the service using it has ever needed. This is where cloud findings concentrate, and none of it is visible from outside the account. |
| Key and secret policy | Who is permitted to decrypt with a managed key. A storage role holding decrypt on the key that protects everything else is a configuration question with a data answer. |
| Federated and pooled identity | How the identity service issues tokens, what it will accept, which clients it trusts, and what a client secret that once reached the internet still authenticates as today. |
| Object storage | What a bucket or container permits, to whom, and whether that answer differs from the account-level policy that was supposed to govern it. |
| Managed and serverless services | Gateways, functions and distributions that are reachable, enumerable, over-permissive in what they accept, or still pointing at an origin that no longer exists. |
| Container platform configuration | What the orchestration layer discloses about itself, which identities are mounted into which workloads, and what a workload can reach that nobody intended it to. |
| What the account publishes | The addresses, names and endpoints the provider is serving on your behalf, established from the account itself rather than from the diagram that describes it. |
Identity and permission policy
Key and secret policy
Federated and pooled identity
Object storage
Managed and serverless services
Container platform configuration
What the account publishes
Three of them, worked
Each of these appears on a posture report. What the report cannot say is which of them somebody could use.
Methodology
One of these is deliberately cited without a version number, and the row says why. A pinned number that is wrong for two providers out of three is worse than no number at all.
| Standard | Version | What it carries here |
|---|---|---|
| CIS Benchmarks | The current Foundations Benchmark for the provider in scope | The configuration baseline the account is measured against, fixed at scoping so that a rerun is comparable. |
| Not pinned to a number here on purpose: CIS publishes per provider on its own cadence. The report names the benchmark and the version it was worked against. | ||
| MITRE ATT&CK | v19.2, released 6 August 2026. Read 2026-09-13 | The technique vocabulary a chain is described in, using the cloud and identity-provider matrices rather than the endpoint one. |
| NIST SP 800-115 | Final, September 2008. Read 2026-09-13 | The structure of a technical assessment, and the handling rules for what the attack phase turns up. |
| Still the current edition: it has been neither withdrawn nor superseded. | ||
| CVSS | v4.0, November 2023. Read 2026-09-13 | The severity vector on every finding, so your team can recompute against its own environmental metrics instead of taking ours. |
CIS Benchmarks
Not pinned to a number here on purpose: CIS publishes per provider on its own cadence. The report names the benchmark and the version it was worked against.
MITRE ATT&CK
NIST SP 800-115
Still the current edition: it has been neither withdrawn nor superseded.
CVSS
Before a run starts
Deliberately excluded
Per finding
The request as made and the response as returned, with the part that proves the finding marked. In an account that is the API call, the principal it was made as, and the result.
Which identity the call was made as, and how something reachable comes to hold it. A permission finding without that path is a policy observation.
Where reach could be established but the next step waited for approval, the finding says so. Where something was blocked by a control that worked, the report records that too, because a control that held is worth knowing about.
Severity with its CVSS v4.0 vector, the CWE, the benchmark control it fails, and the ATT&CK technique it maps to.
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 proof, not a substitute for it.
Where this sits
No vendor is named here — these are categories of work. Two of them run continuously and neither of them makes a call.
| Posture management | The provider’s own security service | A scheduled cloud audit | B-52 | |
|---|---|---|---|---|
| What it works from | The account’s configuration, read continuously. | The provider’s own telemetry and its own rules. | A benchmark, worked through by an assessor. | The account, plus what the account publishes, plus the calls that settle the difference. |
| Sees over-permissive policy | Yes. This is what it is for. | Yes, within its own rule set. | Yes, by reading. | Yes, and then resolves whether anything reachable can use it. |
| Establishes that a permission is usable | No. It reads policy; it does not make calls. | No. | Sometimes, within the hours bought. | Yes. That is the phase-four distinction the whole page rests on. |
| Sees a secret outside the account | No. It is not in the account. | No. | Only if somebody thought to look. | Yes, because what the account publishes is read as part of the same engagement. |
| What a finding costs you to confirm | Triage, against a list that does not get shorter. | Triage. | Usually nothing; it was read and understood. | Nothing. The call that proved it arrives with it. |
| 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
Sees over-permissive policy
Establishes that a permission is usable
Sees a secret outside the account
What a finding costs you to confirm
Whose signature it carries
On the posture tool
Continuous configuration monitoring is the right instrument for knowing that something changed and for holding a baseline steady, and an account without one is worse off. What it cannot do is decide which of its own rows anybody could use, because that requires making a call as a principal rather than reading a document about one. That is the work that leaves a standing list nobody finishes — and it is the work this class exists to do against the rows that turn out to matter.
Filing
Coverage is identical across the three delivery models. What differs is whose signature the report carries, and that is what decides where it can be filed.
Annexure L of the circular dated 20 August 2024 names cloud alongside infrastructure, applications, APIs, operating systems and databases. Read 2026-09-08.
Where an obligation asks what the configuration was measured against, the answer is a benchmark and a version fixed at scoping — which also makes the next run comparable to this one.
Each finding carries through open, fixed, retested and closed, and closes on a retest that cannot reproduce it.
Where the report goes to a regulator or an assessor, start with the expert-verified model.
On the division of labour
That division is why a cloud assessment reports against your account rather than against the provider, and why the provider’s own certifications answer a different question from the one an auditor is asking you. What they attest to is the platform. What you are being asked about is what you configured on top of it — the policies, the keys, the identities and what they reach — and that is exactly the half this class works. It is also the half that changes every week, which is the argument for a cadence rather than an annual exercise.
One scan is one application or target, and the entry tier is $500. A cloud account is usually rather more than one, so an engagement is scoped against what discovery finds inside it.