Tags: Software care
Software care is easy to think of as settled, background work: keep things updated, check for vulnerabilities, apply patches and make sure services can be recovered if something goes wrong. Those fundamentals are still vital, but we’re finding that the work needed to deliver them is changing.
Cyber attacks and service failures can bring the importance of this work into sharp focus, through the cost of recovery and the disruption to people who rely on those services. In our own work looking after government services, we’re seeing changes in the attention and coordination their care requires. We wanted to understand what’s driving that shift, so we explored some recent research.
Three developments stand out: a growing volume of vulnerabilities to assess, less time to respond, and faster software development that adds to the work ahead.
The volume of published software vulnerabilities has risen sharply. CRACI’s analysis of public vulnerability records counts around 47,800 published in 2025 and more than 86,000 by late October 2026. The monthly comparison is equally striking: around 14,900 in September 2026, more than seven times the 2,017 published in November 2022.
These records, known as CVEs, identify flaws in software, including the frameworks, libraries and platforms that applications are built from. For the teams looking after those applications, they create a stream of questions. Do we use the affected component? Does the flaw put our service at risk? Is there a fix, and how urgently should we apply it?
Even the organisations that help answer those questions are feeling the pressure. The US National Institute of Standards and Technology maintains the National Vulnerability Database, adding information about how serious reported flaws are and which products they affect. In April 2026, NIST announced that it would concentrate this analysis on priority categories, including vulnerabilities already being exploited. It had analysed nearly 42,000 vulnerabilities in 2025, more than in any previous year, but still couldn’t keep up with submissions.
Better discovery is valuable: it brings hidden problems into view. The practical challenge is turning that growing body of information into decisions about what needs attention in each service. Someone needs to identify an issue, assess its relevance, arrange approval, test the change and deploy it. The team also needs a way to recover if the fix causes problems. That urgent work happens alongside routine updates, certificate renewals, credential management, recovery checks and approaching support deadlines. Each has its own timetable and requires follow-through. As the volume grows and response times tighten, coordinating this work becomes a bigger part of caring for a service.
The UK’s National Cyber Security Centre expects AI to make cyber attacks more frequent and effective, partly by helping attackers find and exploit software flaws. Its assessment says the interval between a vulnerability becoming public and being exploited has already shortened to days, and predicts that AI will reduce it further.
Google’s threat researchers report an even more striking trend. Average time to exploitation fell from 63 days in 2018 to minus one day in 2024 and an estimated minus seven days in 2025. The opportunity to act can therefore be brief, or an issue may already be under attack when a fix arrives. At Boost, we’ve defined the standards of our new Evergreen software care service against this shrunken timeline - we patch urgent vulnerabilities in hours, not days.
The boom in AI-driven software development introduces another pressure. As applications become easier to create, organisations take on more software that needs to be understood and looked after.
A tool built quickly to solve a specific problem can easily become something people rely on. Its components will need updating. Its access credentials and backups will need attention. Someone will need to understand how it works when a change becomes necessary.
The speed of producing an application is only one part of its lifetime cost. Decisions about building new software need to account for the people, time and funding required to keep it useful and dependable.
The research helps explain why familiar tasks can demand a different level of effort. Teams have more findings to assess, shorter response windows and a growing range of software to look after.
For those responsible for government services, this raises some practical questions.
These questions apply whether care is delivered internally, by a supplier or through a combination of both. Answering them means looking at the capacity available, the responsibilities people hold and how work moves from identification to completion.
Familiar software, with a growing demand for care.
A service can continue working for its users while the effort needed to sustain it changes substantially. In our view, that’s the basic shift worth paying attention to: familiar software, with a growing demand for care.
