The One Factory Problem

Somewhere in a substation older than the engineer currently inspecting it, there's a bushing. Not a metaphor, an actual porcelain-and-copper component, rated for a voltage class the manufacturer stopped producing mid-decade during a merger nobody remembers the details of anymore. When it eventually fails, the options are: source a used one from a salvage yard, pay a boutique remanufacturer eighteen months and a small fortune, or replace the entire transformer, which needs a crane, a permit process, and a lead time measured in seasons rather than weeks.

Nobody enjoys hearing this story. It's also completely ordinary. Ask around and you'll get it back with the serial numbers changed: an optical module that only one obscure fab still bins at the tolerance an old telecom chassis requires. A custom chip baked into a control system from an era when "custom" meant something different than it does today, with a mask set sitting on tooling nobody has powered on in a decade. A gearbox for equipment installed before some of the engineers now maintaining it were born, made by a company that pivoted twice and no longer quite remembers how to build the thing it used to sell.

Here's the part that should bother you more than it seems to bother anyone. We built an entire discipline around software supply chain risk in about five years. Dependency scanning is table stakes. SBOMs show up in procurement contracts unprompted. People will argue for forty-five minutes about whether a transitive dependency three levels down deserves its own CVE. Fine. Good, even.

Then the same organizations walk past a rack where every board, sensor, and connector traces back to one manufacturing line on one continent, with no second source, no spec sheet a competitor could bid against, and no plan beyond "call the guy", and nobody blinks. Nobody maps it. Nobody asks what happens when the guy retires, or the factory floods, or the parent company decides that product line isn't worth the floor space.

Loud failure versus quiet failure

Software supply chain failure is fast and noisy. A bad package gets pulled, a CVE drops, most of the internet patches within a news cycle or two. Unpleasant, but it resolves on a timescale a person can actually work inside.

Hardware supply chain failure is the opposite animal. It sits quiet for years and then it isn't quiet anymore, and there's no patch to ship. There's a lead time, and the lead time is denominated in quarters, sometimes years. By the time anyone notices the part is gone for good, the remaining options are already down to a short, bad list: pay someone to reverse-engineer a part that has no documentation left, cannibalize a decommissioned unit somewhere and hope the tolerances still hold, or tear out otherwise-healthy infrastructure because one dead component took the whole assembly hostage.

The people who know where these fragile joints are tend to be a handful of senior technicians who've been doing the job for decades. That knowledge lives in their heads, not in a spreadsheet, and it retires exactly when they do. Ask a facilities team for a dependency map of their critical hardware and enjoy the silence. Ask the same team about their software dependency graph and they'll have a report from last Tuesday.

The fix is boring, which is the whole point

None of this calls for anything dramatic. It calls for the same unglamorous inventory work software teams already normalized: know what you depend on, flag where there's exactly one source, and keep documentation for the parts you hope you never have to remake from scratch. It isn't exciting. Backing up a database isn't exciting either, and everybody still does it, because the alternative is finding out the hard way.

So map the whole dependency graph, not just the half written in code. The other half is copper, ceramic, and a supplier who might not pick up the phone in five years. That's the half that's going to end up in the incident report, and it won't hand you a CVE number to make the postmortem feel tidy.