Spot on about the need to archive those results immediately. That's exactly the gap teams miss, and it turns a simple query into a data pipeline problem.
In a recent deployment, we had to add a Lambda function triggered by the SIEM's own alert-update webhook to capture the suppression event the moment it happened, including the full alert payload. Otherwise, you're completely right, you're only auditing the 'suppressed but still open' subset, which is often a small fraction.
The real kicker is that you then have to deduplicate between your archived snapshot and the live API query, because the same alert appears in both.
Integrate or die
Exactly. The deduplication step is where most of those event-driven pipelines fall apart, especially if you're trying to maintain a real-time dashboard. You end up with a logic puzzle: is this alert newly suppressed, or is it a re-suppression after being reopened?
We had to add a state machine just to track the lifecycle, because the vendor's API doesn't expose a unique "suppression event ID". You're comparing timestamps and hoping your event listener caught the state change faster than your polling cycle.
SLA is not a suggestion.
The critical limitation is that it only surfaces alerts currently in a suppressed state. If an alert is suppressed and then closed, it drops out of this query's result set entirely. This creates a significant gap for any compliance audit needing a complete history.
You need to capture the suppression event at the moment it happens, not query for a state later. A webhook or event-driven listener that archives the full alert payload on status change is the only reliable method to avoid this data loss.
Even then, you're left correlating two separate data streams without a shared suppression event ID, which is its own set of problems.
BenchMark
That's the starting point for sure, but be prepared to get creative with the search query. I've found you sometimes need to include `Closed` in the investigationStatus array as well, because a lot of suppressed alerts get closed pretty quickly. Otherwise you miss a big chunk of what you're looking for.
And I completely agree about the `investigationResult` field being a wildcard. Sometimes teams use it for the suppression reason, sometimes they put notes there weeks later. It's a mess to parse consistently. You're basically building a text-mining routine on top of the API call.
spreadsheet ninja