Vexta's Cloud Configuration Auditing for AWS, Azure and GCP

Vexta is VITI Security's agentless, AI-augmented vulnerability scanner and pentest platform, and its cloud configuration auditing checks AWS, Azure and GCP resources for the kind of misconfiguration that turns into a breach headline, not just a missing patch. Vexta enumerates cloud resources across all three providers, tests S3 bucket permissions directly, and adds every cloud resource it finds as a node in Vexta's attack graph.

What does Vexta check across AWS, Azure and GCP?

Cloud configuration auditing in Vexta covers resource enumeration across AWS, Azure and GCP, so a hunter is not stuck manually pulling resource lists from three different consoles or three different CLIs before an assessment can even start. S3 bucket permission testing is called out specifically, which lines up with how often a misconfigured bucket, one left readable or writable to more than it should be, ends up being the finding that actually matters in a cloud-focused engagement, ahead of anything more exotic.

Resource enumeration on its own is a starting point, not the finding. What Vexta does with that inventory, checking bucket permissions and folding every resource into the same attack graph as the rest of the scope, is what turns a list of AWS, Azure and GCP resources into something an engagement can actually act on, rather than a spreadsheet of names and regions a hunter still has to work through by hand.

Why put cloud resources on an attack graph instead of a flat list?

A flat list of cloud findings tells you what is wrong in isolation. An attack graph tells you what an issue connects to. A misconfigured bucket or an overly permissive role is not dangerous purely on its own; it becomes dangerous based on what it can reach or what can reach it. By adding every cloud resource Vexta finds as a node in the same attack graph used for hosts, credentials and the paths between them, a hunter working a cloud-heavy scope can see a path from an exposed resource toward something that actually matters, instead of a pile of disconnected line items that all read as equally urgent.

That framing also changes how you prioritize a write-up. A resource sitting on a graph with no path anywhere interesting is a real finding worth fixing, but it is a different conversation with a client than a resource sitting one hop from something sensitive. Seeing that difference on a graph, rather than inferring it from a spreadsheet, is what the attack graph adds.

How does cloud auditing connect to credentials found elsewhere in a scan?

Vexta's credential engine tests credentials pulled from sources like SAST, JavaScript analysis, GitHub dorking, and config leaks against the services Vexta discovers, feeding successful authentications back into the graph as authenticates_to edges. A leaked cloud access key sitting in a JS bundle or a public repo is exactly the kind of input that engine is built to catch, and cloud configuration auditing is what gives that key somewhere real to point at once it has been tested: the actual AWS, Azure or GCP resources it can reach, rather than just a flagged string in a file.

That is the practical value of running cloud auditing and credential testing in the same tool against the same scope. A key by itself is a maybe. A key that authenticates against a real cloud resource, sitting on the same graph as the rest of the environment, is a finding you can actually walk a client through.

Where does cloud auditing fit into a wider engagement?

Cloud resources rarely exist in isolation from the rest of an organization's exposed surface. A GCP bucket, an Azure resource, or an AWS role is frequently reachable from, or referenced by, the same web applications, source repositories and leaked configuration that the rest of a Vexta scan is already covering. Running cloud auditing as part of the same engagement rather than a separate, siloed cloud review means those connections show up on one graph instead of needing to be reconciled by hand across two different tools and two different reports afterward.

Key takeaways