How to build security alert triage

What matters here

• Enrich before a human sees it. Most triage time is spent answering questions a machine could have answered already.
• Every suppression rule gets an expiry. A rule with no end date is a permanent blind spot nobody revisits.
• Score on the asset, not the tool severity. A medium on a production database outranks a critical on a test box.
• Measure alerts closed and time to triage, not alerts generated. Volume rises with instrumentation and means nothing.
• Track false negatives found later. That is the only honest measure of whether suppression went too far.

Who this is for

You run security operations. The queue is thousands of alerts a week, most are noise, and the concern is that the real one gets closed by somebody tired.

How it works in practice

From a detection firing to somebody deciding it matters, in order.

1. 1

   The alert is enriched before anybody opens it

   Asset owner, environment, exposure, recent changes, and whether this fired before.

2. 2

   Known-benign patterns are suppressed with an expiry

   Every rule ends, so a blind spot cannot be permanent by accident.

3. 3

   Scoring uses the asset, not the tool severity

   A medium on a production database outranks a critical on a test instance.

4. 4

   Related alerts are grouped into one case

   Forty alerts from one misconfiguration is one investigation, not forty.

5. 5

   Only what survives reaches a human

   With the context already attached, so triage starts at the decision rather than the research.

6. 6

   Outcomes are recorded on every alert

   True positive, benign, or a duplicate, which is what makes the suppression rules improvable.

Paste these into Claude Code or Codex with the Tray Headless plugin installed. Each stage runs on its own. The systems named in them are the worked example rather than a requirement, and every prompt says so.

Once per project, run /tray-workflows:set-workspace to pick the workspace these build in. Point it at a sandbox first.

1. 1

   Set up, then get the asset context

   Scoring depends on knowing what the asset is worth.

   Headless skills build-workflow

   Copy

   Use build-workflow. The systems in play are Datadog, Okta, Jira,
   PagerDuty, Slack and Snowflake, or whatever we run in those seats.
   Before you plan anything, tell me which of them are already
   authenticated in the workspace, because I do not want a connector
   stubbed that I have not authenticated.
   
   The detail that matters most is the detection sources and our asset
   inventory. I need: alerts with their raw detail, the asset register
   with owner, environment and data classification, and recent change
   events.
   
   The asset register is the constraint. If we cannot resolve an alert to a
   known asset with an owner and an environment, everything downstream is
   guessing, and that is worth knowing before we build scoring on top of
   it.

2. 2

   Enrich before a human ever sees it

   Most triage time is research a machine could have done.

   Headless skills build-workflow

   Copy

   Use build-workflow. On every alert, before it reaches a queue, attach:
   
     The asset, its owner, environment and data classification
     Whether it is internet-facing
     Deploys and configuration changes on that asset in the last 24 hours
     How many times this detection fired on this asset in 30 days, and what
     the outcome was each time
     Any related alert within a short window
     For an identity alert, the user, their department and whether they are
     a leaver
   
   An analyst opening an alert should be deciding, not researching. Every
   one of those lookups is something they would have done by hand, and doing
   them beforehand is most of the value here.

3. 3

   Suppress with an expiry, always

   A rule with no end date is a permanent blind spot.

   Copy

   Build suppression, and give every rule an expiry and a named owner.
   
     Known-benign patterns: a scanner we run, a backup job, a health check
     Expected noise from a specific asset during a known change window
     Duplicate detections of the same thing from two tools
   
   Maximum 90 days. When a rule expires it stops suppressing and asks the
   owner whether to renew, rather than lapsing silently in either direction.
   
   Never allow a permanent rule. A suppression written during one noisy week
   in 2024 hides a real detection in 2026, and by then nobody remembers it
   exists or why.
   
   Report what each rule suppressed. A rule silently eating thousands of
   alerts a month deserves a look, because it is either doing great work or
   hiding something.

   The expiry is the whole control. Suppression is necessary and it is also how detections quietly disappear, and only an expiry keeps both true.

4. 4

   Score on the asset, and group the related

   Forty alerts from one misconfiguration is one investigation.

   Headless skills tray-gotchas

   Copy

   Use tray-gotchas, then score using the asset rather than the tool
   severity:
   
     Detection severity as the starting point
     Multiplied by data classification and whether the asset is
     internet-facing
     Raised if the asset is in production
     Raised if the same detection is firing across several assets, which
     suggests something systemic
     Lowered if it fired and was benign repeatedly on this asset
   
   Group related alerts into one case: same asset within a window, same
   detection across assets, or the same identity across systems. Forty
   alerts from one misconfiguration is one investigation, and presenting it
   as forty is how the queue becomes unmanageable.

5. 5

   Measure outcomes, including the ones you missed

   Alerts generated rises with instrumentation and says nothing.

   Copy

   Record an outcome on every alert: true positive, benign, duplicate, or
   suppressed by rule.
   
   Then report: alerts closed and time to triage, not alerts generated;
   suppression coverage, meaning the share never seen by a human; precision
   per detection source; and false negatives found later, where an incident
   turned out to have a suppressed or closed alert in its history.
   
   That last number is the only honest check on whether suppression has gone
   too far, and it is the one almost nobody produces because it requires
   looking back.

6. 6

   Validate it, then hand the rules to security ops

   Because suppression is a security decision with an owner.

   Copy

   Run the per-step schema checks and the whole-workflow audit before this
   touches production. Run it shadow for a fortnight: enrich and score
   everything, suppress nothing, and compare what it would have hidden
   against what analysts actually closed.
   
   Then open the same workflow in Tray Build so security operations can
   manage suppression rules, expiries and scoring weights in the visual
   canvas.

What it connects to

Detections come from several tools and have to meet asset context before a human sees them.

Named systems are the ones most teams run, not the only ones that work. Each is an authentication in your Tray workspace, referenced by name, so the workflow never holds a credential. Where we have a connector page, the name links to it.

Questions people ask

Related guides