Every company that ships software ships other people's software. A modern application pulls in hundreds of open source packages, most of them transitively, most of them never chosen by anyone at the company, and a meaningful share of them maintained by one person doing it in the evening.
This was understood and ignored for two decades, because it worked. The change is not that the arrangement has broken. It is that the people who underwrite the consequences have started asking about it in writing.
The question moves from engineering to the contract
Software bills of materials made the dependency list producible on demand, which turned a vague concern into an answerable question. Once a buyer can request the inventory, the follow-up is inevitable: for the components on the critical path, who maintains this, how recently, and what is the plan if they stop.
Very few organisations can answer that today, and the answering is where the cost sits. Generating the inventory is largely automated. Assessing maintenance health across several hundred packages is judgement work, and acting on the assessment means either replacing a component, paying for supported distribution, or funding the maintainer directly — three options that all cost money against a line item that was historically zero.
Insurers have accelerated this more than any regulator. Cyber policies increasingly ask about dependency governance at renewal, and the answers move the premium, which converts an engineering preference into a number the chief financial officer can see. That is the same mechanism by which insurers became the practical regulators of corporate security, applied one layer further down the stack.
The maintainers themselves are in an odd position. Sustained funding has genuinely improved for the most visible projects, where foundations, corporate sponsorship and paid support tiers now underwrite real staffing. It has improved much less for the second tier — the library that is not famous, has four million weekly downloads and one maintainer who has been asking for help for two years. Risk concentrates precisely where attention does not.
Buyers are responding with policy rather than heroics. The emerging standard is a short list of tolerated conditions: a critical dependency must have more than one maintainer, a recent release, and a documented disclosure process, and a component failing all three requires a named owner internally and a replacement plan with a date. It is unsatisfying and it is auditable, which is what a procurement standard has to be.
The predictable side effect is consolidation. Faced with a hundred marginal dependencies and a policy that makes each one paperwork, teams reduce the count, and the surviving choices skew toward whatever the largest vendors already support. That solves the governance problem by narrowing the ecosystem, which is a trade worth naming out loud — it is the same dynamic that has pushed buyers to cut the number of tools they own, arriving in a place where variety was the point.
The organisations handling this well have stopped treating it as a security exercise. Dependency maintenance is a form of technical debt with an external counterparty, and like the rest of that debt it accrues fastest on the systems nobody wants to reopen — where the dependency list is longest, the versions are oldest, and the person who chose them has been gone for years.
Topics technologyprocurementrisk
