What It Actually Means
Modern software is assembled far more than it is written. A typical business application might directly use thirty or forty components, and those use others, and by the time it is counted properly the total often runs into the hundreds. Most of the code running your system was not written by whoever built it.
That is not a criticism. Rebuilding all of it would be absurd. It does mean the maintenance picture is different from what most people assume.
Why This Matters To You
It is where most security risk lives. The overwhelming majority of vulnerabilities in business applications are in dependencies rather than in the code written for you. Researchers find them, they are published with an identifier, they get fixed, and automated scanners immediately begin looking for systems that have not applied the fix.
That makes patching cadence more valuable than almost any security product, and it is invisible work that shows up on no feature list.
Abandonment is a real risk. Components get abandoned by their maintainers regularly. An abandoned dependency stops receiving fixes, and any vulnerability found in it stays open permanently. The system keeps working while quietly becoming a liability.
Updates can break things. Which is why they get deferred, and deferring them is how a system reaches a state where updating anything is frightening. The longer the gap, the harder the eventual catch-up, so small and frequent is genuinely cheaper than large and rare.
What Good Practice Looks Like
Automated scanning, so a newly published vulnerability in something you use is reported rather than discovered. Free, and it should be part of the pipeline.
Regular small updates rather than an annual event.
Automated tests, which is what makes updating safe enough to do routinely. Without them every update is a manual regression check and gets skipped.
A deliberate view on what gets added. Every dependency is a permanent commitment to somebody else’s maintenance decisions. Adding one to save an afternoon is frequently not worth it.
What To Ask
- Are dependencies scanned for known vulnerabilities? If nobody is watching, nobody will know.
- When were they last updated? Years is a warning.
- Is anything we rely on unmaintained? An honest team can tell you.
- What is the update process, and is it part of a support arrangement? This is ongoing work and it belongs in a retainer rather than being discovered as an emergency.
- How many do we have? Not a number to optimise, and a very large count on a small system suggests components added casually.
The Part Worth Internalising
Software does not sit still even when nobody changes it.
A system left untouched for two years has not stayed the same. The world around it moved, vulnerabilities were published in the components it uses, and the platform underneath it moved on. Doing nothing is a decision with a cost, and the cost arrives all at once when something finally forces an update.
That is the real argument for ongoing maintenance, and it is a difficult one to sell because the work produces nothing visible. What it produces is the absence of a much larger bill later.
More terms are in the glossary.
