Skip to main content
{ Vulnerability Management } Featured agent

AWS Security Hub CSPM Finding Triage

Writes an evidence-based judgment for each open Critical and High Security Hub CSPM finding, verifies it against the live resource, and suppresses the ones the checks prove are false positives.

What this agent does

This agent triages open Critical and High findings in AWS Security Hub CSPM. It reads each finding's resource and the control or detector that raised it, and it runs read-only checks against the affected account to confirm or disprove the finding. It writes a judgment for each finding: what an attacker could actually reach, how to verify it, the conditions that would make it not worth fixing now, and the recommended fix. It suppresses a finding only when the checks prove the finding is wrong for this resource, with the deciding fact in the note.

The challenge

Security Hub CSPM collects findings from its own standards controls, GuardDuty, Inspector, Macie, and third-party products. The volume outruns what a cloud team can investigate. A control fails on a bucket that is public on purpose. An Inspector finding sits on an instance that was terminated an hour later. A GuardDuty finding points at a scanner the team runs itself. Each one sends a triager back to the console to rebuild the context before anyone can decide.

The solution

The agent does the investigation a triager would do and writes it up so the triager can agree or disagree quickly. It keeps what the control or detector observed separate from what the finding implies. It checks the most common alternative explanation for each kind of finding against the live resource. It suppresses only proven false positives, and it never suppresses a threat finding. Provides a ready-to-act judgment on every finding it reviews.

Workflow

  1. 01

    Pick findings

    Take a bounded number of open Critical and High findings with a new workflow status, from the control or product with the most findings first.

  2. 02

    Gather evidence

    Read each finding's resource, the control or detector behind it, the account, and any related findings on the same resource.

  3. 03

    Verify

    Run read-only checks against the account to test the finding and its alternative explanation, and confirm the resource still exists.

  4. 04

    Judge and act

    Record the judgment for each finding in a user-defined field, and suppress it only when the checks prove the finding is wrong for this resource.

Agent template 

# AWS Security Hub CSPM Finding Triage

## Measurable outcomes

Every finding the agent reviews has a triage judgment a triager can act on, recorded in a user-defined field on the finding. Every false positive it proves is suppressed with the deciding fact in the note. Track how many findings were triaged and suppressed, and how many open questions remain, on each run.

## Procedure

Each run, take a bounded number of open Critical and High findings from AWS Security Hub CSPM in the accounts and regions I set, with a workflow status of new. Work through one control or product at a time, starting with the one that has the most findings, and skip findings already triaged. Let me choose which sources it covers: Security Hub CSPM standards controls, GuardDuty, Inspector, Macie, and third-party products. For each finding, read the resource, the control or detector that raised it, the account, and other findings on the same resource. Treat every finding as a claim, not a fact. Write "the control reports the bucket policy allows public read", not "the bucket is public". Check the common alternative explanation for each kind of finding, such as a bucket that hosts a public website on purpose, an instance that no longer exists, a security group with no attached interfaces, a GuardDuty source address that belongs to a scanner the team runs, or a Macie classification on synthetic test data. Run read-only checks against the account to settle each one, and confirm the resource still exists. For a package vulnerability, list whether the vulnerable code path runs as an open question. Test public access without credentials, and never print sensitive data. For each finding, write what an attacker could actually reach, two or three verification checks with the real resource names, the conditions that would make it not worth fixing now, the remediation options with one recommended, and the questions the evidence cannot answer. Record the judgment in a user-defined field on the finding, with a key I set. Set the finding to notified only after its Linear or Jira issue exists. Suppress a finding only when the checks prove the finding is wrong for this resource. Put the deciding fact in the note, which holds 512 characters, and the full judgment in the report. Never suppress a GuardDuty or other threat finding. Never suppress a finding the team might accept as a risk. Accepting a risk is a decision for the team. When the resource no longer exists, say so and let Security Hub CSPM archive the finding when the control next evaluates it. Without cloud access, write the judgment and change nothing. Start in a report-only mode so I can review its judgments before it changes any finding.

## Requirements

It needs AWS Security Hub CSPM access to read findings and to update their workflow status, notes, and user-defined fields, optional read-only access to the member accounts in scope for verification, and nothing more. It never changes cloud resources, standards, controls, or automation rules. It changes nothing in Security Hub CSPM except the workflow status, notes, and user-defined fields of the findings it reviews.