Walkthrough: Triaging a week's worth of SAST findings in under an hour.

So you've run your SAST tool against the monorepo on a Friday, and by Monday morning your dashboard looks like a Jackson Pollock painting of critical severity alerts. You're staring down 800+ findings, the pull requests are backing up, and the security team is starting to send you memes about "shift left." Been there. The bill for the developer hours to manually review all that would make even my AWS Reserved Instance savings weep.

But here's the thing: 95% of those findings are probably noise, duplicates, or things you can batch-ignore with the right triage filters. The trick isn't to read every one; it's to automate the sorting so you only *actually look* at the 5% that matter. This is FinOps for your security debt.

My process, which I've scripted into an inch of its life, hinges on three steps:

1. **Aggregate and De-duplicate by Code Path, Not Just Finding ID.** Most tools will flag the same vulnerability in 50 places if you call a vulnerable function in a loop. Group by the unique file + line number + vulnerability ID combo first. Then, for things like dependency scans, collapse all instances of `lodash@4.17.15` (a known vulnerable version) into a single tracking ticket. You fix it once in the `package.json`, not 200 times.

2. **Apply Project-Specific Suppressions with a Git-Ignored Config File.** Your monorepo has legacy services that will be sunset before you can fix those `java.sql.Statement` findings. Write a suppression file (JSON or YAML) that the SAST tool can read. This isn't cheating—it's declarative technical debt. For example:

```yaml
# .sast_suppressions.yaml
- rule_id: "java:injection-sql"
path: "legacy-payment-processor/src/main/java/com/old/**"
expires: "2024-12-31"
comment: "Legacy module, sunsetting Q4. Risk accepted."
```

Run your scan with this file, and watch 40% of the findings vanish from your active list. Re-run it monthly to audit the expiration dates.

3. **Sort by Exploitability & Reach, Not Just Severity.** The tool's "CRITICAL" on a dead-code function in an unused internal utility is less urgent than a "MEDIUM" in the user login flow. I pipe my findings list through a simple script that tags findings based on:
* Is the vulnerable function in a route handler? (Tag: `ROUTE_HANDLER`)
* Does the file path contain `test/` or `mock/`? (Tag: `TEST_CODE`, suppressible)
* Is the finding in a dependency that's only used in development? (e.g., `webpack-dev-server`)

After this filtration, you're left with a manageable list. I then export *that* list to a CSV, slap it into a shared tracker, and assign based on service ownership. The whole gruesome ceremony takes about 45 minutes on a Monday with a large coffee.

The key is to treat SAST output like a cloud bill—you don't pay attention to every line item, you set up alerts and budgets for the anomalies. Otherwise, you're just burning cycles on background noise.

Your cloud bill is too high.