ToolkitCloud Security

Practical documentation · Authorized use only

CloudSploit

CloudSploit evaluates cloud configurations against security checks. Use it with read-only least-privilege credentials in a dedicated audit account, start with one cloud scope, validate results against native configuration, and route remediations through change control.

CSPMAWSAzureGCPAuditing

Start safely and get useful results

Best for

  • • Cloud configuration review
  • • CSPM baseline and remediation triage

Not for

  • • Using broad owner credentials
  • • Auto-remediation without review

Before you run anything

  • • Document the authorized target, time window, success criteria, data-handling rules, and a named stop contact before you begin.
  • • Confirm the installed version with the tool’s version or help command, then compare its documented behavior with the linked upstream project before relying on any option.

Practical workflows

Beginner

Prepare a least-privilege audit scope

Scenario: A sandbox AWS account is assessed with read-only access.

cloudsploit --help

Verify the installed CLI and current provider options before configuring credentials or scope.

Expected use: The audit role should be read-only, scoped to the sandbox account, and monitored.

Intermediate

Run a controlled provider scan

Scenario: Review one sandbox account and export results for owner validation.

cloudsploit --config ./cloudsploit.config.js

Use a version-controlled, secret-free configuration that selects only the approved provider/account and output settings.

Expected use: Validate high-priority findings with native cloud console/API evidence before making changes.

Interpret results like an analyst

  • • Policy checks can produce false positives when compensating controls or organization policies apply.
  • • A clean scan reflects the enabled checks and credentials, not universal cloud security assurance.

Common mistakes and operating tips

Avoid

  • • Embedding long-lived cloud secrets in configuration files or shell history.
  • • Applying bulk remediation directly from scanner output without owner validation and rollback.

Operational discipline

  • • Treat command output as evidence, not a conclusion: retain the command, version, scope, timestamp, and a redacted result in the engagement record.
  • • Start with the smallest safe scope, validate expected behavior in a lab or pilot, then expand only when the authorization and monitoring plan support it.

Verify against the current upstream

Tool behavior and release syntax can change. Treat this guide as practical operating context, then verify version-specific details against the upstream project before an assessment.

Open authoritative upstream documentation