78% of vulnerabilities are found in indirect dependencies, making remediation complex

February 26, 2019 | in Ecosystems, Open Source
| By Liran Tal

Welcome to Snyk’s annual State of Open Source Security report 2019.
This report is split into several posts:

Or download our lovely handcrafted pdf report which contains all of this information and more in one place.

DOWNLOAD THE STATE OF OPEN SOURCE SECURITY REPORT 2019!

Indirect dependencies

It is hard to imagine the days of writing software without any open source dependencies. Managing dependencies for a project is an important task, and requires due diligence to correctly keep track of the libraries you depend upon. After all, the application you are deploying bundles your code as well as your dependencies.

 

Most dependencies in npm, Maven and Ruby are indirect dependencies, requested by the few libraries explicitly defined. Vulnerabilities in indirect dependencies account for 78% of overall vulnerabilities

 

Snyk has scanned over a million snapshot projects and has discovered that vulnerabilities in indirect dependencies account for 78% of overall vulnerabilities. This further amplifies a critical need for clear insight into the dependency tree and the need to be able to correctly highlight nuances of a vulnerable path in order to address these vulnerabilities.

Of course, finding the vulnerabilities in a dependency is just the first step. Being able to precisely determine all the paths through the dependency tree in which the vulnerable dependency can be reached is a more complex issue.

Additionally, being able to suggest the steps to take that will eliminate the vulnerability while preserving the compatibility between dependencies is an even greater and much more interesting challenge.

The direct and indirect dependency split across ecosystems

Risks and impact

 

Only one in three developers can address a high or critical-severity vulnerability in a day or less

 

It shouldn’t come as a surprise to most that in this year’s State of the Octoverse report from GitHub, security is the most popular project integration app category with more than one integration for developers. Here’s a quote from industry analyst Gartner in a recent application security report that covers the necessity for organisations to test for security as early as possible in the application lifecycle.

 

Almost half (43%) of respondents have at least 20 direct dependencies, amplifying the need to monitor for open source vulnerabilities introduced through these libraries

 

The more we use open source software, the more risk we accumulate as we’re including someone else’s code that could potentially contain vulnerabilities now or in the future. Moreover, risk doesn’t solely reflect how secure the code is but also the licensing compliance of code you adopt and whether that code is in violation of the license itself.

 

Enterprises should use SCA tools on a regular basis to audit repositories that contain software assets (such as version control and configuration management systems) to ensure that the software developed and/or used by the enterprise meets security and legal standards, rules and regulations. Application developers should have access to SCA tools to inspect the components they plan to use. — Mark Horvath, Hype Cycle For Application Security 2018, Gartner

Take action

Application composition is complex. As OS maintainers and developers there are actions you can take to improve the security in projects you own and contribute to.

Open source maintainers

As an open source maintainer, you should offer secure releases of your code and provide a communication strategy to those consumers in order to positively impact other projects and applications, ultimately benefiting your own projects as well most likely.

  • Practice secure code review with your peers if possible and follow secure- code best practices. Make security considerations part of your code review checklist and educate those who are reviewing so that they know what they should be looking for.
  • Regularly audit your code base for vulnerabilities, through static and dynamic code analysis, for example, that can be automated into your development workflow and make it easier to catch vulnerabilities before they
    become public.
  • Clearly define a simple process for communication of responsible disclosures, using your own policy or by forwarding to an existing program. To communicate your security awareness consider adopting a SECURITY.MD policy and a project badge that reflects the security health of the project.
  • Implement a shift-left security strategy that provides your team the insight into security issues during development, CI, and even when pull requests are created to eliminate all chances of vulnerable code entering your projects.

Open source developers

As a consumer of open source components, it’s your responsibility to fully understand the direct and indirect dependencies your projects use, including any security flaws that might exist in that dependency tree. Consider adopting the following security guidelines:

  • Regularly audit your code base with a tool that automatically detects vulnerabilities in your third-party dependencies, providing remediation advice to your team and monitoring a project’s dependencies even after it has been deployed.
  • Follow responsible disclosure policies if you are reporting a security vulnerability to make sure you don’t put users in harm’s way. If you are unsure about how to do this, consider disclosing to a security company that work through the disclosure with you, such as Snyk’s responsible disclosure program.
  • Subscribe to the security communication channels of your open source dependencies, if they have them, so you’re aware of any potential vulnerabilities as they are reported.

Continue reading from our key takeaway posts:

DOWNLOAD THE STATE OF OPEN SOURCE SECURITY REPORT 2019!