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:
| Dimension | Examples of what's flagged |
|---|---|
| Identity | Long-lived access keys; users with wildcard policies; roles with *:*. |
| Network | Security groups open to 0.0.0.0/0 on sensitive ports; public subnets carrying private workloads. |
| Data | Unencrypted S3 buckets; RDS instances with public endpoints; missing backups. |
| Compliance | Resources 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:
| Severity | Meaning |
|---|---|
critical | Active risk; you should fix this today. |
high | Likely to cause incident or compliance failure; fix soon. |
medium | Hardening — fix in the next sprint. |
low | Best-practice nudge. |
info | Informational; no action required. |
Reading audit output
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
- Use
cbx audit aws— practical recipe. - Run
cbx auditin GitHub Actions — CI integration. - ChangeSets — the reviewable artifact produced when you propose a remediation.