Introducing Fix-First: A New Model for Open Source Security

Everyone knows open source needs to be kept up to date. But upgrading those libraries? That’s where the real friction shows up—disruption, time, the risk of breaking an app, and constant pressure from delivery timelines.

And so teams defer.
And defer.
And defer again.

Every deferral increases risk—and multiplies the cost the organization will eventually have to pay.

This is the cycle nearly every engineering and security team is trapped in today. Not because people don’t care about security or building resilient software, but because the current approach makes modernization impossible to scale.

Why Prioritization-First Actually Increases Technical Debt

Most AppSec programs use a prioritization-first model. It sounds reasonable: find the most important vulnerabilities and focus developer time there.

But here’s the truth about prioritization we don't like to admit:

Prioritization-first isn’t only about fixing the most important vulnerabilities.
It’s also about shrinking the list down to a number AppSec hopes engineering might be able to fix.

And that number isn’t based on actual engineering effort—because AppSec usually has no way of knowing:

• How do vulnerabilities translate to remediations
• Which upgrade path will result in the most security impact with least amount of developer effort
• Whether the upgrade will break the application

Figuring out the true remediation effort, across thousands of libraries, versions, services, and transitive packages, would require years of developer time.

No organization can afford that.

Meanwhile, dependencies continue aging. Tech debt and risk grows. And because upgrades don't happen, prioritized vulnerabilities often can’t be remediated without major version jumps, making the backlog even harder to unwind.

Prioritization-first doesn’t reduce technical debt.
It systematizes it.

Backporting: A Modern Approach That Still Builds Debt

Some teams try to avoid major upgrades by backporting patches into old library versions.

The intent is noble.
The outcome is not.

Backporting:

• Keeps you on outdated version lines
• Misses dozens of non-security fixes bundled into modern releases
• Creates nonstandard libraries that confuse SBOMs and customers
• Complicates maintenance
• And still forces painful upgrades later—only now with more drift and more risk

Backporting doesn’t modernize your codebase, it simply reinforces technical debt.

The Fix-First Philosophy: Modernize by Default, Not by Exception

Fix-first flips the model:

Upgrade everything you can.
Prioritize only what’s left.

Instead of trying to predict the least painful subset of vulnerabilities, fix-first removes the pain by removing the friction. The goal isn’t to guess which upgrade path might be worth doing, it's to make upgrades easy enough that you don’t have to guess at all.

Fix-first means:

• Staying current instead of catching up
• Removing risk at its root instead of layering tactical patches
• Turning modernization into a routine act, not a heroic one

Fix-first isn’t more work.
It’s removing the work that keeps teams perpetually behind.

How Heeler Makes Fix-First Possible

Legacy tooling can’t achieve fix-first because it can’t understand code deeply enough, and can’t perform the work needed to validate changes safely.

Heeler was built specifically to solve this.

1. Automatic upgrade discovery & dependency modeling

Simply connect your repos and artifact registries. Heeler emulates your build, generating a complete dependency graph, including first-party libraries and all transitive dependencies, without pipeline changes.

2. 70–80% of upgrades handled automatically

Heeler starts by performing deterministic analysis to translate vulnerabilities to remediations, and calculate the upgrade impact of these upgrades based on the dependency graph. Heeler’s AI agents take this analysis and then run a multi-step workflow, perfomring the work the developer would normally do to update dependencies, make necessary first-party code changes, validate compatibility, and produce merge-ready PRs.

These automated upgrades collapse backlogs that teams previously assumed were permanent.

3. The remaining 20–30%: prioritized with runtime context

For upgrades requiring developer involvement, Heeler generates:

• A complete, deterministic upgrade path and summary of material changes between current version and recommended version
• Runtime exploitability analysis, including assessment of exposure, library reachability, mitigations, and active exploits

Heeler’s patent-pending technology maps code to cloud—from changesets to deployments—to identify which vulnerabilities represent true risk to the business.

4. Guardrails to prevent new debt

Modern codebases accumulate risk the moment developers merge new dependencies with known risk—intentionally or accidentally. Without prevention, every sprint may introduce new vulnerabilities, new licensing liabilities, and new future upgrade challenges.

Heeler’s guardrails ensure that fix-first doesn't just unwind historical debt—it prevents new debt from forming. This shifts security from reactive cleanup to proactive quality assurance.

Heeler can observe, warn or block PRs that add new risk including:

• Vulnerable packages (with or without fixes available)
• Abandoned or malicious packages
• Risky-licenses
• Poorly maintained dependencies
• Unapproved packages

Imagine a World Where Upgrading Is Easier Than Deferring

A world where:

• The safest path is also the simplest
• Up-to-date becomes the default state
• Modernization requires no heroic effort
• Risk decreases as velocity increases

That world isn’t theoretical.
That world exists with Heeler.

Fix-first isn’t just a philosophy—it’s a transformation.
It’s the shift from “what can we possibly fix” to “we fix everything we can, automatically.”

And once you adopt fix-first, you never go back.