# The cost of chasing upgrades Upgrading is the most labor-intensive way to remediate a vulnerability. It is slow, painstaking, and error-prone, and the people doing the work are developers, among the most expensive employees in any organization. The cost is not just the engineering hours spent on a given CVE. It is the way that work compounds across an inbound stream that does not slow down. ## Off-cadence interruptions Vulnerabilities are not disclosed on your team's sprint calendar. They land when they land, often with an SLA attached: 7 days for critical, 30 days for high, however your compliance posture has it written. When an SLA clock starts, planned engineering work pauses while someone investigates the CVE, decides on a fix, and pushes it through. Each of these is a context switch on a developer. The work that gets interrupted does not pick up where it left off; it absorbs the cost of being put down and picked back up. The interrupting work itself is rushed because of the SLA, which is exactly the situation in which mistakes get into production. And because the SLA does not look at exploitability, teams sometimes spend a developer for a day to fix a vulnerability with no realistic security impact, just to keep the dashboard green. ## The hard-upgrade tail Some upgrades are trivial: a patch bump on a small package, no behavioral change, the build keeps working. The team can ship those without much fuss. The remaining upgrades are the ones that consume the team's time. A hard upgrade can sit on a developer's desk for days or weeks: cascading dependency conflicts, broken call sites, regressions that only show up under load, behavioral changes in transitive packages that the original CVE was not even about. The team that wrote the upgrade typically does not own all the code that depends on it. Test coverage is rarely complete enough to catch every regression. Hard upgrades are the most common source of "small dependency bump took down production for an hour" stories in any sufficiently large engineering organization. Forced upgrades to fix vulnerabilities sometimes ship more bugs into production than the original vulnerability ever did. ## Lost knowledge of older components In a long-lived organization, the developer who originally wrote the code that depends on a vulnerable package may have moved on years ago. The team that owns the component today may not know how to build it locally, may not have a working test suite, and may not be sure whether the application even uses the vulnerable functionality. Legacy components are the worst case: old packages, sparse documentation, brittle build processes, and the smallest number of people who understand them. They are the easiest things to break and the hardest to get working again. And often the team correctly judges that it does not make sense to invest weeks of developer time on an upgrade for a component scheduled for deprecation, so the CVE goes onto the exception list. ## Code growing faster than the team can patch Engineering headcount on any given team is roughly fixed quarter over quarter. Code bases are not. Every quarter, the team ships new features that pull in new dependencies. Every quarter, more CVEs land on those dependencies. The code the team is responsible for does not just grow in size; it ages, and the people who originally wrote large parts of it move on. Maintenance gets harder over time, not easier. AI-assisted development has accelerated this. Tools that generate code per-prompt have raised the rate at which application code (and the dependencies it pulls in) grows, sometimes dramatically. The work of remediating vulnerabilities in those dependencies has not been similarly accelerated; AI tooling that writes new code does not, today, take on the multi-week effort of chasing third-party CVEs through their upgrade graphs. The maintenance backlog grows; the headcount available to absorb it does not. ## The deferred-exception pile Given the cost above, the unstated bargain teams strike is to defer most of the patching. Some vulnerabilities are tagged "unfixable" by scanners. Some are tagged that way by the team because the upgrade path is too painful, even when one technically exists. Some are accepted exceptions because the underlying component is deprecated and not worth investing in. Whatever the label, the result is the same: the open-vulnerability inventory in most large organizations is measured in hundreds or thousands. The compliance side of this is not the audit paperwork. Auditors generally accept exception documentation at face value if it is filed correctly. What is much harder to explain to an auditor, a regulator, or a customer is a scanner report that shows hundreds of unresolved high and critical vulnerabilities sitting in your environment for months. Compliance frameworks that include a remediation-speed standard (DORA, PCI DSS 4.0, FedRAMP) make this worse, not better, when the only remediation tool available is "upgrade and hope". [The Seal approach](/new-documentation/new-docs/seal-approach.md) addresses this by removing the upgrade requirement entirely. A sealed package replaces the vulnerable version without changing any of the surrounding code, so the upgrade project does not need to happen. --- # 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/the-cost-of-chasing-upgrades.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.