Skip to main content
{ Vulnerability Management }

Orca Alert Triage

Writes an evidence-based judgment for each open Critical and High Orca alert and dismisses the ones cloud checks prove are false positives.

What this agent does

This agent triages open Critical and High alerts in Orca Security. It reads each alert's asset, evidence, and attack path, and it can run read-only checks against the affected cloud account. It writes a judgment for each alert: what an attacker could actually reach, how to verify it, when it is not worth fixing now, and the recommended fix. It dismisses an alert in Orca only when its checks prove the detection wrong, and it snoozes an alert only for a dated reason.

The challenge

Orca raises more Critical and High alerts than a cloud security team can investigate. Each one arrives as a detection, and some of them depend on a fact Orca cannot see, such as a bucket that is public on purpose, a vulnerable package on a code path the workload never runs, or a secret on a disk snapshot that was rotated after the snapshot. Triagers spend their time rebuilding the context for each alert before they can decide anything.

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 Orca observed separate from what Orca inferred, and it checks the most common alternative explanation for each kind of alert against the live resource. It dismisses only proven false positives, with the evidence in the dismissal reason. Provides a ready-to-act judgment on every alert it reviews.

Workflow

  1. 01

    Pick alerts

    Take a bounded number of open Critical and High alerts from the alert type with the most open alerts, skipping ones already triaged.

  2. 02

    Gather evidence

    Read each alert's asset, evidence, attack path, and the cloud account it lives in.

  3. 03

    Verify

    Run read-only checks against the cloud account to test the detection and its alternative explanation.

  4. 04

    Judge and act

    Write the judgment for each alert, and dismiss it in Orca only when the checks prove it is a false positive.

Agent template 

# Orca Alert Triage

## Measurable outcomes

Every alert the agent reviews has a triage judgment a triager can act on. Every false positive it proves is dismissed in Orca with the evidence in the reason. Track how many alerts were triaged, dismissed, and snoozed, and how many open questions remain, on each run.

## Procedure

Each run, take a bounded number of open Critical and High Orca alerts in the cloud accounts I set. Work through one alert type at a time, starting with the type that has the most open alerts, and skip alerts already triaged. Let me choose which categories it covers: vulnerabilities, malware, IAM misconfigurations, network and workload misconfigurations, data at risk, lateral movement, neglected assets, and suspicious activity. For each alert, read the asset, the evidence Orca attached, the attack path, and the account. Treat every detection as a claim, not a fact. Write "Orca reports the package version is vulnerable", not "the workload is exploitable". Check the common alternative explanation for each kind of alert, such as a site that is public on purpose, a vulnerable package the workload never loads, a secret already rotated, an identity that is unused by design, or a neglected asset that is a stopped instance kept for a reason. When I give it read-only access to the cloud account, run those checks. For a vulnerability on a workload, check the workload's source code to see whether the vulnerable code path runs. The source code provider and repository for each workload are set when the agent is built. Without them, list the code path as an open question. Test public access without credentials, and never print sensitive data. For each alert, 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. Dismiss an alert in Orca only when the checks prove the detection is wrong, and put the evidence in the dismissal reason. Snooze an alert only for a dated reason, such as a scheduled rebuild, and set the snooze to end on that date. Never dismiss an alert the team might accept as a risk, and never dismiss a malware, suspicious activity, or malicious activity alert. When the asset no longer exists, say so and let Orca close the alert on its next scan. Without cloud access, write the judgment and dismiss nothing. Start in a report-only mode so I can review its judgments before it dismisses or snoozes anything.

## Requirements

It needs Orca API access to read alerts, assets, and their evidence and to dismiss and snooze alerts, optional read-only access to the cloud accounts in scope, and optional read access to the workloads' repositories in GitHub, GitLab, or Bitbucket, and nothing more. It never changes cloud resources, and it changes nothing in Orca except the dismissals and snoozes.