CloudBoosterDocs
Concepts

Audits

Continuous security and compliance checks across your connected AWS accounts.

Audits

An audit is a security and compliance scan of your infrastructure. CloudBooster audits run on demand from the CLI (cbx audit aws), continuously in the background from the portal, and as part of your CI pipeline.

The output is a list of findings, each with a severity, a description, an affected resource, and (where possible) a proposed fix that can become a ChangeSet.

What cbx audit aws reads

cbx audit aws reads your live AWS account directly through the SDK and grounds every finding in CloudBooster's curated AWS knowledge. It answers "what does my running cloud actually look like right now, and where does it deviate from best practice?"

The audit fetches CloudBooster's AWS knowledge and rule pack over the public knowledge API, inlines it alongside the discovered resources, and runs a local LLM CLI (claude by default, or codex via --llm-executor codex) to cite that knowledge in its findings. The grounding is what makes the findings trustworthy — it isn't optional.

Auditing Terraform / Pulumi state files or on-disk IaC is available only as a Go library path (pkg/audit) for downstream consumers, not as a cbx audit CLI mode. To bring existing infrastructure under management from a state file, use the portal's import flow.

What an audit checks

Audits cover four dimensions:

DimensionExamples of what's flagged
IdentityLong-lived access keys; users with wildcard policies; roles with *:*.
NetworkSecurity groups open to 0.0.0.0/0 on sensitive ports; public subnets carrying private workloads.
DataUnencrypted S3 buckets; RDS instances with public endpoints; missing backups.
ComplianceResources missing required tags; deviations from CIS / SOC 2 baselines.

The exact rule set is defined by CloudBooster's rule pack, fetched over the knowledge API and updated continuously. Pin a specific version with --rulepack-version (see the cbx audit aws recipe).

Severity

Findings are ranked:

SeverityMeaning
criticalActive risk; you should fix this today.
highLikely to cause incident or compliance failure; fix soon.
mediumHardening — fix in the next sprint.
lowBest-practice nudge.
infoInformational; no action required.

Reading audit output

$ cbx audit aws --region eu-west-1

Auditing 1 connected account: 123456789012 (eu-west-1)

[CRITICAL] iam-root-access-key
  IAM root account has an active access key.
  Resource: arn:aws:iam::123456789012:root
  Fix: rotate and remove root access keys; use IAM users or SSO.

[HIGH] sg-ssh-open-to-world
  Security group sg-0a1b2c3d4 allows SSH (22/tcp) from 0.0.0.0/0.
  Resource: arn:aws:ec2:eu-west-1:123456789012:security-group/sg-0a1b2c3d4
  Fix: restrict to your office IP range or use SSM Session Manager.

[HIGH] s3-bucket-public-acl
  Bucket "legacy-uploads" has a public-read ACL.
  Resource: arn:aws:s3:::legacy-uploads
  Fix: set Block Public Access; review object ACLs.

3 findings (1 critical, 2 high).

Each finding has:

  • A rule ID (iam-root-access-key) — stable, suitable for referencing.
  • A resource — the exact ARN.
  • A fix — human-readable description of the recommended remediation.

Remediating findings

To remediate a finding, use Propose ChangeSet in the portal (Manage security findings), or address it manually and re-run cbx audit aws to confirm the finding is gone.

Running audits in CI

Wire cbx audit aws into your CI to catch regressions before they merge. See Run cbx audit in GitHub Actions for the full setup.

A typical CI gate fails the build if any new critical or high finding is introduced compared to the previous main-branch baseline.

Suppressing findings

Findings can be suppressed in the portal. Navigate to the finding and mark it as suppressed with a reason. Suppressed findings are tracked and reviewed periodically.

See also

On this page