Open-source software dependencies are used very often when developing web applications. I found some stats on the internet that around 90% of web applications consist of third-party components.
Based on my experience, this info is quite accurate. Mainly because of the deadlines, you would use already created components, and because of the cost, you would use open-source ones.
The problem when using open-source dependencies while developing the application is that developers would most likely choose the most used one by checking the downloads on Github, and many of them would not even bother to search about open-source vulnerabilities on the internet. Search on the internet can be tricky because that information can be found in many different sources, so they are not in one place.
There is also a possibility to look in the CVE database on this link or in the NIST database. Unfortunately, OSVDB is no longer active. Though you should remain aware that there is very little info on open-source vulnerabilities in these databases. Thus it is not enough to check these databases for vulnerabilities before you choose which dependency to use.
Why using open-source dependencies is dangerous if they are not checked frequently for vulnerabilities?
It is great that you would check for vulnerabilities to choose the right open-source dependency, which is fine when you want to start using them. But, when you start using the dependencies, you need to be sure that your web application is secure, so you would need to start checking vulnerabilities frequently!
Attackers are very aware of the third-party component used in web applications, the lack of security checks for dependency vulnerabilities, etc. Because of that awareness dependencies are often the largest attack surface!
For example, in November 2018, cyber attackers inserted malicious code into the EventStream component, which was used 6 million times. You can read more about it in this article.
What to do to secure the web application which is using open-source dependencies?
In short, you can check out vulnerabilities manually or automatically.
Besides the checking, always keep in mind that you should use new versions of libraries because some known bugs developers/testers found are fixed by each new version. And you know if there is a bug, there is a way for the attacker to “get in”! So, most simply put, always update your libraries!
By manually, I don’t mean you will go through the code itself and test packages for vulnerabilities. Although if you want, you can do that as well, it is very time-consuming, i.e., inefficient! I meant that you could use already existing tools that you would run and let them check all vulnerabilities of your application’s dependencies.
There are many open-source tools/services that can be used to check for dependency vulnerabilities.
I will list some of them:
- Dependency-check is a command line tool which is designed by OWASP. It checks Java, .NET, JavaScript, and Ruby. It gets information from NIST NVD.
- Node Security Project which targets Node.js modules and NPM dependencies. It uses two databases: NIST and his own.
- RetireJS targets JavaScript dependencies. It has a specific dependency check but also provides a site-checking service for JS library vulnerabilities. It gets information from NIST NVD as well as from other JS sources.
- OSSIndex targets JavaScript, C#(.NET), and Java library dependencies. It retrieves information from NIST NVD. It also gives a free vulnerability API.
- Bundler-audit targets Ruby Bundler. It gets information from the NIST NVD and RubySec.
And by automatically, I mean you would set up your deployment to automatically check on push, merge code, etc. I will cover it in the next chapter!
What is the purpose of setting up a vulnerability checker while deploying?
Before your web application is live secure the application by implementing code workflow in your pipeline! Ensure your code and application is safe before it becomes public!
In this stage, your DevOps people are crucial!
What can you do to set up the code flow check correctly?
So, you can integrate the tool for checking the vulnerabilities throughout the entire development process.
I will give an example of flow if you are using Azure services:
- Scanning Azure Repos and Github
- Scanning Azure Pipelines
- Scanning Azure Container Registry
- Scanning Azure functions
- This stage would be divided into four parts: Scan, Prevent, Fix, and Monitor. Scan to detect vulnerabilities in the project by scanning Azure repos or Github. Scan pull requests and prevent them from being merged if they contain vulnerabilities. The implemented tool would scan for new updates and patches and automatically populate a fix. This stage is done daily. Also, you can configure the security level with a policy that will prevent code from being merged.
- This stage would be divided into three parts: Test, Prevent, and Monitor. When the Build is in process, the tool scans application dependency for vulnerabilities, makes a report, and monitors them constantly.
- This stage would be divided into three parts: Scan and monitor, Prevent and Fix. The tool would scan all container images for possible vulnerabilities. In this stage, policies can also be set up to stop the build if images contain new vulnerabilities. The tool would try to fix them.
- This stage would be divided into three parts: Scan, Monitor, and Fix. The tool would scan applications running on Azure services, monitor them, and protect deployment to ensure that no new vulnerabilities could be found in the new environment.
*Note: There are plenty of tools available which can be integrated with Azure DevOps, such as Snyk, SonarCloud, AWS Toolkit, Ado Security Scanner, Beagle Security, and many more.
On the internet, you can find many guides on how to set up an environment, depending on which tool you are going to use.
Conclusion
Open-source vulnerabilities are a very hot topic nowadays. The more you investigate, the more you will be aware that using third-party libraries puts your security in someone else’s hands.
Of course, you are not going to stop using open-source dependencies, nor should you. But, if you follow the best practices I mentioned in the article, you will be aware of the vulnerabilities and have the time to react!
Stay informed!
Cover photo by Kasia Derenda
#dependency_vulnerabilities #third-party_libraries #open-source_dependencies #CVE #NIST
