Underestimating the size of something critical that you have taken on can lead to fragmented management and increased business risks.
My wife and I have four children, which means we have done a ton of shopping at Costco over the years. First it was diapers, then cereal, then every other kind of food, all of which provided significant savings for our family of six.
The thing about Costco, though, is that it is a cavernous warehouse, which creates ‘The Costco Effect’: everything looks smaller than it really is. So, it may seem like a good idea to buy 24 rolls of toilet paper (what a great price!), but do you have the space to store it?
The same applies to software supply chain security. You hear about it or read about it, and it makes sense, and you think you have understood. But when you take it ‘home’ and try to apply it to your own organization and your own processes, you realize it is much bigger than you thought.
Sizing up the supply chains
The software supply chain is everything from the idea of the application all the way through to customers using it.
The part that everyone understands is how third-party components are used as building blocks to assemble an application. These components are almost always open source software components, although third-party commercial components are also sometimes used.
It is clear that the security of these components has a direct impact on the security of the assembled application. Software composition analysis (SCA) help development teams keep track of their components and manage risk from both a vulnerability perspective and a licensing perspective.
However, managing risk in the software supply chain also means security must be considered at the time of component selection. When developers are creating new functionality, they may choose a component to be included in the application. The development process needs to have some safeguards so that when developers choose components, they base that choice on risk and not solely on functionality.
Furthermore, where do the components come from? Developers have available to them a variety of technologies that easily retrieve components, such as npm or Maven. Can you trust these? What if the component repository is compromised? How do you know you are getting the thing you asked for? A comprehensive security process addresses these questions.
Another category of the software supply chain is build tools. This includes developers’ editors, plugins, compilers, utilities, and anything else used in building an application. In airplane manufacturing, for example, the supply chain includes the seats, engines, rivets, and other parts that are assembled into an airplane, but it also includes the wrenches, rivet guns, scaffolding, and anything else that is used during the assembly of the airplane.
Finally, deployment of an application is also part of the software supply chain. Nowadays many applications are deployed into containers, so the same questions apply to software supply chain security. How are container images selected? What types of risk assessment have been done or need to be done? And just as important, where are the container images coming from? Can you trust the repository?
A holistic approach to software security
While the software supply chain may end up being ‘bigger’ than you thought, the solution for managing it is: a comprehensive approach to security.
Nobody talks about airplane manufacturing separate from safety—every design decision, every selection of parts, every phase of airplane manufacturing has an undercurrent of safety.
Similarly, security and software are becoming inextricably entwined. The process that leads from application design through implementation, deployment, and maintenance must have security infused at every phase.
Managing risk in the software supply chain is challenging but important. And software risk is a business risk. Using a holistic approach to reducing risk in the software supply chain can provide solid benefits in building trust in software.
