Skip to main content
{ Vulnerability Management }

Google Security Command Center Finding Triage

Writes an evidence-based judgment for each active Critical and High Security Command Center finding, verifies it against the live resource, and mutes the ones the checks prove are false positives.

What this agent does

This agent triages active Critical and High findings in Google Security Command Center. It reads each finding's resource and the source that raised it, and it runs read-only checks against the affected project 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 mutes a finding only when the checks prove the finding is wrong for this resource, and it records the judgment as a security mark on the finding.

The challenge

Security Command Center brings together findings from Security Health Analytics, Event Threat Detection, Container Threat Detection, Virtual Machine Threat Detection, Web Security Scanner, and third-party sources. A cloud team cannot work through all of them. A health finding fires on a bucket that serves a public site on purpose. A firewall finding points at a rule no instance matches. A threat finding flags a scanner the team runs itself. Most of a triager's time goes to looking up the project, the resource, and its owner before any decision.

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 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 mutes only proven false positives, and it never mutes a threat finding. Provides a ready-to-act judgment on every finding it reviews.

Workflow

  1. 01

    Pick findings

    Take a bounded number of active, unmuted Critical and High findings, from the source and category with the most findings first.

  2. 02

    Gather evidence

    Read each finding's resource, source, category, and properties, the project it lives in, and any related findings on the same resource.

  3. 03

    Verify

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

  4. 04

    Judge and act

    Write the judgment for each finding, record it as a security mark, and mute it only when the checks prove the finding is wrong for this resource.

Agent template 

# Google Security Command Center Finding Triage

## Measurable outcomes

Every finding the agent reviews has a triage judgment a triager can act on and a security mark that records it. Every false positive it proves is muted with the evidence in the mark. Track how many findings were triaged and muted, and how many open questions remain, on each run.

## Procedure

Each run, take a bounded number of active, unmuted Critical and High findings from Google Security Command Center in the organization, folders, or projects I set. Work through one source and category 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 Health Analytics, Event Threat Detection, Container Threat Detection, Virtual Machine Threat Detection, Web Security Scanner, and third-party sources. For each finding, read the resource, the source and category, the finding's properties, the project, and other findings on the same resource. Treat every finding as a claim, not a fact. Write "the finding reports allUsers has object read on the bucket", 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, a firewall rule that no instance's network tags match, a public IP finding on a VM whose firewall rules deny all ingress, or a threat finding whose source address belongs to a scanner the team runs. Run read-only checks against the project 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. Set a security mark on every reviewed finding with the judgment, in a mark key I set. Mute a finding only when the checks prove the finding is wrong for this resource, and put the evidence in the mark. Never mute a finding whose finding class is THREAT. Never mute a finding the team might accept as a risk. Accepting a risk is a decision for the team. Never create a mute rule. A rule mutes findings the agent has not reviewed. When the resource no longer exists, say so and let Security Command Center set the finding inactive on its next scan. Without cloud access, write the judgment and change nothing. Start in a report-only mode so I can review its judgments before it marks or mutes anything.

## Requirements

It needs Security Command Center access to read findings and to set security marks and mute state on them, optional read-only access to the projects in scope for verification, and nothing more. It never changes cloud resources, sources, or mute rules. It changes nothing in Security Command Center except the marks and mute state of the findings it reviews.