> ## Documentation Index
> Fetch the complete documentation index at: https://docs.breachlens.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Scan cloud posture

> Connect an AWS, Azure, or GCP account read-only and map each misconfiguration to the compliance frameworks it affects.

Cloud posture (CSPM) checks how your cloud accounts are *configured* — public buckets, over-permissive roles, unencrypted volumes, missing logging, and hundreds of other checks — and maps each finding to the compliance frameworks that care about it. It's **read-only**: BreachLens reads your cloud's configuration, never changes it.

## Connect an account

Open **Cloud Accounts → Add account** and pick your provider. You supply **read-only** credentials; BreachLens encrypts them at rest (AES-256-GCM) and never returns them.

<Tabs>
  <Tab title="AWS">
    Provide an IAM **access key + secret** for a read-only user (optionally a session token for temporary `ASIA…` credentials):

    * `AWS Account ID` (12 digits) · `Region` (optional) · `Access key ID` · `Secret access key` · `Session token` (optional)

    **Least-privilege grant:** attach the two AWS-managed policies **`SecurityAudit`** and **`ViewOnlyAccess`** to that IAM user. Together they permit configuration reads across services without any write or data-plane access.
  </Tab>

  <Tab title="Azure">
    Provide a **service principal** scoped to one subscription:

    * `Tenant ID` · `Subscription ID` · `Client ID` (application id) · `Client secret`

    **Least-privilege grant:** assign the SP the **`Reader`** role on the subscription and **`Security Reader`** at the tenant. Both are read-only built-in roles.
  </Tab>

  <Tab title="GCP">
    Provide a **service-account key** (the full JSON) for a read-only service account:

    * `Project ID` · `Service account key` (paste the JSON)

    **Least-privilege grant:** give the service account **`roles/viewer`** and **`roles/iam.securityReviewer`** on the project.
  </Tab>
</Tabs>

### Credential rotation and edits

Credentials are supplied as keys today — an IAM access key, an Azure client secret, or a GCP service-account key. Rotate the key on your side and re-paste it any time from the account's **Settings**. The account's identity fields — subscription, tenant, client, account, and project IDs — are editable there too, so a mistyped ID can be corrected in place without removing and re-adding the account.

<Note>
  Keyless onboarding — AWS role assumption, GCP Workload Identity Federation, Azure managed identity — is on the roadmap. [Tell us](mailto:sales@breachlens.app?subject=BreachLens%20keyless%20cloud%20onboarding) if it's a procurement gate.
</Note>

<Tip>
  Use **Test connection** in the Add-account modal before saving — it validates the credentials against the provider so you catch a typo'd key or a missing role before the first scan.
</Tip>

## Run a posture scan

<Steps>
  <Step title="Open the account">
    Go to **Cloud Accounts** and click the connected account.
  </Step>

  <Step title="Run the scan">
    Click **Run scan**. A posture scan is a single read-only pass over the account's configuration — no agents, nothing deployed into your cloud.
  </Step>

  <Step title="Read the results by framework">
    Each finding is mapped to the compliance frameworks it affects, so you can filter to "what fails CIS" or "what fails SOC 2" rather than one flat list. Every finding also carries a **risk score** for triage, so you can rank findings within a framework instead of eyeballing severity alone.
  </Step>
</Steps>

<Note>
  **Kubernetes clusters are a separate target.** Cluster posture (CIS Kubernetes Benchmark) connects a Kubernetes cluster with its own read-only kubeconfig, not a cloud account — add it under **Kubernetes** rather than here.
</Note>

## Your posture score

Every scanned account gets a single **posture score from 0 to 100** — the share of evaluated configuration checks that pass, weighted by severity so a failed *critical* check pulls the number down far more than a failed *low*. It's the one number you can put in front of leadership: "this account is at 72, up from 61 last month."

<CardGroup cols={2}>
  <Card title="Only real signal counts" icon="filter">
    Checks that can't be assessed automatically (manual controls) and ones you've muted don't move the score. An account with nothing yet evaluable shows **no score** rather than a misleading 100.
  </Card>

  <Card title="Where you see it" icon="location-dot">
    On the account's detail header, in the **Cloud Accounts** list so you can rank accounts worst-first, and on the cover of the exported Cloud Posture report.
  </Card>

  <Card title="It moves with your cloud" icon="arrow-trend-up">
    Remediate a critical finding and it climbs; a bucket goes public and it dips. The score reflects the state at the moment of the scan.
  </Card>
</CardGroup>

<Note>
  The posture score measures configuration at the time of the scan — it's a snapshot, not a live gauge. Run posture on a schedule (below) so the trend is what you act on, not a one-off number.
</Note>

## Remediate a finding

Every finding carries a **Fix** action. Open it and BreachLens generates a ready-to-apply remediation for that exact check, pre-filled with what it already knows about the finding.

<Steps>
  <Step title="Open the fix">
    Click **Fix** on a finding to open the remediation panel.
  </Step>

  <Step title="Pick your format">
    The same fix is offered in whatever formats that check ships — a **CLI** command, a **Terraform** or **CloudFormation** snippet, and click-through **console** steps. Values BreachLens already knows — the account or subscription and region — are filled in where the check's template supports them; you supply the resource-specific placeholders.
  </Step>

  <Step title="Review, then apply">
    Apply the fix in your own tooling. **BreachLens never changes your cloud for you** — it hands you the change to run.
  </Step>
</Steps>

<Note>
  **The generated command is a starting template, not a guarantee.** Read it before you run it: a remediation can create or replace resources, and a provider's defaults — a new VM's public IP, an over-broad firewall rule — can quietly widen exposure. You stay in control of the change.
</Note>

### Before you apply

Every Fix opens with a short **Before you apply** checklist — a deterministic, offline pass over the generated command, with no AI on this path. It surfaces two kinds of note:

* **Hardened** — a change BreachLens *already made* to close a self-inflicting gap in the vendor snippet. The classic is `az vm create`, which provisions a **public IP and open SSH by default**; BreachLens appends the flag that strips the public IP so the "fix" doesn't open a new exposure. Every such change is flagged, so you always see exactly what was altered — never a silent rewrite.
* **Worth a look** — a gap that's real but too intent-dependent to rewrite automatically, left for you to decide: an OS mismatch between the CLI and the Terraform, ingress from `0.0.0.0/0`, a hardcoded secret, or a legacy managed image where a newer option is preferred.

### AI review

For a deeper second opinion, click **AI review** in the Fix panel. It reads that exact command and returns a verdict — **safe**, **caution**, or **risky** — with what the command changes (its blast radius), any new exposure it might introduce, and a short pre-flight checklist to confirm first. It's **advisory only**: it never applies or blocks the fix, and you always read the command yourself.

Unlike the always-on *Before you apply* checklist, AI review calls your configured AI provider, so it runs on request rather than automatically — one click per fix, when you want it.

You don't confirm the fix inside BreachLens — the **next scan does**. Once the underlying check stops failing, the finding [resolves itself](#keep-it-current) on the following posture scan. That re-scan, not the command, is the proof it worked.

## Keep it current

Cloud drifts constantly — a bucket goes public, someone widens a role. BreachLens re-scans every connected account **automatically each day** (turn a specific account's daily scan off in its Settings if you'd rather scan it only on demand), so drift and remediation are picked up without anyone clicking; you can also **Run scan** on demand, and the per-scan **⇆ Diff** shows exactly what changed since the last run.

Findings are **self-resolving** — each one tracks a specific misconfiguration *check*, so the first scan after you fix or delete the underlying resource marks it **resolved** on its own, no manual triage needed. An account's finding count reflects **open** findings only, with resolved ones shown separately, so a falling count reads as progress rather than data quietly disappearing.

## Next steps

<CardGroup cols={2}>
  <Card title="Monitor continuously" icon="repeat" href="/pipeline/continuous-monitoring">
    Schedule nightly posture re-scans and route drift to Slack / Teams / Jira.
  </Card>

  <Card title="Scan container images" icon="box" href="/scanning/containers">
    CVE detection on the images you deploy, with reachability tiering and signature verification.
  </Card>
</CardGroup>