Another day, another dozen tickets from Mend screaming about a "Critical Vulnerability" in a transitive dependency that was last updated during the Obama administration and is only invoked in our codebase if you run the legacy reporting module... backwards... on a leap day. The noise-to-signal ratio in these SCA tools is frankly artistic. We've all been there, right? You triage the same false positive for the fiftieth time, muttering about CVE descriptions that haven't heard of context.
So, I got bored of the ritual. Instead of just grumbling in the team chat, I wrote a script to automate the despair. The premise is simple: Mend's API is decent, and most of our false positives fall into a few predictable patterns—dev dependencies, unused code paths, certain packages we've deemed "blessed" despite their alleged sins. Manual triage is a tax on engineering time that we're just accepting.
The script runs on a schedule (hello, CI cron job), hits the Mend API for new, high-severity tickets in a given state, and applies a set of our own heuristics. If a ticket matches, it auto-resolves it with a canned justification. It's essentially a policy layer Mend itself should provide but, bafflingly, doesn't in any usefully flexible way.
Here's the core of the logic, stripped down:
```python
# A gross oversimplification, but you get the gist.
def should_auto_close(vuln_ticket):
# Heuristic 1: It's in a dev dependency (we check our project config mapping).
if vuln_ticket.package in dev_deps:
return True, "Development dependency; not deployed to production."
# Heuristic 2: The vulnerable function is never called in our actual code (via code analysis results we store).
if not is_function_reachable(vuln_ticket.cve_id):
return True, "Vulnerable code path not reachable in application."
# Heuristic 3: It's in a package we've marked as reviewed and accepted (e.g., our 'approved risks' list).
if vuln_ticket.package in accepted_risks_registry:
return True, "Risk reviewed and accepted per security council policy #123."
return False, None
```
It logs everything it does, obviously, and we review the logs weekly to catch any overreach. The result? Our ticket backlog went from "apocalyptic" to "mildly concerning." Engineers only get alerted to things that pass through this filter, which are actually novel and require human thought.
Now, I can hear the purists already: "But you're just ignoring security issues!" No. We're applying *our* security policy programmatically. The alternative was alert fatigue leading to *actual* critical issues being missed. This is simply moving the triage from a repetitive, manual UI-clicking exercise to a codified, auditable process.
Of course, this is a hack built on a paid product that should really have this functionality. It feels like these tools are built for security teams who never talk to the engineers drowning in the tickets. Has anyone else resorted to similar automation? Or found a Mend configuration setting that actually works to reduce the flood without just turning off whole swathes of scanning?
🤷
🤷
Ah, the classic "Obama-era transitive dependency in a leap-day-only code path" false positive. I've danced that waltz more times than I can count.
Building your own policy layer on top of these tools is the only way to stay sane. I did something similar for a previous team, but we added a mandatory one-week "cooling off" period before auto-closing. The script would flag the ticket and add a comment, but wait seven days in case a human wanted to veto. Found a couple of real issues that way that our heuristics missed.
Just watch out for the API changing on you. I got bit once when a vendor "improved" their API and my neat script started closing everything, real and fake. Had to build in a dry-run mode and better logging after that little panic attack
it worked on my machine
The cooling off period is smart. We did something similar but tied it to our release train. If a vulnerability surfaced in a library that wasn't being deployed to prod in the next two weeks, it went into a "watch" queue. Stopped us from burning time on issues in artifacts that were about to be deprecated anyway.
Your API change horror story is why any script like this needs idempotency and a hard commit switch. Mine logs the intended action with the full API payload, then requires a second run with a `--execute` flag. Lets you diff the planned and actual state if things go sideways.
garbage in, garbage out
Tying the cooling-off period to the release train is a sharp pattern. We do something similar, but we also map vulnerabilities to our service dependencies. If a flagged library is only used by a service that's marked for decommission in the next quarter, we automatically downgrade the ticket's priority rather than close it. It keeps the queue clean but leaves a breadcrumb trail.
Your `--execute` flag is non-negotiable. I'd add a step to snapshot the ticket state before that second run - something as simple as a JSON dump with timestamps. That way, if the vendor API does change unexpectedly, you're not just diffing planned vs actual, you can also replay or roll back based on the pre-change snapshot.
That's a great approach. Our team deals with the same noise with Snyk.
How do you structure your heuristics? Is it just a big if-else block or something more maintainable? I'm worried our rules will get messy fast.
That's a neat idea with the release train! I'm trying to think how to apply that in a marketing context. We use a similar script for scoring leads, and a cool-off period stops us from pouncing on every website visitor.
But I worry about missing a "hot" lead because it landed during a quiet week. How do you balance that automation with missing a real, urgent issue that just happens to fall outside the deployment window? Do you ever get pushback from security teams?