What is a software supply chain? The software supply chain is the stack of code components and dependencies used to build an application or system. It represents an inventory management and tracking process considered critical for security and dependability in software systems. Though in some ways this mimics traditional supply chains, the intangible nature of code makes software supply chains entirely distinct.
Software exists in a liminal space in our modern experience. It’s not like other kinds of products that you touch or see. Computer code can be written and read on the screen, but when executed it becomes a flurry of electrical impulses buried deep in the heart of the machine. The code itself is translated into flickering sparks, on or off, inaccessible even to programmers as it flies through processor cores and memory.
Yet the interactions we have with the output of software are real: visual and audible signals on screens, drones that float in response to commands, cars that steer themselves back to center lane when our attention drifts.
Both real and ephemeral, the software supply chain similarly exists between two worlds. While bits and bytes don’t take up warehouse storage space or make transoceanic journeys locked in shipping containers, they do emerge from a supply chain process all their own.
Welcome to the World of Software Supply Chain Management
It’s not a process that traditional supply chain managers design or oversee. There are big differences between real-world logistics trains and the things software engineering teams need to consider. Studies in international shipping, warehouse management, and freight dispatching just aren’t too useful in the information technology world.
So, most of the supply chain managers in the software world come from an IT and engineering background. They’ll have earned degrees in areas such as computer science or software engineering, or maybe project management. They’ll be focused on metrics that most supply chain managers have never heard of, like SLOC (Source Lines of Code), burndown rates, and sprint cycle time.
But other concepts found in traditional supply chain management still apply in the software world:
- Procurement - In the software world, components aren’t bought like a stack of bricks; libraries are instead licensed. But it’s still the responsibility of someone to evaluate the options, review the advantages, and line up the deals for the rights to use that code.
- Contract Negotiation and Management - In the same vein, big licensing deals are negotiated just like any other procurement contract. And once the e-ink is dry on the contract, someone will be responsible for monitoring and managing the terms of use.
- Storage - While it’s not like storing boxes of oil filters, application code does, in fact, take up a kind of space. Whether on local servers or in the cloud, someone must oversee and manage the terabytes of space modern software projects take up. That can involve infrastructure projects like building out data centers internally. Or it can mean dealing with the software equivalent of 3PL (Third Party Logistics) companies, cloud providers like Microsoft or Amazon.
Software Supply Chain Management Borrows Concepts and Practices from Traditional Logistics
Software is still a built artifact. And the build process is easily as complex as many physical goods.
Not so long ago, a programmer might sit down and write every line and every function of a program by hand. They had ultimate control of every feature, and intimate knowledge of how it was put together.
But just like houses, cars, or power tools, it turns out that reinventing the same components from scratch every time is inefficient.
Just as a carpenter doesn’t start building a house by chopping down trees and milling 2x4s, coders today don’t write out new routines to control the user interface or store logging data.
When you get to the top of the stack, where the new code is running, you may have dependencies running back to libraries written a decade ago.
When that web of dependencies becomes too complex, problems lurk.
What Is the Output of the Software Supply Chain?
In one sense, of course, the output of the software supply chain is more software. That’s what the industry produces.
But the other product of software supply chain management, the one that really justifies its existence, is one that is completely familiar to real-world supply chain managers: a Bill of Materials (BOM, or, more commonly, SBOM, for Software Bill of Materials).
A BOM is established for products of all types, shapes, and sizes to create a master list of the component parts. That list gets used for everything from procurement processes to quality control. By understanding the point of origin, the costs, and the provenance of every single item that goes into a commodity, supply chain managers can quickly track problems back to the source. They also get a snapshot view of the costs and complexity that go into the production process.
An SBOM is used for the exact same reasons. But the most critical reason that software makers track components is security.
In the Software Supply Chain, Security Is Job One
Software supply chain risk management is the real reason that logistics concepts were introduced into software creation. When a security flaw is found in a common library, when a framework maintainer stops supporting a particular feature, when suspicious telemetry starts trickling out of a product toward strange servers, security teams need to know where that code is buried.
Product managers need to have a clear picture of information like:
- Who wrote a particular library or component
- Whether or not that component is maintained, and how diligently
- What licensing restrictions are placed on the code
- Where that code is in the software lifecycle
Not only is this important for resilience and maintainability, but it’s also essential in preventing supply chain attacks.
These events are rare but becoming more common in both traditional physical supply chains and the world of software supply chains. They involve a malicious actor finding a way to insert their own code or component into the stack by compromising or posing as a supplier. The malicious code can corrupt hundreds of downstream projects that may rely on the compromised component.
When Attackers Penetrate the Supply Chain, All Downstream Organizations are at Risk
The SolarWinds attack in 2020 was a perfect example of a supply chain attack in action. Hackers compromised network monitoring software provider SolarWinds in 2019. Using their access to the software build system, they inserted trojan horse code that mimicked legitimate SolarWinds network activity, but in fact contacted servers run by the hackers. Any customer downloading the completely legitimate and verified software updates would therefore be compromised.
Ironically, their activities within the SolarWinds network went unnoticed.
Customers who were affected by the attack included the United States Treasury, the Department of Justice, Department of Homeland Security, and the National Nuclear Security Administration. Private sector companies hit included Microsoft and Nvidia. In all, around 18,000 government and private users downloaded the corrupt version of the software.
The actual impacts of the stolen data from the compromise will be felt for years to come. But as a warning sign to software supply chain leaders, the attack signaled the need for greater risk management analysis.
In other cases, software supply chain vulnerabilities aren’t created by bad actors, but simply mistakes that go unfixed. The log4j (Logging For Java) library has been used as a piece of hundreds of applications, from Minecraft to iCloud to Cisco routers, since it was introduced in 1999. But a flaw lurking in the ancient code was discovered in 2021 and exploited within days.
Tens of thousands of systems that had used log4j were vulnerable. Although a patch was issued quickly, not every organization even knew they needed it. Log4j was so deeply embedded, so ancient, and so common that many teams simply forgot it was part of their products.
Like log4j, there are hundreds or thousands of popular components that worked well enough to not be noticed—until they become a risk. Software supply chain risk management is needed to quickly mitigate those vulnerabilities.
Like Physical Supply Chains, Software Supply Chains Offer Opportunities to Innovate for Competitive Advantage
There are other ways that software supply chain management mirrors real-world logistics operations. In fact, innovations are likely to bleed over into traditional supply chain management the more that process becomes digitized.
Something that has been hot in both fields is the concept of running lean. In the programming world, that shows up in agile software development practices like Scrum and Extreme Programming, or even Kanban, a practice that any SCM student will know through their studies of the Toyota Production System.
But the software supply chain world has forged ahead with other approaches that blend manufacturing, delivery, and support in ways that could be coming to real world supply chains soon.
DevOps is a methodology that integrates development and operations roles to automate, systematize, and speed up software manufacturing and deployment. By integrating the tools, processes, and people responsible for making, deploying, and managing the product, development cycles are shortened. Feedback between users and creators is expanded.
In this system, a feature request that might take months to trickle through traditional project management could be created overnight and deployed in the morning. Tweaks could be made that same afternoon, and a new version might reach production the same evening.
As supply chains become more entwined with tech like the Internet of Things, ERP (Enterprise Resource Processing) systems, and automated warehouse systems, they are also becoming more entwined with software. Supply chain managers of every variety are going to become more concerned about software supply chain management.