CloudSploit by Aqua: a self-hosted CSPM scanner for AWS, Azure, GCP and OCI

What CloudSploit actually checks, and who ends up running it

CloudSploit is a command line scanner that reads your cloud account configuration and reports misconfigurations. The README describes it as "an open-source project designed to allow detection of security risks in cloud infrastructure accounts", covering Amazon Web Services, Microsoft Azure, Google Cloud Platform, Oracle Cloud Infrastructure and GitHub. It is not an agent and it does not sit in the data path of your workloads. It authenticates with read-only credentials and asks the provider APIs what your account looks like right now.

The audience is narrow but real. A platform or security engineer who has been told to produce evidence for PCI or CIS without uploading credentials to a third party vendor is the natural user. So is a team that already runs everything else in a container and wants one more job in that pipeline. The README's own deployment section splits the world in two: self-hosted, which is what the open source repository gives you, and a hosted commercial version at Aqua Wave. That split tells you who the project expects to serve. If you want a console with history and someone else paging when a scan fails, the open source path is not aimed at you.

How the scanner is put together: collectors, plugins, postprocessing

The repository layout makes the architecture legible. There is index.js at the root, which is the CLI entry point and is also exposed as a binary named cloudsploit-scan in package.json. engine.js drives a scan. Around those sit three directories that do the real work: collectors/, plugins/ and postprocess/.

The flow is a pipeline. A collector talks to a cloud provider API and pulls back raw resource data. Plugins receive that data and apply individual checks, each one producing a pass, fail or unknown result. Postprocess then shapes the result set, which is where compliance mappings and output formatting live. The README documents a --collection=file.json option that saves the raw cloud provider response data, which is the clearest evidence that collection and evaluation are separate stages: you can capture the raw responses once and reason about them separately from the checks.

That separation matters for cost. The expensive part of a scan is the API calls, and the plugin layer is pure logic over data already in memory. It also explains why the plugin directory is where contributors are pointed. The README has a dedicated "Writing a Plugin" section, so adding a check is a supported path rather than a fork-and-pray exercise. The dependency list in package.json shows how wide the provider surface is: @aws-sdk/client-ec2 and aws-sdk for AWS, several @azure packages plus ms-rest-azure for Azure, google-auth-library for GCP, @alicloud/pop-core and ali-oss for Alibaba, and @octokit packages for GitHub. That is a lot of SDK surface to keep current, and it is the main reason the tool needs periodic upgrades rather than a one-time install.

Installing CloudSploit and running a first PCI scan

The README's generic quick start assumes Node.js is already present. Clone the repository, install dependencies, and ask the CLI for help to confirm the entry point works.

$ git clone https://github.com/aquasecurity/cloudsploit.git
$ cd cloudsploit
$ npm install
$ ./index.js -h

That last command prints the usage banner and the option list. If it prints nothing, the install is broken and nothing further will work.

Configuration comes next. Copy the example config and edit it for the provider you are scanning.

$ cp config_example.js config.js

The config file accepts credentials three ways: a JSON file on disk, environment variables, or hard-coded values. The README marks hard-coding as not recommended, which is the correct call. For AWS, the README notes that you can run CloudSploit directly and it will detect credentials through the default AWS credential chain, so no config edit is needed if your environment already has AWS credentials set. For other providers you uncomment the relevant block. Azure, for example, exposes a credential_file option and inline options such as application_id, key_value, directory_id and subscription_id, each reading from an environment variable of the same shape.

Environment variables only work after you uncomment the matching section of config.js. That is a common first stumble: setting AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY does nothing until the AWS block in config.js is active. The Docker path skips the config file entirely.

$ docker build . -t cloudsploit:0.0.1
$ docker run cloudsploit:0.0.1 -h
$ docker run -e AWS_ACCESS_KEY_ID=XX -e AWS_SECRET_ACCESS_KEY=YY cloudsploit:0.0.1 --compliance=pci

The Dockerfile builds on node:lts-alpine3.12, installs the package, creates a non-root cloudsploit user and switches to it before the entrypoint. A plain scan with no arguments runs the full check set:

$ ./index.js

For a compliance run, pass the benchmark. The README documents HIPAA, PCI and CIS Benchmarks as supported compliance targets, and the Docker example uses --compliance=pci.

Wiring scans into CI with --exit-code and --ignore-ok

The CLI options are where CloudSploit stops being a report generator and becomes a gate. Two flags do most of that work. --ignore-ok drops passing results so the output is only findings. --exit-code makes the process exit non-zero when non-passing results exist, and the README describes this as a good option for CI/CD systems.

$ ./index.js --ignore-ok --exit-code --console=text

--console=text switches the default table output to raw text, which is easier to read in a build log than a rendered table. Other documented options include --govcloud and --china for AWS partitions, and --collection=file.json to persist the raw provider responses.

Be deliberate about combining --exit-code with a broad compliance profile. A PCI run against an account that has never been scanned will almost certainly produce failures, and a non-zero exit will fail the build on the first run. Teams usually start with --ignore-ok alone to see the finding set, then add --exit-code once the baseline is clean or once suppressions cover the accepted exceptions. The README documents a Suppressions feature for exactly that purpose, and the output formats section covers CSV, JSON and JUnit XML alongside the console output. JUnit XML is the format most CI systems already know how to render as a test report.

Where CloudSploit is the wrong tool

CloudSploit is a point-in-time scanner, not a monitor. Nothing in the README describes continuous evaluation, event-driven detection or alerting on change. You get a result set for the moment the scan ran. If your requirement is to know within minutes that a bucket was made public, this tool does not do that on its own; you would have to schedule it and build the alerting yourself.

The second limitation is operational. This is a Node.js application with a broad dependency tree, and the SDK packages it depends on move. Upgrading the tool means upgrading AWS, Azure, Google, Alibaba and Octokit client libraries together, and any one of them can change behaviour under you. There is no documented upgrade procedure or migration guide in the README. A team without someone willing to own a Node.js dependency tree will find this heavier than it looks.

The third is scope. The README lists AWS, Azure, GCP, OCI and GitHub. It does not claim Kubernetes workload scanning, container image scanning or runtime protection. If your problem is what is running inside your clusters rather than how the accounts are configured, this is the wrong layer entirely.

Finally, credential handling deserves a hard look. The config file supports hard-coded credentials, and the README says not to. It also supports a credential_file path. Either way, the scanner needs read access across your cloud account, and that file becomes a high-value target. The Docker approach of passing credentials as environment variables at run time is the cleaner pattern, but it still means the credentials exist in the process environment.

CloudSploit compared with Prowler and ScoutSuite

The two names that come up alongside CloudSploit are Prowler and ScoutSuite, and the difference is mostly one of implementation language and packaging rather than of intent. All three read cloud account configuration with read-only credentials and report misconfigurations against a set of checks and benchmarks.

CloudSploit is JavaScript and installs through npm. Its checks live in plugins/ and are written against the JavaScript SDKs. Prowler is a Python tool, which means it installs into a Python environment and its checks are Python. ScoutSuite is also Python, and it is built around producing an HTML report of collected configuration data rather than primarily around a pass/fail check list. That distinction is practical. If your team writes Python and already has a Python toolchain in CI, adding a JavaScript runtime for one scanner is friction you can avoid. If your CI is already Node-based, or you want to extend checks in the same language as the rest of your tooling, CloudSploit's plugin model is the easier extension point.

The compliance angle is a second axis. CloudSploit documents HIPAA, PCI and CIS Benchmarks, and the --compliance flag selects one. If your auditor has asked for a specific benchmark that CloudSploit does not map, the plugin layer is where you would add it, and that is real work. Compare the actual benchmark coverage before choosing, not the feature list.

Licence, maintenance and what upgrading costs you

CloudSploit is licensed GPL-3.0-or-later. That is a copyleft licence, and it is worth understanding before you embed the scanner in something you distribute. Running it as a separate process in your own CI, which is the documented usage, is a different situation from linking its code into a product you ship. If you plan to redistribute a modified version, or to build a commercial offering on top of the plugins, read the licence text and talk to someone qualified. Nothing here is legal advice.

The repository is not archived, and the last push was on 2026-09-22, so the codebase is being touched. The release history is less even: v3.10.0 landed on 2024-11-15, v3.9.0 on 2024-09-24, and v3.5.0 on 2024-06-05. Those dates cluster in 2024, and the gap between the newest tagged release and the latest commit is substantial. That pattern is consistent with active work on master that is not being cut into tagged releases, which matters if you pin versions. If you install from a tag, you are running code that is older than the default branch. If you install from master, you are running untagged code.

Upgrade cost follows from the dependency list. The AWS SDK v3 client, the legacy aws-sdk v2 package, the Azure storage and data-tables packages, google-auth-library and the Octokit clients all need to move together. There is no documented upgrade path in the README, so plan to test a version bump against a known account before rolling it into a pipeline that gates merges.

Editorial conclusion

Adopt CloudSploit if you need posture checks to run inside your own network against AWS, Azure, GCP, OCI or GitHub, and you are comfortable operating a Node.js tool yourself. Do not adopt it if you want a hosted console with history, dashboards and no maintenance burden: the README points that audience at Aqua Wave instead. Before committing, copy config_example.js to config.js, provision read-only credentials for the providers you actually use, and confirm that ./index.js -h lists the CLI options your workflow depends on. Then check the plugin coverage for your provider, since the checks are the product.

Frequently asked questions

Official sources

1. aquasecurity/cloudsploit on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases