Demo on recorded data — get early access
RisksDemo accountsLast event 0 s agoLast full scan 6 min agoSign out

Risks

What to fix first, ranked by code: each risk with its fix and what signing it closes. The rows behind them are on Findings.

Your biggest risks

1Identity

Your CI login ‹ci-deploy-bot› uses a 412-day-old key that can create new users.

CriticalAn old CI key that can create new usersHigh confidence

Fix Move CI to the OIDC role ‹ci-deploy-oidc› and delete the key.

A leaked CI key is how most break-ins start; this one can make more identities, so one leak becomes many.

Fixing it closes 3 findings and 2 paths to protected assets. 3 findings behind it

High confidence: every fact in the headline is confirmed in records AWS wrote, and the activity was seen. Precisely, proven: 4 facts from 6 records, 2 sources.

2Data

Customer data in ‹prod-customer-exports› can be read by 2 roles nobody uses.

HighCustomer data readable by unused rolesHigh confidence

Fix Remove the two unused roles from the bucket policy.

Unused readers are what someone else borrows; nobody would notice the reads.

Fixing it closes 2 findings and 2 paths to protected assets. 2 findings behind it

High confidence: at least three confirmed facts of two kinds, from two independent sources. Precisely, strong: 3 facts from 6 records, 2 sources.

3Clusters

Cluster ‹prod-eu› can be reached from anywhere on the internet.

HighCluster control is open to the internetHigh confidence

Fix Restrict the endpoint to your office and CI ranges, or make it private.

A stolen kubeconfig works from anywhere; a private or allowlisted endpoint makes it useless off your network.

Fixing it closes 1 finding and 1 path to a protected asset. 1 finding behind it

High confidence: every fact in the headline is confirmed in records AWS wrote, and the activity was seen. Precisely, proven: 4 facts from 6 records, 2 sources.

4Logging and visibility

Only 1 of 3 sensitive buckets records who reads it.

MediumNo record of who reads two sensitive bucketsHigh confidence

Fix Turn on read logging for the other two buckets.

Without data events, a case can say a bucket was reachable, never whether it was read.

Fixing it closes 2 findings and 0 paths to protected assets. 2 findings behind it

High confidence: every fact in the headline is confirmed in records AWS wrote, and the activity was seen. Precisely, proven: 4 facts from 6 records, 2 sources.

5Identity

14 IAM users can sign in to the console without MFA.

MediumConsole passwords without MFAHigh confidence

Fix Require MFA, or move the 14 people to your identity provider.

A phished password is a session; MFA makes it a dead end.

Fixing it closes 14 findings and 0 paths to protected assets. 4 findings behind it

High confidence: every fact in the headline is confirmed in records AWS wrote, and the activity was seen. Precisely, proven: 4 facts from 6 records, 2 sources.

Themes

Counts of what is open now, by severity, with the last 30 days. The findings themselves are on Findings.

  • Identity 1 Critical 3 High 14 Medium 22 Low
    40 open, up from 30 over 30 days
    Open the findings
  • Exposure 2 High 5 Medium 9 Low 1 Info
    17 open, down from 24 over 30 days
    Open the findings
  • Logging and visibility 2 Medium 31 Low 4 Info
    37 open, unchanged over 30 days
    Open the findings
  • Clusters 1 High 6 Medium 12 Low
    19 open, unchanged over 30 days
    Open the findings
  • Data 2 High 3 Medium 4 Low
    9 open, up from 5 over 30 days
    Open the findings

What changed since last week

Counted over the week from 2026-09-05.

  • Identity: 6 opened, 2 closed
  • Exposure: 1 opened, 4 closed
  • Clusters: 1 opened, 1 closed
  • Data: 3 opened, 0 closed

New in your biggest risks

1 risk from last week is no longer ranked.

Proposals waiting for a signature

By rule, from the scheduled run