Secure code is important. Writing secure code is hard. Developers often use guidelines such as the OWASP TOP 10, a list of the 10 most critical security risks, to help them avoid the most common risks. But what if a security issue is not found in your code but in one of your dependencies?

Research suggests that 99% of all codebases contain open source code and that 85 to 97% of enterprise codebases comes from open source. That means that most of your code is not written by your developers! Instead, we all depend on open source code to build our own applications.

This opens you up to new risks for your organization. Do you know what open source your organization uses? Do you know who created those open source packages? Do you know if they maintain those packages? What if a vulnerability is discovered in a package that you’re running in production?

Understanding the risks of open source

The Equifax breach is a typical example of what can happen when we use open source software. Equifax used a very popular package, Apache Struts, that had a security vulnerability that allowed hackers to extract data for half the population of the US.

What’s especially noteworthy in this example is that the Apache Struts vulnerability was already known for months and a fix had been created by Struts. Unfortunately, Equifax was running an older version in production and they never deployed this patch.

Another type of attack is one where malicious code is added to an existing package that has a large user base. One such example is the “event-stream” NPM package. This package is used as a dependency by millions of other open source packages. The maintainer of this package welcomed some extra help from a new maintainer. The new maintainer added malicious code to swipe bitcoins from Copay wallets. It took two months before the malicious code was identified and removed and in the meantime the package was downloaded millions of times.

Shift left with DevSecOps

Since we can no longer ignore open source, the software development industry is investing heavily in improving the security of open source.

This means a change in the way DevOps teams work. Since such a large part of your application comes from open source packages, it’s impossible to verify all of these manually. You also don’t want to rely on security tests that run right before your application goes to production since the removal of an open source package often means that code has to be rewritten.

Instead you want to move security to as early as possible in your automated continuous integration and continuous delivery pipelines. By automating the checks and integrating them into your pipeline you can be certain that no unpatched package will go to production. This also makes sure that individual developers can’t forget to verify a package.

Some examples

Many vendors are building products that will help you secure your open source usage.

GitHub for example has developed functionality where your code is automatically scanned for open source packages, analyzed for any known issue and when an issue is found, a pull request is created that updates the code to a newer version. Since GitHub hosts so many open source packages, this gives them the opportunity to secure code across dependencies.

Another popular vendor is WhiteSource. They offer a product that helps you manage your open source dependencies by monitoring which versions of packages are used and there license types. As a part of your CI/CD pipeline, WhiteSource analyzes all packages that you use and will even notify you if somewhere in the future vulnerability is detected in a package that you have deployed to production.

The same tactic is applied to Docker container images. Reusing an existing public image is a form of an open source dependency. Snyk analyzes your containers and checks if there are issues in your base images or in any of the open source libraries that you add to the image.

Next steps

If you develop software, you need to invest in securing your open source usage.

Start with looking at the examples mentioned in the previous paragraphs. Don’t invest too much time in figuring out which product is the best but just choose one that integrates with your CI/CD product and start adding it to your pipelines. You will get a rich amount of data that can help you understand how you are using open source and which applications are at risk.

Then continue tweaking your process and make sure that you have a robust DevSecOps implementation so you can use open source in a secure way!