How to improve software supply chain security with Software Composition Analysis
For me, the Open Source philosophy is one of the most amazing concepts created by the technology community around the world. With that we can easily access, read, change, contribute and distribute software and its source code to anyone, everywhere, resulting in a big collaborative environment to improve the quality of code, develop new technologies, etc.
This seems to be an amazing working model for IT professionals, hobbyists and amateurs, in which we don’t need to reinvent the wheel every time while coding our personal or professional projects. Now we can just import some open-source components to our application and the work is closer to being done, and the best thing is: we don’t need to directly pay anything for it, it’s all free (and who doesn’t like free stuff?)!
However, nothing is always a bed of roses, while open source gives us more time, flexibility, freedom, and much more convenience, it creates a lot of security problems, sometimes hidden or unknown by most of developers, even in big tech companies.
If we think about how modern software is created, we can think of applications made with Python, NodeJS or Ruby, for example, and all of these languages will be using a package manager, like PIP, NPM or Rubygems, importing a lot of small external open source components to our application, and these small external open source components usually will also be using many others even smaller open source material. This seems to be very complex, and it is (imagine all of this takes place together with docker container images)!
In March of 2017, an Apache Struts (open source java framework) vulnerability (CVE-2017–5638) was found and got a base score of 10 on the CVSS (Common Vulnerability Scoring System). Basically, because of an insufficient and inefficient bill of materials (they didn’t know that they were using Apache Struts in the vulnerable version), Equifax was not able to patch the software at the time and because of it suffered a data leak breaching information on over 140 million US customers.
Note that the above vulnerability was not in the code made by the Equifax Developers, it was in an open-source third-party component used by Equifax developers and maintained by The Apache Software Foundation, an open-source community with over 1000 members. That shows how important it is to look not just at the code you are creating, but also at the code of the components you are using in your project.
Now that you are aware of how important it is to know which components are in your application, I will show you more problems that are caused by using open-source software/components without the correct assessment management:
First problem: no-longer maintained components If you are a developer, I am sure you will remember situations when you have been using an abandoned component that no longer has had support or maintenance for years. Components that are not “alive” can put you and your application in a seriously risky situation. It can have bugs which have not been patched, commonly known CVE and public exploits which were done to explore the vulnerabilities of the component and this fact will likely be affecting your application.
Think: maybe you are not using outdated components but one component that you are using can be importing outdated components with CVEs.
Second problem is: lack of frequent updates/patches and security coding practices Sometimes the open-source component maintainers you are using know the securities problems but they don’t quickly fix them, or they don’t even know that they have security problems because they are not looking for them. Maybe they also don’t have a clear process for dealing with application security. Another possible situation is that the component that you are using is also using other third-party components/software with security problems themselves which they don’t even keep track of.
Usually we don’t know if the developers of the third-party component have good security coding practices, might they don’t even think about it, they just copy and paste code from the internet, using vulnerable functions and components.
Third problem: no security component update process and malware Also, if we don’t have a security process to frequently review and update the components we are using in our application, we will probably be using outdated components and they can have known vulnerabilities.
Furthermore, no one with malicious intent may try to abuse genuine open-source components creating pull requests with malicious code that maybe will be accepted by the component maintainers.
So, how to fix it?
The first thing you should have is a bill of materials of all your software components and versions and compare them against some CVE database, for example, the National Vulnerability Database (NVD) and find out if you are using vulnerable components and then have a clear process to patch them when necessary.
You could do this by using a spreadsheet and manually reviewing every day all the applications you have for the components and all their versions and then comparing this against the NVD database. But this probably would be a lot of hard work and you’ll probably not be able to do this properly and fast enough.
And this is when SCA software come into play, they were created to do all of this hard work for us automatically.
SCA Software Gartner defines Software Composition Analysis (SCA) as a “technology that analyses applications and related artefacts (containers, registries, etc.) to detect open-source and third-party software components known to have security and functional vulnerabilities, or which are out-of-date for security patches, or that pose licensing risks. SCA products and services help ensure the enterprise software supply chain includes only secure components and therefore, supports the secure development and assembly of the application.”
The SCA software can make a complete scan of your application, binary, zip codebases or even container images and tell you all the components and versions which you are using. The software will then tell you when you need to patch certain components. Besides that, some SCA software can even patch them automatically for you!
Remember, you should be using SCA, unless you are coding 100% of your software. Another important thing is that a bill of materials can be a necessity for your legal team. In this case you shouldn’t be doing SCA only for security, but also for license compliance.
Some of the most famous SCA tool providers are:
Owasp Dependency Track (free)
Snyk
WhiteSource (Mend nowadays)
Synopsys
Checkmarx
Veracode
Some of these providers also provide SAST tools, and you can think that they are the same thing, but SCA and SAST have different goals. While SCA is looking for components and versions to compare with a list of known vulnerabilities, the SAST is looking for unknown vulnerabilities in the codebase. They are not the same and should be used in a way to complement to each other.
Finally, if you are working with software supply chain security, I think you should take a look at Dependency Confusion if you haven’t seen it yet.
And,
You can help the community! If you are using open source components, you should be also running security checks and scans in them, you should be finding vulnerabilities, fixing them and reporting them to the community. If everyone did it, the digital world would be much more secure.
References:
nvd.nist.gov/vuln/detail/cve-2017-5638
synopsys.com/blogs/software-security/equifa..
synopsys.com/glossary/what-is-software-comp..