# Why remediation is hard Remediating an open-source vulnerability almost always means upgrading the affected package to a newer version. That sounds simple. It is rarely simple. ## Direct versus transitive dependencies Most CVEs in your security report are not in code your team chose. They are in code your team's code chose. Direct dependencies are visible in your manifest (`package.json`, `requirements.txt`, `pom.xml`). You can upgrade them directly. **Transitive dependencies** are pulled in indirectly by your direct dependencies, often several levels deep. You cannot upgrade a transitive dependency on its own. You have to upgrade the direct dependency that pulls it in, or another package along the chain, to a version that pulls in a fixed copy. When the direct dependency is a small, well-maintained package, this works. When the direct dependency is a large framework, things get expensive. ## The upgrade cascade A small transitive dependency with a CVE in a code path your application does not even touch can force you to upgrade a much larger framework. The framework's new version comes with a list of unrelated breaking changes (new APIs, removed APIs, changed defaults), bumps for several of its own dependencies, and sometimes implicit version requirements on packages elsewhere in your build that did not formally depend on it. A two-line CVE turns into a multi-week upgrade project: read the framework's changelog, update the manifest, fix call sites, chase down newly incompatible dependencies, run the test suite repeatedly, validate behavior in pre-production, coordinate the release. The vulnerability you set out to fix may have been a missing length check on a parser you never call. ## Trivial versus hard upgrades Some upgrades are routine: a patch bump on a small package, no behavioral change, the build keeps working. A meaningful share of CVEs can be remediated this way without much engineering effort. The remaining upgrades are the ones that consume the team's time. A major-version bump on a framework. A CVE in a transitive dependency that requires the upgrade cascade above. A patch that depends on a feature your runtime does not have. Any of these can take days to weeks of developer time, introduce regressions, break existing call sites, or take down a production environment after a release. The trivial-versus-hard split is what makes "we'll just upgrade everything" not work as a strategy. The trivial cases are not the bottleneck. The hard cases are, and the team only has so many of them in flight at once. ## When there is no upgrade path Some CVEs cannot be remediated by upgrading at all. The chain of dependencies that pulls in the vulnerable package may not have a version combination that resolves cleanly. A package somewhere in the chain may no longer be actively maintained, so there is no future version to pin against. Major SCA scanners surface this situation as **unfixable**. Sometimes "unfixable" really means "unfixable through upgrades". Other times it means "the upgrade exists but the cost of taking it (a major framework bump, or a rewrite of the dependent code) is more than the team can absorb." Either way, the result is the same: the vulnerability sits open, and the team writes an exception. ## Container patching A vulnerability in an OS-level package or a language runtime inside a container image generally takes coordination across more than one team. Someone publishes a new base image with the patch, someone rebuilds the application's container against it, someone validates the new build. Each handoff costs calendar time, even when no one is dragging their feet. ## EOL components Some vulnerable software has no fix coming. The Linux distribution is past its support window. The maintainer of the package archived the repository. The vendor of the runtime no longer ships security updates for the version you depend on. Migrating off an EOL component is a multi-quarter project. Staying on it means the CVE list grows month over month with nothing your team can do about it. [The Seal approach](/new-documentation/new-docs/seal-approach.md) is built to address each of these cases without requiring an upgrade. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.sealsecurity.io/new-documentation/new-docs/remediation-problem/why-remediation-is-hard.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.