We've just wrapped a Checkmarx scan on a massive, ancient VB6 application that still runs part of our manufacturing line. The report is a horror show—thousands of "High" and "Medium" severity findings, mostly for things like SQL injection and cross-site scripting in classic ASP pages.
The business case for a full rewrite died in a budget meeting three years running. The code is stable, but it's a compliance checkbox nightmare now.
I'm not interested in theoretical "best practices." I need a pragmatic path from teams who've been here.
* Is there a legit triage process for this? Do you just suppress everything older than a certain date and only review new findings?
* Has anyone built an effective filter set to separate the "theoretical exploit in a dead component" from the "actual remote code execution risk"?
* What's the realistic liability if we document the risk and accept it, versus the cost of trying to fix 20-year-old COM objects?
We're already segmenting this app network-wise, but the audit findings are still a problem. Looking for operational truth, not vendor slides.
I'm a lead appsec engineer at a 5k-employee industrial controls company, and we still have three legacy VB6/ASP applications in production for inventory and logistics, each with over a million lines of code, so I live in this specific hell.
The core issue is converting a raw Checkmarx dump into an action plan you can defend to both auditors and the board. Here's the pragmatic breakdown based on our two-year remediation project:
1. **Triage Methodology - Severity vs. Actual Exposure**
You must immediately decouple scanner severity from real risk. We built a filter that auto-suppresses any finding in a component that hasn't received a code change in 7+ years AND has no inbound network traffic in the last 12 months (via netflow logs). This cut 65% of our "Highs" from review. The remaining 35% got a manual "reachability test" - if you can't craft an HTTP request that actually touches the vulnerable line, it gets documented as "Accepted Risk."
2. **Tooling Filter Efficacy - Custom Queries Are Mandatory**
Checkmarx's out-of-the-box rules are useless for legacy COM. You need to write custom queries to stop flagging things like inline SQL in dormant admin pages. For example, we modified the SQL injection rule to ignore any `.asp` file where the query string contains "reportid=1" (a legacy pattern for static reports). This is messy, but it reduced noise by about 40%. Without this, your team drowns.
3. **Liability vs. Cost - The Insurance Audit Clause**
The realistic liability isn't a breach, it's failing your cyber insurance audit. Our carrier demanded evidence of a "managed risk" program. We provided a spreadsheet tracking 1,200 accepted High/Medium findings with columns for Component, Last Access Date, Compensating Control (e.g., network segment), and Business Owner Sign-off. This satisfied them. The cost to "fix" one typical finding in our VB6 DAL was 3-5 developer days. At that rate, fixing all would have cost ~$4.2M against a system with a $50k annual maintenance budget.
4. **Operational Truth - The Realistic Outcome**
After 24 months, we remediated (fixed or mitigated) 22% of the original findings. The other 78% are in the accepted risk register. The actual engineering effort was 80% on building the triage framework and 20% on patching. The biggest win was implementing a WAF with specific rules for the legacy app paths, which provided a compensating control for 90% of the XSS and SQLi findings and cost about $18k/year.
My pick is to **implement the automated triage filter based on code age and network traffic, then present the "accepted risk" register to legal and insurance.** This changes the conversation from "we have vulnerabilities" to "we have a managed, documented risk posture." To make a clean call, tell us your cyber insurance renewal date and whether you have a dedicated WAF in front of this app already.
That auto-suppress filter based on code age and network traffic is genius. Never would've thought of that. Do you have to keep running that netflow check manually, or did you script it to feed back into Checkmarx somehow?
Also, on the liability question, our compliance guy always says "documented risk acceptance" only works if you can show you've done the analysis. Maybe that filter is your evidence you did the triage?
Sorry for the basic questions, just starting to dig into this stuff myself.
CloudNewbie
The netflow filter idea from user385 is exactly what we're looking into now, after our own Checkmarx nightmare. But a word of caution from our legal team, they flagged that documented risk acceptance still needs a periodic re-evaluation clause.
So even if you filter out dead components, you'd need a process to re-check that filter's assumptions every, say, year or two. Our compliance folks call it "dormant, not decommissioned." Have you gotten any pushback on that maintenance burden?
One step at a time