The 2026 Buyer's Guide to Open Source Vulnerability Remediation

How to evaluate your options, price the status quo, and make a decision your executive team will actually approve.

A note on the numbers. The salaries, headcounts, and costs in this guide are illustrative. They're drawn to be realistic so the math works the way it does in a real budget meeting - but they're examples, not benchmarks. Replace them with your own.

The problem you're actually buying against

Every security leader hits the same moment. You run a scan, the number comes back, and the number is bad. Thousands of open source vulnerabilities across your product - some in libraries, some in base images. And the part that matters most: it's growing.

Open source vulnerabilities are a faucet, not a puddle. The snapshot isn't the problem. The inflow is. Whatever you choose has to keep working every week, not clear a backlog once.

This guide walks the four real options, how to put a defensible price on each, and the questions to ask before you sign anything.

The four options (yes, four)

Most buying conversations pretend there are two: keep doing what you're doing, or buy something. There are actually four.

1. Accept the risk - do nothing. Cost: $0 on paper. Name it so no one mistakes it for the "free" one.
2. Use your existing engineers. The default at most companies without a security program - whether or not they've priced it.
3. Hire a dedicated security engineer. What most mature programs do.
4. Buy a remediation platform. The option where the breaking-change problem goes away.

Option 1 is the deceptive one. It's $0 until it isn't. Every open finding stays open, and the day one of them gets exploited, the price isn't a line item - it's a breach, a disclosure, and often someone's job. Put it on the table so the room sees it for what it is, then move on.

The single most important move in the whole process: don't pitch a tool. Present these options with a cost attached to each, and let the math do the selling. Executives don't love a yes/no on a product they've never heard of. They're very good at choosing between priced options.

Option 2: use your existing engineers

Pros. No new spend - it's already inside the engineering budget. Your developers get more security-literate over time, which has real long-term value.

Cons. Lost development time, and a lot of it. The team realistically only resolves criticals and some highs before the next wave arrives - a treadmill. Developers are slower at triage than a specialist, through no fault of their own; triage is a skill. And where an upgrade is required, it tends to introduce breaking changes, which means regression testing, which means even more lost time.

Price the status quo - this is the number that changes the room. Nobody line-items developer time spent on vulnerabilities, so it looks free. Put a number on it:

50 developers × ~10% of their time on OSS vuln research and fixes × $160K average salary = ~$800,000 / year.

It never appeared on a budget. You were paying it anyway. Once that figure is on a slide, the "do nothing" option becomes the most expensive line in the room.

Option 3: hire a security engineer

Pros. A specialist researches, triages, and decides whether each finding actually applies in your context or is a false positive - that context is everything. It recovers some of the hidden developer cost from Option 2, and when a vuln is legitimate, an expert can guide the fix and explain why it matters. That mentorship compounds.

Cons. A salary of ~$180K+, plus everything else a headcount costs. And it's still one person on the same treadmill: new criticals keep arriving while mediums and lows - some of them exploitable KEVs - pile up. Crucially, the engineer can triage but can't regression-test the whole product alone. Developer time is still required.

The thing Options 2 and 3 share: both still end with a human upgrading a package. The breaking-change problem doesn't go away no matter who owns the ticket.

Option 4: buy a remediation platform

This is the option where the breaking-change problem actually goes away. Instead of chasing upstream upgrades, a remediation platform backports the security fix onto the version you already run - same version, same API, no version bump, no breaking changes. The vulnerability is gone; the artifact you trust is unchanged.

What to expect from a serious platform:

• Remediation without a package upgrade - no breaking changes, minimal-to-zero developer time (the vendor tests the patch).
• Coverage across critical, high, and medium/low - not just the top of the pile.
• Zero-vulnerability base images, which can clear an entire base-image backlog in one move.
• A patch-availability guarantee (e.g., 80%+) and a path to request a fix when one isn't ready - typically landing within a couple of weeks.

The one honest con: you're relying on a vendor for security patches. Name it before your execs do (more on that below). Priced against Options 2 and 3, a platform often lands at less than half the cost of a dedicated hire and a fraction of the hidden developer cost - but confirm that against your own stack.

The two charts that do the heavy lifting

Bring exactly two visuals to the meeting.

1. Annual cost by option, side by side. Footnote the Option 2 bar clearly: it isn't new spend, it's the lost-developer-time cost you already pay. That single reframe makes "do nothing" the most expensive bar on the chart.
2. Share of critical/high findings resolved over time, by option. With existing engineers or one hire, the curve crawls - every fix competes with feature work. With a platform, it climbs fast and keeps climbing, because patching doesn't depend on your developers' calendars. Label it as an assumption from experience. Executives respect a stated assumption far more than a suspiciously precise prediction.

Handling the only objection that matters: vendor reliance

The one real pushback is almost always: aren't we trusting one vendor for our security patches?

The answer that works is an analogy. You already rely on vendors for security patches everywhere. Google patches Chrome. Apple patches macOS. Microsoft patches roughly half the software on earth. Nobody treats that as an unacceptable dependency - it's just how patching works. A platform applying that same model to open source libraries isn't a new category of risk. It's a new vendor in a category you already accept.

Run a proof of value before you buy

Don't take any of it on faith. A short PoV turns vendor claims into your own numbers.

• Measure real patch availability on your stack. If the contract guarantees 80%, see what you actually get. (In practice it often comes back higher - but measure it, don't assume it.)
• Test a patch end to end. Confirm "no breaking change" against your build and test suite, not a datasheet.
• Time a fix request. For anything not immediately available, how long until a patch lands?
• Verify the "Fix not Available" bucket against your real code. Findings that say "you must upgrade" are frequently stale, build-time-only, or already upgraded on your default branch. Check before you let them generate tickets - you may find the true number of required upgrades is near zero.

Bring your PoV numbers to the meeting. Your own data beats the vendor's every time.

How to report it upward after you buy

Executive support survives on visible movement, not a dashboard nobody logs into.

• Total remediations over time. The cleanest evidence the investment is paying off - it only moves one direction.
• Risk Pressure Index = (Critical×3 + High×2 + Medium) ÷ Sealed. One weighted line that answers the only question leadership asks: is our risk falling? When it trends down, the story tells itself.
• Remediation Coverage for criticals/highs = sealed ÷ total. Sits near 100% at steady state, dips when a fresh wave lands, recovers as fixes ship. A temporary dip is normal; a dip that doesn't recover is the thing to chase.

The buyer's checklist

• [ ] Priced the status quo (developer time) and put it on a slide
• [ ] Presented four options with costs, not a single ask
• [ ] Ran a PoV and brought your own numbers
• [ ] Confirmed "no breaking change" against your build
• [ ] Named the vendor-reliance con and framed it against Google/Apple/Microsoft
• [ ] Labeled every assumption in your charts
• [ ] Agreed the upward-reporting metrics before go-live

The bottom line

The status quo always has a cost. Until you find it and put it on a slide, "free" is unbeatable - and it's usually the most expensive option you have. Price it honestly, present real choices, and let the math close the deal.