Overcoming Software Supply Chain Risk
Table of Contents
Few can deny that the software supply chain has become more complex compared to ten years ago.
Whereas before you had a programmer building many different systems such as the back-end, the server, the database, today you have many experts engaged in developing software in their own specific areas. Also, the abundance of third party components, which helped development teams to speed up software development, has led to an increased usage of commercial libraries and open source components in commercial software products.
Although these two trends have increased the complexity of the software supply chain, there has not been a lot of focus on better managing the supplier dimension of the software supply chain and improving control and visibility.
Can’t See the Wood from the Trees
Software development today is a truly communal affair. A software program typically consists of many types of software components, like proprietary code, open source components and commercial libraries. This is true also for projects developed by subcontractors. With so many different software suppliers using many different types of code, can you really know what you have in your software?
The problem, similar to manufacturing lines, is that a malfunction in the smallest part can have a massive knock-on effect on a product. Some may ask why draw parallels between software development and manufacturing supply chain, for while the latter enjoys direct communication between manufacturer and supplier, while developers are not able to interact with authors of third-party components. Yet just as in the manufacturing supply chain, different suppliers offer components of varying quality and integrity.
Borrowing from the Automotive Sector
The automotive industry is an excellent example of an industry that understands the challenge and importance of ensuring component visibility throughout the supply chain. Due to the potentially fatal consequences of a malfunction, strict procedures and standards have been implemented for both the manufacturing and software supply chains.
This a key lesson for software development, for the freedom to choose a component supplier, combined with a lack of component quality visibility, often entails real security risk. So, how can your team feasibly identify the source of components used in your software supply chain, as well ensuring their quality?
Looking Under the Hood
Not knowing what you have increase your security and quality risks, especially when it comes to third party components. How can you fix known security vulnerability or sever software bugs if you do not even know it’s in your software?
Remember that even a vulnerability in an indirect open source dependency threatens your entire product. And when 1 out of 16 open source components contains a security vulnerability, it is a more than probable risk which explain why it’s essential to gain control over the third-party components in your system.
Applying Lessons Learned
Just as in the automotive sector, strict processes which set out clear guidelines and standards when introducing components are key to achieving visibility and security within your software supply chain. The first step is for your team to set out clear approval polices to ensure that no outdated, defective or corrupt components or commercial libraries are used. Then you can employ automation policies to ensure that all the code developed in-house conforms to said policies, as well as demanding your contractors not only follow the said guidelines, but they give you full disclosure on what code they are using. This increased component visibility within your software supply chain will award your organization the following benefits:
- Integrity – The identification and avoidance of known license and security vulnerabilities together with using the most up-to-date open source components.
- Transparency & Traceability – Knowing which and where components are used
- Remediation –Identifying out-of-date, defective and vulnerable components
With this peace of mind regarding what components are actually used within your software supply chain, your development team can focus on what they do best, developing great software!
