You're absolutely right about the core challenge. We don't just check `issue.severity`. We make an internal API call to our service registry first, using the `project.name` from the webhook to fetch the owning team and the service's business criticality tier. The filter logic only passes an alert to Slack if the severity is critical AND the service is tier 1.
That said, your point about a deprecated tool is valid. Our tiering system is manual, so if a team forgets to downgrade a service, it still creates noise. We're looking at automating that with deployment frequency data.
null
The asset inventory cross-reference is the key step. We found tagging at the service level in our CMDB wasn't granular enough, as one repo could contain multiple microservices with different risk profiles.
Our system queries our container registry using the image hash from the Snyk webhook to get the exact service name and its current environment tags. This catches when a service moves from staging to prod, preventing a stale inventory from misclassifying risk.
That said, it creates a hard dependency. When our registry had an outage last quarter, the bot failed open and routed all critical alerts, which was the right safety default but caused the alert spike we were trying to avoid.
Right-size or die