Subscribe
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.
- What if an earthquake knocks out power on the U.S. west coast?
- What if our factory is destroyed by fire?
- What if our biggest supplier goes out of business?
- What if our product has a safety problem and needs to be recalled?
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.
Six Consideration for Securing Your Software Supply Chain
Manage open source components in your software supply chain
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.
See the bigger picture
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.
- As previously mentioned, third-party code such as open source components often makes up the bulk of an application and must be managed appropriately.
- First-party code is the code your developers write. Your developers are human, which means they will make mistakes that can result in quality and security problems.
- Understanding the provenance of components is equally important. Where do they come from? Developers often use a default repository but they might not consider the security ramifications of those components.
- Any container images or operating system images used to deploy applications are also part of the supply chain. These typically also contain many open source components.
- The provenance of container images is likewise important. Did you just pull that image out of a public repository? Who built it? How did they build it? What’s in it?
- Configurations are another important part of the supply chain. For example, the configuration of a container using infrastructure-as-code can have functional and security consequences. Likewise, the configuration of the open source components you are using can be critically important.
- Any APIs and protocols your application uses or exposes are also part of its supply chain.
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.
Start now
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.
Continue Reading
.jpg)