New Savings Proposals: approve, test and roll back cost changesLearn more Sign in|Talk to a cloud engineer
Product tourGet a demo

Fix the findings that are worse together

When two findings land on the same resource, the overlap is usually the real risk: an open port on a machine whose role has administrator rights. Atlas puts those combinations first and keeps triage tied to the evidence.

Get a demoSee attack paths
What you're watching
  1. 1
    Ask what the risk is

    Anyone on the internet can reach port 22 on checkout-api, and its role can escalate and read 2.4M PII records. Each is High; together they are Critical.

  2. 2
    Ask who should fix it

    The team=checkout tag routes the finding to the Checkout team, first seen Sep 3 in prod-core.

  3. 3
    Check the related findings

    The open security group, the privilege escalation and CVE-2026-1182 stay listed as their own findings. The combination is the overlap.

  4. 4
    Read the remediation plan

    Three steps: allow port 22 only from bastion-sg, strip iam:PassRole and * actions, then patch and redeploy checkout-api.

Who does thisSecurity engineer on triage, with the Checkout team's engineering leadWhat you getOne Critical row with an owner and a fix, instead of separate tickets in the network and IAM queues.
Critical
0
toxic combinations and critical exposures
High
0
high-severity findings
Medium
0
medium-severity findings
Low
0
low-severity findings

Findings get closed or snoozed for the wrong reasons

Two mediums that add up to a critical, a snooze nobody revisits, and a finding that disappears when access breaks.

Security

Two findings can add up to a critical

What usually happens: An open port rated High and a permissive role rated Medium sit in different queues, owned by different teams.

How CloudLens resolves it: The combination is its own Critical row, so the overlap gets one owner and one fix plan.

Resolved
Triage

Snoozes outlive their reasons

What usually happens: A finding snoozed in March stays hidden in June, after someone opened another port on the same group.

How CloudLens resolves it: Triage is pinned to the evidence. When the evidence changes, the snooze is cleared and the finding comes back.

Resolved
Accuracy

Findings close when access breaks

What usually happens: A permission is removed, the scanner stops seeing a resource, and its findings close as if they were fixed.

How CloudLens resolves it: A finding resolves only when Atlas can still see the resource and the risk is gone.

Resolved

A weekly findings review, step by step

Dana runs the Tuesday findings review. Here is what that looked like this week.

DODana OkaforSecurity engineer, Lumora Retail

Lumora Retail is a fictional company. The people, names and numbers are sample data.

    1
    Tue 09:006 combinations

    Filters to toxic combinations

    Six rows, all Critical or High. The first reads: An open port leads to a machine with administrator rights, on checkout-api.
    2
    Tue 09:15

    Checks why it isn't a duplicate

    The open security group and the privilege-escalation permission are still listed as separate findings. The combination row exists because both land on the same instance.
    3
    Tue 09:40

    Snoozes three findings for a week

    Three findings on bastion-legacy are waiting on a decommission ticket, so she selects them and snoozes them for one week.
    4
    Thu 11:20Evidence changed

    One snooze clears itself

    Someone adds an inbound rule to bastion-legacy. The evidence behind that finding changed, so Atlas clears its snooze and it's back in Dana's queue.
    5
    Fri 10:00

    Her comment lands in Jira

    A note on the access-key finding posts to SEC-77. When the CI team moves the ticket to In Progress, Atlas shows Jira's status next to its own.
Too many findings, too little time?

See which of yours are worse together

Get a demo

Two findings, one resource, one row

Each part is still reported on its own. The combination is a separate row that marks where they overlap, which is why it ranks above either part.

An open port leads to a machine with administrator rightsNetwork + identity
Unencrypted data on a resource reachable from the internetExposure + encryption
A production snapshot is restorable outside this accountBackup + sharing
Readable credential on a function with administrator rightsSecrets + identity
Unsupported software on a resource reachable from the internetEOL + exposure
Long-lived access key on a user with no MFAKeys + MFA
sg_open_to_world

Port 22 on checkout-api accepts traffic from anywhere.

+
iam_privilege_escalation

The role it runs as can grant itself more permissions.

=
Critical · toxic combination

An open port leads to a machine with administrator rights.

Triage that follows the evidence

The overlap gets its own row, first in the list

Filter to toxic combinations and open one. The drawer explains which two facts overlap on the resource, and the Fix tab lists the steps, the owner and the evidence that was used. Both parts stay open as their own findings, so fixing either one still counts.
  • Titles that say what the overlap does
  • Overlap row next to its parts
  • Fix steps with a named owner
What you're watching
  1. 1
    Filter to toxic combinations

    Six of 1,286 findings match. The first is an open port leading to a machine with administrator rights, on checkout-api.

  2. 2
    Open it to see the overlap

    The drawer shows sg_open_to_world, internet reachability and iam_privilege_escalation on one resource. Each part is still reported separately.

  3. 3
    Switch to the Fix tab

    Owner, evidence id and last-seen time sit above four steps and the security-group diff to bastion-sg. The Jira issue is created from here.

Who does thisSecurity engineer running triage, handing off to the Checkout teamWhat you getThe overlap gets one owner and one fix plan, ranked above both of its parts.

From a new exposure to a resolved finding

A rule change shows up on the next scan, gets a path and a rank, and lands in the owner's Jira project. After the fix, the next scan confirms the risk is gone and the finding resolves with its history. Scan intervals come from your scan policy.
  • Detected on each scan
  • Ranked and routed automatically
  • History kept after resolution
What you're watching
  1. 1
    A new exposure on checkout-api

    The 14:02 scan finds port 22 open to 0.0.0.0/0. Within a minute the path to customer-exports is computed and Open critical goes from 2 to 3.

  2. 2
    SEC-77 lands with the owner

    The toxic combination is ranked Critical and SEC-77 is assigned to Priya Nair, with the path and fix steps attached.

  3. 3
    The rescan resolves it

    Port 22 is narrowed to bastion-sg at 15:40. At 16:05 the resource is still visible, the risk is gone, and the finding resolves with history kept.

Who does thisSecurity engineer on call, with the platform lead who owns the changeWhat you getA finding that closes only after a scan proves the fix, with every step recorded.

Acknowledge, start work or snooze in bulk

Select findings and set a triage state: In progress, Acknowledged, or Snoozed for 3 days, 1 week or 1 month. Triage is pinned to the evidence it was set on. If a later scan sees something different, the triage is cleared.
  • None, In progress, Acknowledged, Snoozed
  • Cleared when evidence changes
  • Export CSV, PDF or JSON
What you're watching
  1. 1
    Select three findings

    A container running as root on checkout-api, port 22 open on bastion-legacy, and a public load balancer on search-lb.

  2. 2
    Snooze them for one week

    Pick 1 week from the bulk bar. All three read Snoozed until 21 Sep, and they return early if the evidence changes.

  3. 3
    A new rule clears one snooze

    The next scan sees a new rule on bastion-legacy. That snooze is cleared and the finding is back in the queue, tagged evidence changed.

Who does thisSecurity engineer, during the weekly findings reviewWhat you getSnoozes that end on their own when the risk behind them changes.

Comments and status stay in sync with Jira

See the Jira integration
Every finding has a Fix tab, a comment thread and an activity log. Comments can be posted to the linked Jira issue. When Jira's status moves on its own, Atlas shows both statuses side by side instead of overwriting either one.
  • Fix tab with remediation steps
  • Comments posted to Jira
  • Activity log per finding
What you're watching
  1. 1
    Comment on the finding

    On the long-lived access key finding, Ana writes that the key rotates with the release going out today, with Also post to Jira SEC-77 checked.

  2. 2
    The comment syncs to SEC-77

    It posts to the linked Jira issue, and the activity log records the sync under the earlier owner assignment.

  3. 3
    Jira moves on its own

    Someone moves SEC-77 to In Progress in Jira. Atlas shows that status marked differs, with a Reconcile link, and keeps its own.

Who does thisSecurity engineer and the CI team member who owns the keyWhat you getSecurity and engineering read the same thread and both statuses, whichever tool they work in.

Decide what counts as work

Each organization sets a Tag policy (required keys, with a preview of what's missing), a Scan policy (which services, how often) and an Issue policy (a severity threshold, finding types that are always work, and types that never are).
  • Tag policy with preview
  • Scan policy: services and interval
  • Issue policy: always or never work
What you're watching
  1. 1
    Set required tag keys

    Add owner, cost-center and environment. The preview shows 212 resources missing owner before anything is saved.

  2. 2
    Choose what to scan and how often

    Toggle services, including Amazon Inspector, on a 6-hour interval. With no scan policy set, every supported service is scanned.

  3. 3
    Decide what counts as work

    Raise issues at High and above, always treat an open port to an admin machine as work, and never raise untagged resources in sandbox.

Who does thisSecurity engineering lead, agreed with the platform teamWhat you getA written rule for what becomes a ticket, applied from the next scan.

Findings across the whole stack

Kubernetes (EKS)

Privileged containers, containers running as root, secrets in environment variables, public load balancers and namespaces without a network policy.

Vulnerabilities

Amazon Inspector package findings, deprecated AMIs and unsupported engine versions.

Exports

CSV, PDF or JSON for audit packs, data pipelines and SIEM ingestion.

Resolved, with history

A fixed finding is marked resolved and keeps its history. It resolves only while Atlas can still see the resource.

About findings and triage

Each part is a real finding, and fixing either one helps. The combination is a separate row for the overlap, so it can rank above both.

Triage is pinned to the evidence at the time it was set. If a later scan sees different evidence, or the snooze period ends, the triage state is cleared and the finding returns to the queue.

No. If Atlas loses access to a resource, for example because a permission was removed, its findings stay open. They resolve only when the resource is visible and the risk is gone.

Attack Paths Chains from the internet to your data, ranked by reach.
Data Governance The data classes that decide what a finding is worth.
Jira Create issues and epics from findings.

Start with the findings that matter most

Connect a read-only AWS role or Azure service principal. We'll walk you through your bill, your security graph and the first things worth fixing.