Everyone's raving about Braintrust's comprehensive scanning, but let's be honest: half the "findings" it surfaces are about as useful as a screen door on a submarine. You run a scan, get 200 issues, and 180 of them are "info" or "low" severity noise about theoretical best practices that have zero impact in your actual environment. It buries the real problems.
The official docs suggest tweaking severity thresholds in the project config. Sure, you can set `minSeverity: "medium"` and call it a day. But that's a blunt instrument. It kills all low-severity items, including the few that might actually be worth a glance in your specific context. What I want is to filter based on the *type* of noise. For example, I don't need another reminder to use parameterized queries when my entire codebase uses an ORM that already does that. I also don't need style-guide nitpicks from a linter masquerading as a security finding.
Has anyone built a sustainable way to tame this, beyond just globally muting whole categories or severities? I'm looking for something like a persistent filter list or a way to mark certain finding patterns as "ignored in this project" without having to approve them as false positives one-by-each-time. The triage workflow feels like it's designed to make you click through every trivial alert. I'm hoping there's a config file or API trick I've missed, because my patience for wading through chaff to find the grain is running thin.
Anecdotes aren't data.
Oh, you're just discovering that "comprehensive" is a euphemism for "we bill by the finding"? Welcome to the club. The blunt instrument approach is the only one they *really* want you to use, because it makes their dashboard metrics look clean and it's cheap for them to support.
You're right that muting whole severities is useless. The real filter you need is one that understands *context*, which these tools are philosophically opposed to providing. Their business model is selling you the anxiety of a big number, then selling you the solution to reduce that number. If you could intelligently filter out the noise, you'd see how few actual, actionable issues you have.
What you're asking for, a persistent filter list, is basically a custom ruleset. You'll have to build it yourself. Every time you get a scan, export the JSON, run a script to strip out the known-bad check IDs for your project (like the parameterized query nag when you use an ORM), and *then* look at the results. It's tedious, but it's the only way to get a signal that isn't manufactured by the tool's own incentive structure.
Your k8s cluster is 40% idle.
Tell me about it. I've spent more time filtering Braintrust results than fixing actual issues.
Have you tried their custom rule tags? You can create a JSON mapping to flag specific finding patterns you consider noise, then pipe your reports through a simple script to strip them out. It's not perfect, but it's better than a blanket severity cutoff.
The real pain is when their "best practice" rules update and reintroduce noise you've already silenced. Makes it feel like a constant upkeep chore.
—b
You've perfectly diagnosed the problem with the severity threshold being a blunt instrument. I ran into this exact issue on a migration project last year, where we had to keep certain low-severity IAM findings that were actually critical for our legacy service accounts.
The sustainable approach we landed on was a two-tiered filter: a centralized suppression file for universal noise (like your ORM example), and per-project overrides. We built it into the CI pipeline with a Python script that processes the Braintrust JSON output. The script first applies the global suppression list based on rule IDs and path patterns, then applies a project-specific allowlist that can re-include specific low-severity findings we've deemed locally relevant.
You mentioned marking patterns as "ignored in this project" - that's the key. You need a version-controlled config file that lives with your project code. Ours looks like a simple YAML mapping of rule IDs to exclusion paths. The maintenance chore user998 mentioned is real, but it becomes part of your dependency update cycle, like any other toolchain update.
Custom rule tags are a step, but they still require manual mapping for every rule. Their rule IDs can shift with updates, breaking your filters without warning.
We handle this by hashing the finding's rule text and path as a secondary key. It's a bit more work upfront but survives minor rule version bumps.
You're right about the upkeep chore. Feels like you're working for the scanner, not the other way around.
I feel this so much. It's the main reason our team is hesitant to run full scans now, because sifting through all that noise just kills our momentum. You mentioned marking patterns as "ignored in this project" without approving them as false positives - I've been trying to find exactly that feature in their UI and coming up empty.
Is the only real solution here to start messing with custom JSON files and external scripts? That seems like a huge jump for someone just trying to get a clean report.
Totally get that. We hit the same thing with Argo CD apps. A blanket severity filter just hides useful stuff.
I ended up baking a filter stage into our CI pipeline, right after the scan. A simple script that parses the SARIF/JSON output and drops findings based on a list of rule IDs we consider noise (like that ORM parameterized query one). The list lives in the repo as a config file, so it's versioned and shared.
It's an extra step, but it makes the PR comment from the security check actually actionable. Have you tried something like that, or is the overhead too much?
git push and pray