Trusting the software supply chain
Business depends on other people's components and updates. That is an architecture question, not just a security question.
When I look at a typical enterprise system, I see the same picture almost every time: several dozen third-party libraries, a handful of external services, an operating system receiving regular updates, and a collection of open-source components. All of it running together, and most of the code not written by the company's own team.
That is fine in itself. Writing everything from scratch is neither possible nor necessary. But it has a consequence that is rarely discussed openly: the company depends on the decisions and processes of other organisations. And when something in that chain goes wrong, the company may have neither warning nor time to react.
What the software supply chain is
The supply chain in a software context is the full path from source code to running system. It includes open-source libraries, commercial components, build tools, the repositories from which dependencies are fetched, and the update services for operating systems and applications.
Every link in that chain is a point where something unwanted can enter the system. Not only through an attack, but through an error: an update that broke compatibility; a library whose author stopped maintaining it; a dependency with a critical vulnerability that the company learns about days later.
Why this is an architecture question
The software supply chain conversation usually lands on the security agenda. That is right, but not sufficient.
It is an architecture question because the decisions are made at design time: which components to use, how deeply to embed external dependencies, how to isolate parts of the system from each other, how difficult it will be to replace one component with another if needed.
If the architecture embeds third-party components deeply without isolation, any problem in that component becomes a problem for the whole system. A replacement takes months. An update is hard to verify. A vulnerability is hard to contain.
The opposite - a system where third-party components are used through clear boundaries - allows the company to swap a component, freeze a version, or isolate a problem without rewriting half the system.
What is worth checking
I am not arguing for building everything in-house or avoiding third-party components. I am arguing that dependencies need to be understood and managed deliberately.
A few questions that help with that:
Does the team know which external components the system depends on? Not "roughly" - a specific list with versions. If that list does not exist, that is already a risk.
How quickly does the company learn about security updates in the components it uses? Through official channels? Through a news story?
What happens if one of the key third-party components stops being maintained or changes its terms? Is there a fallback?
Are updates tested before being applied to production, or are they applied automatically and immediately?
Updates as a separate topic
Automatic updates are convenient. They close vulnerabilities without manual work. But they also mean that changes in someone else's code reach production without verification.
That is not an argument against updates - outdated components with known vulnerabilities are more dangerous. It is an argument for a process: a staging environment that accepts an update before production; a minimum window to check compatibility; a rollback procedure for when something breaks.
A practical minimum
Dependency management can be organised without large investment. The minimum looks like this:
- Maintain an explicit list of all external dependencies with versions - a software bill of materials, even in a simple format.
- Subscribe to security notifications for the key components.
- Set up a test environment that updates pass through before production.
- Identify which components are critical and what your plan is if they become unavailable or unsafe.
The software supply chain is not an exotic risk. It is the daily reality of any company that uses software. Which, at this point, is most of them.