ScoutSuite

ScoutSuite is NCC Group's open-source, multi-cloud security-auditing tool: point it at an AWS account, an Azure subscription, a GCP project, an Alibaba Cloud account, or an Oracle Cloud Infrastructure tenancy, and it calls that provider's own read-only APIs to pull down the account's entire configuration — every S3 bucket's ACL, every IAM policy, every security group rule, every unencrypted volume — and renders the whole thing as one interactive HTML report you open in a browser, with no server, no database, and no ongoing agent involved. Its defining trait is right there in that sentence twice: it is read-only by construction, not just by the IAM policy you happen to attach to it, and its output is a document you hand someone rather than a dashboard you keep watching. That combination is why security consultants reach for it on day one of a cloud assessment — one command produces a browsable snapshot of an entire account's posture in minutes, safe to run directly against a live production environment because it structurally cannot change anything it looks at. By the end of this page you should know how its collect-then-report architecture works, why "read-only" is a design guarantee rather than a suggestion, how its findings library and custom rulesets work, the commands you'll actually run across each supported provider, the gotchas that catch first-time users, and exactly why it fits a one-off assessment better than a tool built for continuous monitoring.

What ScoutSuite is, and the problem it solves

☺ Like you're 10: It started as one company's internal AWS-only tool and grew into one free tool that speaks the language of five different cloud providers.

ScoutSuite is developed and maintained by NCC Group, a security consultancy whose day job is running assessments and penetration tests against other companies' infrastructure — an origin that shaped the tool directly. Its predecessor, a narrower AWS-only auditor named Scout2, existed for years before NCC Group rewrote it from the ground up in Python 3 as ScoutSuite, broadening scope from a single provider to a genuinely multi-cloud tool covering AWS, Azure, Google Cloud, Alibaba Cloud, and Oracle Cloud Infrastructure. The rewrite wasn't cosmetic: instead of shipping a differently-shaped tool per provider, ScoutSuite gives every one of those five providers the same command shape (scout aws, scout azure, scout gcp, and so on), the same collect-then-evaluate-then-render pipeline underneath, and the same HTML report format on the way out. A consultant who's learned the tool against one client's AWS account already knows how to point it at the next client's Azure subscription.

The problem it solves is speed and breadth at exactly the moment a security assessment usually starts: the first day, before anyone has decided which two or three services deserve a deep manual review. Clicking through a cloud console service by service — S3, IAM, EC2 security groups, RDS, CloudTrail, KMS, and dozens more — to manually assess configuration is slow, inconsistent between two different reviewers, and easy to leave gaps in simply because nobody thought to check a less-obvious service. ScoutSuite's read-only API calls cover on the order of fifty AWS services (and a comparably broad set for each of the other providers) in one run, and every one of those checks runs identically every time — the same coverage on an account with three resources as an account with three thousand. See cloud security posture for the broader discipline this tool serves, and IaC security & policy as code for the pre-deploy half of the picture ScoutSuite doesn't cover — it audits what's actually running, not what a Terraform plan says should run.

Architecture: collect once, evaluate once, render a report anyone can open

☺ Like you're 10: It looks at your cloud account once, writes down everything it saw in one big file, checks that file against a rulebook, and turns the result into a webpage — and the looking-and-writing step never touches anything, only reads.

ScoutSuite's pipeline has three stages, and knowing where each one starts and ends explains most of what the tool can and can't do. The first stage is collection: a per-provider Python module — built on each cloud's own official SDK, boto3 for AWS, the Azure SDK for Python, google-api-python-client and the Cloud SDK for GCP, comparable first-party SDKs for Alibaba Cloud and OCI — walks every supported service and calls its read-only List/Describe/Get-style APIs, assembling everything it finds into one large nested JSON structure representing the account's entire inventory and configuration as ScoutSuite understands it. That structure is written to disk as scoutsuite_results_<provider>-<account-id>.js — a JavaScript file that assigns the JSON to a variable rather than a plain .json file, a deliberate choice that lets the finished HTML report load its own data with an ordinary <script> tag and work correctly when opened straight from the filesystem (file://), without hitting the same-origin restrictions a browser would otherwise apply to a local XHR/fetch request for a JSON file.

The second stage is rule evaluation: the collected JSON is walked against ScoutSuite's built-in findings library — hundreds of rules per provider, each one checking a specific path into that JSON against a specific condition and, on a match, contributing a finding at a given severity. The third stage is rendering: findings and the underlying inventory are assembled into a self-contained HTML dashboard, written alongside its supporting assets in a report directory, ready to open in a browser or hand to someone else with no ScoutSuite installation, no cloud credentials, and no network access required to view it.

The detail worth internalizing is that these three stages are logically separable even though one scout invocation normally runs all of them back to back. Because the raw collected data is itself a persisted artifact — not just an intermediate value discarded after rendering — a report can be regenerated against a different or updated ruleset without recollecting anything, and the machine doing the rule-evaluation-and-rendering step never needs the cloud credentials the collection step used at all. That separation matters operationally: a consultant can run collection from a locked-down jump host holding the client's read-only credentials, then hand the resulting .js file to a laptop with no cloud access whatsoever to generate and review the report.

Read-only by design: the collection model

☺ Like you're 10: It's not that ScoutSuite promises to be gentle — it literally only knows how to ask "what is this set to," never "change this to something else."

"Read-only" describes two separate, reinforcing things about ScoutSuite, and it's worth being precise about both. The first is the IAM policy a team is expected to attach to the credentials ScoutSuite runs with: AWS's own managed SecurityAudit policy (arn:aws:iam::aws:policy/SecurityAudit) is the standard grant, sometimes supplemented with ViewOnlyAccess for services SecurityAudit doesn't cover completely; Azure's built-in Reader role and GCP's Viewer role play the equivalent part on their respective platforms. The second, and the one that actually matters for trusting the tool, is that ScoutSuite's own code never issues a mutating API call in the first place — every request it makes is a List, Describe, or Get-shaped call, full stop. Even if you attached broader, write-capable credentials to it by mistake, the tool has nothing in it that would use that extra privilege; there's no code path that ever calls PutBucketPolicy or CreateSecurityGroup. The IAM policy is defense in depth on top of a guarantee the tool's own design already provides, not the only thing standing between a misconfigured run and a changed resource — see workload identity & pipeline IAM for how that least-privilege discipline generalizes beyond auditing tools specifically.

That distinction is exactly what separates ScoutSuite from an offensive tool covered elsewhere in this course — an exploitation framework such as Rhino Security Labs' Pacu, discussed in offensive security for DevSecOps, is built specifically to use a compromised or over-privileged cloud credential to escalate privilege and pivot, which means running it carries real risk of changing something in the account it's pointed at. ScoutSuite carries no equivalent risk, which is precisely why it's safe to hand the exact same command to a client's own cloud administrator and ask them to run it themselves against production, or to point it directly at a freshly assumed cross-account role on day one of an engagement with no separate change-control review of what the tool itself might do — the worst realistic outcome is API throttling, not a changed resource.

Five providers, one command shape

The provider selection is the first word after scout; everything downstream — flags, output format, report structure — stays the same regardless of which one you pick. Authentication is the one place each provider's own conventions show through:

Exact flag names shift slightly release to release as provider coverage has grown — scout <provider> --help is the reliable source for whatever version is actually installed, the same discipline worth applying to any CLI tool whose documentation you can't be certain is current.

The findings library: rules, custom rulesets, and exceptions

☺ Like you're 10: Every check the tool knows is written down as a small file that says exactly where to look and what counts as a problem — and you can write your own, or tell it to ignore one you've already accepted.

Each finding ScoutSuite can report is defined declaratively as JSON, not hand-coded logic scattered through the collector — a shape that will look familiar from Checkov's YAML custom policies, applied here to a cloud account's live state instead of infrastructure-as-code source. A finding definition names the JSON path into the collected data it inspects, the condition that turns a matching resource into a finding, a severity (danger or warning), the service and dashboard category it's filed under, and — the part that makes the report useful for more than a to-do list — plain-English description, rationale, and remediation text, plus references to the compliance frameworks the check maps to, most commonly the CIS AWS/Azure/GCP Foundations Benchmarks. See compliance as code at scale for how a mapping like that turns a pile of findings into audit evidence rather than just a backlog.

{
  "description": "S3 bucket without default encryption enabled",
  "rationale": "Data at rest in an unencrypted bucket relies entirely on access control to stay protected; encryption is a second layer if that ever fails.",
  "remediation": "Enable default server-side encryption (SSE-S3 or SSE-KMS) on the bucket.",
  "compliance": ["CIS AWS Foundations Benchmark 2.1.1"],
  "path": "s3.buckets.id.encryption",
  "conditions": ["equal", "false"],
  "service": "s3",
  "level": "danger"
}

Treat that shape as illustrative rather than a field-for-field spec to copy — the real rule files ship inside the tool's own rules/findings/ directory per provider, and reading a handful of them directly is the fastest way to understand the current schema for whichever version you're running.

Custom rulesets and exceptions: the same accepted-risk problem every scanner on this shelf has

Not every finding deserves to stay red forever — a bucket with intentionally public read access serving a static site, a security group rule restricted further by a second rule the check can't see, exactly the same accepted-risk cases Checkov's suppression mechanisms exist to handle. ScoutSuite gives you two levers instead of editing the built-in rule files directly: a custom ruleset — a JSON file, passed with --ruleset, that turns specific findings on or off or overrides their default severity for every account it's run against — and an exceptions file, passed with --exceptions, that marks specific already-seen findings on specific resources as accepted, the same "this one resource, this one reason" scope Checkov's inline #checkov:skip comment covers for infrastructure-as-code. Keep both checked into version control next to whatever governs the account itself, for the same reason any suppression mechanism belongs in git: an exception with no reviewable history is indistinguishable from a scanner nobody's looking at.

Day-to-day commands

☺ Like you're 10: One flag picks the cloud, a handful more narrow down what to look at and where to put the report, and the same shape works no matter which provider you're pointed at.

# install
$ pip install scoutsuite

# AWS — uses a named profile from ~/.aws/credentials
$ scout aws --profile prod-readonly

# AWS — scope to specific regions and services, skip a slow or irrelevant one
$ scout aws --profile prod-readonly --regions us-east-1 us-west-2 --services s3,iam,ec2
$ scout aws --profile prod-readonly --skip cloudtrail

# Azure — reuse an existing `az login` session, no separate credentials to manage
$ scout azure --cli

# GCP — a service account key file
$ scout gcp --service-account --service-account-key-file ./key.json --project-id acme-prod

# name and place the report explicitly instead of accepting the timestamped default
$ scout aws --profile prod-readonly --report-dir ./reports --report-name acme-prod-2026-08

# skip auto-opening a browser, and overwrite a previous report of the same name
$ scout aws --profile prod-readonly --no-browser --force

# apply a team's custom ruleset and a file of accepted-risk exceptions
$ scout aws --profile prod-readonly --ruleset ./acme-ruleset.json --exceptions ./acme-exceptions.json

Every subcommand's exact flag set is one scout <provider> --help away — the most reliable source for the version actually installed, since flag names have shifted slightly across releases as provider coverage grew.

Reading the report

☺ Like you're 10: The finished webpage is organized like a filing cabinet — one drawer per cloud service, a red or yellow tab on anything that needs attention — and you can open the whole cabinet without needing the key that unlocked the account in the first place.

The rendered HTML opens to a dashboard summarizing every scanned service down the left side, each carrying a badge count of its danger and warning findings, so the shape of the account's risk is visible before reading a single detail page. Drilling into a service lists every resource of that type ScoutSuite found, with each failing check called out against the exact attribute and value that triggered it — not just "this bucket failed a check" but which setting, and what it's currently set to versus what the rule expected. Filtering by severity, by service, or by a specific finding ID narrows a large account down to whatever a reviewer is actually working through in one sitting. The whole thing — HTML, CSS, JS, and the raw results file — sits in one self-contained report directory that can be zipped and emailed or dropped into a client deliverables folder; nothing about viewing it later requires ScoutSuite itself, cloud credentials, or continued access to the account. Because the report bundles the full inventory ScoutSuite collected, not only the subset that failed a check, it doubles as a straightforward asset inventory in its own right — useful for the "what do we even have running" question that often opens an assessment, independent of any finding at all.

Gotchas and failure modes

☺ Like you're 10: Most surprises come from the same two places — the account was too big or too locked-down for the collector to see everything, or the report is older than you think it is.

• A missing read permission fails quietly, not loudly. If the credentials ScoutSuite runs with can't read a given service — a permissions boundary, an SCP, a policy narrower than SecurityAudit in practice — that service typically shows up in the report as unscanned or sparse rather than throwing a hard error partway through the run. A clean-looking service in the dashboard can mean "nothing wrong" or "couldn't be read at all," exactly the same trap Trivy's distroless-image gotcha teaches on the container side — verify the credential's effective permissions before trusting an empty section as good news.
• Large accounts take real time, and can hit rate limits. A full multi-region, every-service AWS account collection issues a large number of API calls; on a big or old account this can run long enough to bump into provider-side throttling. Scoping --regions and --services to what actually matters for a given engagement, rather than always running the unscoped default, keeps a run from becoming an hours-long job on a large enterprise account.
• Temporary credentials can expire mid-collection. An assumed-role session or an SSO token with a short lifetime can expire before a large collection finishes, silently truncating whatever hadn't been collected yet at the moment it expired. Use a session duration comfortably longer than the collection is expected to take, especially on a first run against an account of unknown size.
• It's a snapshot, not a monitor. Nothing about ScoutSuite continues to check the account after the report finishes rendering — a bucket made public five minutes after the report was generated simply isn't in it. That's a property of what the tool is for, covered directly in the comparison below, not a bug to work around.
• Ruleset coverage lags new provider features. The findings library is maintained on the open-source project's own release cadence; a newly launched cloud service or resource type can exist in an account well before a rule exists to check it, so "zero findings for this service" can also mean "no rule was ever written for it yet."

Where ScoutSuite sits against Prowler and native CSPM tooling

☺ Like you're 10: Every alternative trades ScoutSuite's one-cloud-tool breadth and hand-off-ready report for something built to run over and over, forever, inside a pipeline instead of at the start of an engagement.

The real comparison, as with most tool comparisons on this course's shelf, is rarely "which one is objectively better" — it's whether a one-time snapshot or an always-on watcher is what a given moment actually calls for.

None of this makes ScoutSuite obsolete once a team can afford something continuous — it makes it the tool you reach for before that decision gets made. A consultant walking into an unfamiliar account on day one of an engagement, or a team trying to decide whether a paid CNAPP platform is worth the line item, both want the same thing first: a fast, free, broad, honest snapshot of where things actually stand. ScoutSuite is built for exactly that moment, and its HTML report — a document, not a subscription — is the right shape for a deliverable that outlives the engagement that produced it. See Prowler for the tool built to keep asking the same questions every day after that snapshot is taken, and vulnerability management & triage for how a one-off report's findings get folded into an ongoing backlog once the assessment ends.