New O’Reilly Book: Securing Open Source Libraries by Guy Podjarny

Snyk has partnered with O’Reilly to offer a new book, Securing Open Source Libraries: Managing Vulnerabilities in Open Source Code Packages.  In the book, Snyk CEO and founder Guy Podjarny covers a number of topics to help you address the risk of vulnerable open source libraries in use by your applications today. 

Vulnerable dependencies are the most likely part of your application to be exploited by attackers. The book covers some of the key best practices and tools to protect your applications at scale.

Download your free book now!

Guy starts by explaining what a known vulnerability is and how they are held publicly, like in the CVE and NVD databases; he digs into why relying on these alone isn’t good enough. Additionally, Guy covers what responsible disclosure is and steps you can take for vulnerabilities you discover.

In chapter 2, Guy digs into the meat of the book, looking at how vulnerabilities can have multiple paths in your application. This is caused when a vulnerable library appears multiple times in your dependency tree.

Consider an app that uses two packages, A and B, wherein A uses B (with the same version) as well, resulting in the following dependency tree:

Now, let’s assume B@1.0.0 has a known denial-of-service (DoS) vulnerability. When testing the app, how many vulnerabilities should we report? On one hand, the app only has one known vulnerability: DoS in B@1.0.0. On the other hand, there are two instances of this vulnerability. What should we report: one or two?

Another key topic is when to test. The book looks at the benefits that come with testing at the source level as well as the built applications. However, testing source is an approximation, whereas testing a built application is more precise. The best solution is to use both!

To combine the two, certain tools test _built_apps, but also look for package manifest files, build a logical tree, and try to fit the libraries found on top of the tree. As a result, you can be certain you get the built-app testing coverage, with (to the extent possible) the source code–driven depth of understanding.

Alternatively, you can use both approaches at different stages of your development. For instance, you can use source code scanning as part of your GitHub/GitLab/BitBucket workflow, while using a built app test in your build process or as a deployment gate. In the majority of cases, the two approaches would yield the same results and act consistently. When they don’t, the built app tests will ensure you don’t deploy a vulnerability. 

The chapter covers how you can find known vulnerabilities, in your SCM, command line, container registries, and the browser. However, this is just half the story. The more interesting part comes when you need to act on the data you’re given. Guy explains how to upgrade your direct and indirect dependencies, as well as patching when upgrade paths do not exist. It’s possible for conflicts to still occur in some languages, however:

Many languages, such as Ruby and Python, require dependencies to be global, and clients such as Ruby’s bundler and Python’s pip determine the mix of library versions that can co-exist. As a result, upgrading one library may trigger a conflict with another. While developers are adept at handling such conflicts, there are times when such issues simply cannot be resolved.

In addition to focusing on application vulnerabilities, the book also touches on how you can remediate vulnerabilities in your container images. Guy explains how, unlike with application vulnerabilities, the OS vulnerabilities are less likely to have fixed versions you can simply upgrade to. This means we rely more on good triaging practices. 

Chapter 4 covers a topic which is very important in today’s, fast-paced, modern development world -- adding security testing into your existing pipelines, to ensure that you test as you push development changes to production. This is often referred to as a DevSecOps pipeline.

Download the full book!

Setting up for quick remediation

An important part of this whole process is about how your teams react to new vulnerabilities being found, whether because of a code change or because a new vulnerability has been disclosed. Who should you reach out to when a new security notification is received? Security team? Developers? Management? How fast should you react to different types and severities of issues? Should you break builds for new vulnerabilities? Are you vulnerable to dependency chain updates? Download the book now to get guidance and more practical advice on how to get started securing your open source libraries.