The remediation problem

Why remediating open-source vulnerabilities is hard, and what the cost of chasing upgrades does to a team.

Open-source vulnerabilities are reported every day. The hard part is not knowing they exist. The hard part is remediating them.

The traditional remediation path is to upgrade the affected package. On paper, that is straightforward: a CVE is published, the maintainer ships a fix, you take the new version. In practice, every layer adds friction. Direct dependencies you do not own. Transitive dependencies you cannot easily change. Frameworks that bundle unrelated breaking changes with every release. Components from before the original authors moved on. Code bases that keep growing while engineering capacity stays roughly fixed.

Teams that try to chase every CVE through an upgrade hit the same set of obstacles every quarter, accumulate exceptions for the cases they cannot fix, and watch the open-vulnerability inventory grow regardless.

This section explains why.

• Why remediation is hard: the upgrade cascade, transitive dependencies, hard-versus-trivial upgrades, the cases where there is no upgrade path, container patching, and EOL components.

• The cost of chasing upgrades: off-cadence interruptions, the hard-upgrade tail, lost knowledge of legacy components, code bases that grow faster than developers can patch, and the deferred-exception pile that compliance ultimately has to face.

If you already know the problem and want the Seal answer, jump to The Seal approach.