by Michael Wager

The development of a software product can be compared to the car engineering phase. In car engineering certain parts of a car will be assembled by 3rd-party suppliers, the same applies in software engineering to support the development and accelerate the time to market. Software developers use software from other parties, so-called dependencies, most of the time these are open-source libraries developed by the community. These libraries may be frameworks for overall development support, cryptographic helpers, and compression functions. The goal is to prevent inventing the wheel again but to check what other developers have already solved.

It is important to note just like the code you write, these libraries can have vulnerabilities too, so it is important to keep them up to date. Projects like the Open Source Security Foundation – a cross-industry forum for a collaborative effort to improve open-source software security, do their best to support the process of securing open-source software with different projects. For example, they provide support for security awareness in their practices and publish tools for an automated way to judge the overall security state of an open-source project.

Vulnerabilities in Open-Source Software

Let’s have a look at some examples of security issues in open-source software. A well-known issue was found in log4j, a logging library for Java that is widely used in applications worldwide. This library had a critical security issue, thus affecting millions of applications. Another example of so-called supply chain attacks is seen in the NPM package “ua-parser.js”. The NPM account of the original maintainer had been hijacked and the malicious threat actor then added some malware to do crypto mining on the affected machines. These machines could be local developer machines, staging, or even production servers!

So, you see, open source libraries are an attractive attack vector for malicious threat actors, and therefore securing open source components is a very important part of the Secure Software Development Lifecycle (SSDLC).

Software Composition Analysis

Fact is: Libraries will be used, so what can we do? How can we decide if a library meets certain criteria related to security? Of course, we can always do manual research before introducing a new dependency. However, this is a manual task and does not help while already using the libraries. A very common way is the use of a concept called Software Composition Analysis (SCA). The idea is to regularly scan the project dependencies for known vulnerabilities, mostly based on Common Vulnerabilities and Exposures (CVE), which is a list of public security vulnerabilities. The best practice is to automate this process inside your CI/CD pipeline. The scan should run on a feature branch when creating a pull request, or you may regularly scan the master branch. It is also very important to scan your project if no deployments happen, as new vulnerabilities may arise every day. Lots of free tools supporting a wide range of programming languages are available, e.g. OWASP dependency-check, or npm audit for projects based on JavaScript. Of course, more professional solutions for large enterprises are available on the market. Examples would be snyk, Mend, or Sonatype. They provide good support and often have large security research teams available.

Conclusion

Open Source Security is a big topic in the world of cyber security. Our security experts can consult you on deciding which tools are best for your projects and also help you integrate them into your development lifecycle.

If you have questions, contact us at cybersecurity@secure-io.de