Effective software supply chain risk management requires security measures throughout the entire supply chain.
Risk management is a well-understood part of business. Personified, risk management would be a dusty, gray man with a gray beard who asks questions that make you uncomfortable.
Risk management is about understanding threats to your business and figuring out how you will deal with them.
An increasingly important part of risk management is software supply chain risk management, which is all about managing risk in the software that your business builds, buys, deploys, and maintains.
All businesses nowadays are software businesses: They either build software as part of their products and services or they buy software and use it to operate the business. Software is the critical infrastructure for all other critical infrastructure, and consequently it carries significant risks that must be managed, just like any other risks.
For many organizations, understanding how open source components are used is a critical first step toward software supply chain risk management, especially given recent activity around Executive Order 14028 and the call for a standardized software Bill of Materials (SBOM).
The overwhelming majority of software applications are a conglomeration of hundreds or thousands of open source software components held together by a little bit of code. In other words, developers grab significant chunks of functionality by using open source components, and then implement a specific application by writing code that uses those components.
While creating applications this way is fast and much easier than building everything from the ground up, it does raise some important questions related to risk. Which components are you using? Do they work correctly? Do they have security vulnerabilities? How were they tested? Are the component licenses compatible with your application license? If you find a problem in a component, are the component maintainers likely to fix it?
In theory, it is possible to track open source components manually, but this is about as practical as harvesting a field of wheat with a pair of fingernail clippers.
A software composition analysis (SCA) solution like Black Duck® automates many of the tasks involved in managing open source components, including discovery, correlating known vulnerabilities and licenses, and determining compliance with security policies.
Open source components are just one part of the larger supply chain. By way of analogy, think about a toaster manufacturer. They buy third-party components, probably create some of their own components, and assemble all the pieces into a toaster, their product. Part of their supply chain is the components they buy, the companies that create them, and whatever subcomponents are used. But equally important in the supply chain are distributors, shipping companies, and retail stores.
A software supply chain consists of everything that goes into software until the point when users touch it.
Lowering risk requires a holistic approach to security. You could do a great job managing open source components in your application, but if you deploy it on an insecure container image, heartburn and tears are sure to follow.
Getting a grasp on the entire software supply chain gives you the opportunity to apply appropriate processes and tools evenly, resulting in an overall reduction of risk.
Managing the software supply chain of your applications is challenging but necessary.
A great way to get started is simply by knowing what’s in your applications. You can use an SCA solution like Black Duck to assemble a software Bill of Materials. A good SCA solution, however, goes well beyond just identifying open source components. It can report on known vulnerabilities associated with the components you used, giving you a quick view into which components might expose security vulnerabilities in your application. In addition, an SCA solution can identify which licenses go with which components and can quickly let you know if the components you used have licenses that are compatible with how you want to sell and deploy your software.
After you’ve established a baseline of protecting your application supply chain, branch out to cover the entire surface. For first-party code, incorporate static application security testing (SAST). If your SCA tool has binary analysis capabilities (such as Black Duck Binary Analysis), you can use it to understand the composition of container images you are using for application deployment. Any infrastructure-as-code that you are using for your application can likewise be scanned with a SAST tool.
Remember that the supply chain extends all the way to when the user interacts with your application, so make sure you understand the scope and breadth. Then make plans to reduce risk holistically.
Documentation is key to success. A good starting point is the SBOM. The recent executive order is a bellwether; customers and executive teams alike will start to require evidence of supply chain security as a part of the products or services you deliver.
Application development and application security are converging. Effective risk management demands that security is part of the entire application supply chain. If you haven’t started, consider incorporating SCA or SAST into your process. If you’ve already started, make sure you are thinking about the full breadth of the supply chain and expand your activities for better coverage.
Jonathan Knudsen likes to break things. He has tested all kinds of software, from network infrastructure and medical devices to cryptocurrency nodes. Jonathan has worked as a developer, consultant, and author. He has published books about 2D graphics, cryptography, and Lego robots, and has written more than one hundred articles on a wide range of technical subjects.