Bulk IP triage queue that clears your SIEM alert backlog

Build me an app my SOC analysts open at the start of every shift to clear the pile of IP addresses coming out of our alert queue. The job here is emptying a batch of a few hundred alert IPs fast, not profiling one indicator in depth. Optimise every screen for queue throughput.

The main surface is a triage queue. An analyst pastes a list of IP addresses or uploads a file exported from our SIEM, and one handler scores the entire batch using the GreyNoise Multi IP Lookup operation, chunking the request so a batch of several hundred addresses completes reliably. Use the dataset membership flags on each result to split the batch into three lanes: addresses found in the internet scanner intelligence dataset are opportunistic internet background noise; addresses found in the business service intelligence dataset (the RIOT data, things like Google and Slack) are known business services; addresses found in neither dataset go in a third lane, and those are the ones that may actually be targeting us. The default sort puts that third lane first, because it is the genuinely interesting bucket, with the noise lane last.

Each queue row shows the address, its lane, its classification and trust level, and its current verdict if it has one. Expanding a row opens a detail panel backed by the GreyNoise IP Lookup operation for that single address, showing classification (benign, malicious, suspicious or unknown), trust level, activity tags, the actor or scanner behind it, and first and last seen dates. Keep the panel scannable rather than exhaustive, since the analyst is deciding in seconds.

When an address matches the business service dataset, render that as an explicit warning in both the row and the detail panel: blocking this address would break a legitimate SaaS the company depends on. Name the service where GreyNoise provides it. Suppress should be the obvious action on those rows.

Every row gets marked Suppress or Escalate. Persist the verdict, the analyst name, the timestamp, and a snapshot of the GreyNoise evidence in the app's own storage, keyed by IP address. When a later batch contains an address that has been triaged before, surface the prior verdict and who set it inline, so the same address is never re-triaged from scratch. The analyst confirms or overrides the old verdict rather than starting over.

Escalate opens a prefilled ticket through the Jira Create Issue operation. The summary names the address and its classification, and the description carries the GreyNoise evidence: lane, classification, trust level, activity tags, actor, and last seen date. Let the analyst pick project and issue type and edit the text before submitting, then store the returned issue key on the row so the queue shows which addresses already have tickets.

Put a "Deep dive this IP" button on the detail panel that kicks off a background agent for that address. The agent runs GreyNoise IP Lookup for the address, then uses GNQL Query to pivot across the address's ASN, its organization, and its activity tags, checking whether the same campaign is hitting a wider range of our space. It writes a short investigation brief back into the app under that IP covering what it found, whether the address is part of a broader pattern, and a recommended verdict. Show a pending state on the row while it runs and display the finished brief next to the address in the queue.

Degrade gracefully on free-tier keys. GreyNoise v3 serves both noise context and business-service data from a single IP endpoint, but most fields require a paid subscription, and a restricted response comes back as partial content listing which fields were withheld. Show whatever the connected key returns, label the missing fields as needing a paid plan, and never let a restricted response break the lane sorting. Handle rate-limit responses by pausing the batch and telling the analyst what happened rather than silently dropping addresses.

Round it out for shift work: counts per lane across the top, filters for lane, verdict and undecided, a progress indicator showing how many addresses in the batch remain undecided, and keyboard-friendly verdict marking so an analyst can work down the queue without reaching for the mouse.