Published on
This series was born from an interview on the Application Security Podcast, season 5, episode 18. Chris and Robert interviewed Steve Springett about the world of the secure supply chain. In part one, we introduce the concepts of software supply chain risk and software composition analysis and cover the need to use multiple SCA tools.
Software supply chain risk
Developers no longer write every single line of code that goes into your applications or products. Software is produced using building blocks; existing open-source and third-party components, built upon to create something new. This new approach enables organizations to build software quickly by reusing components that already exist.
The software supply chain is relatively new, evolving into a “thing” in the last five to seven years. The general idea of the supply chain has existed since the beginning of modern manufacturing. Think about a car; a car has a very diverse supply chain. Some parts come from the tire manufacturer, and others from a spark plug manufacturer. The automaker assembles all these component pieces to produce a car.
In the world of software, that same process is happening. With software, there are no solid pieces; it’s all technology, bits, bytes, components, and libraries with a small amount of custom code. Components are assembled to provide a final product, representing the car that a user can drive off the showroom floor or into a web browser.
Software supply chain, in a general sense, describes how a developer produces software. When using a modern development approach, the build pipeline is the collection point for the software supply chain and defines all the steps the developer goes through to create the software.
So far, so good. There must be a catch, and there is. Incorporating all these third-party and open source components include organizationally accepting risk for software that you didn’t write. This issue is the single, gigantic issue that defines software supply chain risk. This risk applies to both internal-use only applications and cloud offerings, and the applications that you deliver to your customers.
The goal is not to discourage the use of reusable open source and third-party components. Supply chain risk is trying to address the dangerous preconceived notion that open source is free. To borrow a line first said by Dan Cornell, “open source is free as in puppies, not as in beer.” There are maintenance and hygiene requirements that you must perform if you want your products and applications using these components to be healthy and secure.
[Build your Security Culture — security culture doesn’t happen overnight. Our belt-based approach helps build a culture that will last. Our education guides your development community through their journey and identifies your champions along the way. Visit www.securityjourney.com today to learn more.]
Software composition analysis, or not?
There is a set of commercial and open source products that have arisen to try to address the problem of supply chain risk. In the industry, we refer to them as software composition analysis or SCA tools.
Two central capabilities define SCA tools: analysis and risk intelligence. The analysis includes assessing what applications exist and determines the components that exist within each application. Risk intelligence provides the data to allow the user to decide whether to ship software or not. If the software is found to be too risky, it requires some further mitigation before shipment. Both of these things together form the basis for a software composition analysis product.
Risk intelligence should infer whether a component has any known vulnerabilities as a first-level check. Risk intelligence also reports on the open-source license to ensure that all parts in use are using organizationally approved licenses. The age of the component and when it was last updated is also good data points to consider. Old elements could have inherent vulnerabilities in the open-source software it uses.
Risk intelligence continues with whether a project is actively maintained. If a component has regular committers, then it has a better chance of being a healthy component. Measuring open support tickets also weighs in on how active the project is. If the project closes support tickets with no response, that should reflect negatively on their overall risk score.
These are examples of the different types of intelligence that go into determining whether or not to use a component. The quality of intelligence varies dramatically across the vendors and the open-source world.
The SCA or software composition analysis acronym is highly misleading and ignores a large and growing percentage of today’s software. Let’s drop the SCA acronym as a start because it’s limiting in scope and because many companies are developing to that particular scope and not understanding the breadth of the problem. Vendors focus in on the analysis portion and miss out on accurate risk intelligence.
Multiple tool SCA solution
With static analysis tools, organizations typically use one. The product depth and tuning capability of the existing solutions ensure that the average enterprise requires only a single solution. With dynamic analysis, organizations typically use multiple tools. Some use Burp Suite and others OWASP Zap as their first tool. Then they layer other commercial solutions on top to ensure they get the right results. They may also round out their dynamic portfolio with manual techniques to derive the best possible set of issues for their running applications.
With SCA today, solutions are closer to DAST where you need multiple tools to get the job done. Today, there are no real leaders in the space of SCA.
Conclusion
It’s tough to argue that software supply chain risk is not a concern of organizations large and small. We are all building software using other people’s components, and so we all must keep our eye on the security properties of those components.
SCA is still in its infancy and has a long way to go to solve the issues brought forth by the software supply chain. There are commercial and open source solutions available; you have to know the right questions to ask to judge their capabilities. Look for part two of this series, as we list the capabilities and the questions you should ask to measure how good an SCA product is, and how to measure their roadmap for the future.
