Scanning Vulnerable Dependencies

At the start of developing a new project, you may choose frameworks and other third party dependencies which are popular at the time. If the dependencies are well maintained, they are hopefully free from known vulnerabilities and safe to use. To make sure, you should consult a vulnerability database, like the National Vulnerability Database.

Using dependencies you can trust, is very import to get a solid foundation for your application, but as soon as you deploy the application for the first time, a new vulnerability may already have been found. You can never be sure that all vulnerabilities have been fixed in library, thus you need to periodically scan them.

While you are developing, and building your application, you should have a build step which scans your dependencies. Depending on the language and build system you use, a lot of tools are available.

Some of the tools you can use in your build pipeline are:

• OWASP Dependency Check has support for Java, .Net and more.
• NPM Audit checks packages in NPM for vulnerabilities by running npm audit.
• Retire.Js checks JavaScript libraries in your application, can also be used with a browser plugin.
• Brakeman will check your Ruby dependencies, and is created for Ruby on Rails. It will also do static analysis of your code.

Running one or more of these in your pipeline, and possibly failing the build, will stop you from deploying known vulnerabilities.

It is normal that an application can live many years after the development process is finished. This means that many of the libraries will get old, and in many cases will have known vulnerabilities after time passes.

To make sure we get a notice of new vulnerabilities, we should do the same scan as we do during the development process every day. If the code is hosted on GitHub, and the code is written in one of the supported languages, continuous dependency scanning is very easy. GitHub will run it automatically on public repositories, and it can be manually enabled for private repositories. Read more about GitHub vulnerability scanning here.

With docker and other container systems, the system tools and other dependencies inside the containers are our responsibility. They will not get automatically patched as in a normal OS. This is why it is just as important to scan your containers, because the application is just as secure as the least secure component.

If you are using Docker Hub, they have created a scan you can add to your images, and you can read more about it here. Other alternatives are Anchor, and an open source alternative made by CoreOS which is named Clair.

Most of the tools suggested here overlap with each other, and you should test them and see which works for you. The most important lesson from this post, is that you cannot know if your software or its dependencies are secure, and it is your responsibility to make it as secure as possible.