Snyk Report Finds Decline in Open Source Vulnerabilities

Snyk, a provider of tools for discovering and remediating vulnerabilities in open source code, today published a report that finds the number of new vulnerabilities discovered in open source software packages has declined 20% on a year-over-year basis. However, the bulk of the vulnerabilities being discovered are considered to be high severity, the report finds.

Alyssa Miller, application security advocate for Snyk, said the decline represents a significant improvement as developers become more conscious of cybersecurity issues. As long as humans write code there will always be security issues; however, Miller said the latest report suggests improvements in open source security are likely to continue as more developers embed vulnerability scanning tools within their application development tools.

Those tools enable developers to discover vulnerabilities in their code long before they ever find their way into a production environment, she noted.

The Snyk report is based on a survey of 500 developers, security practitioners and IT operations staff and scans run by Snyk on open source software packages. It finds the top vulnerability currently impacting scanned projects is prototype pollution, which results in objects in JavaScript applications being modified, was found in nearly 27% of all the projects Snyk surveyed.

Better-known vulnerabilities, such as cross-site scripting attacks, are still being reported in high numbers, but Snyk reported the number of projects actually being impacted by this class of vulnerabilities is fairly low. These threats appear to be getting caught and remediated much earlier than many lesser-known vulnerabilities, said Miller.

Want to learn more? Tune in Tuesday, June 30, at 11 a.m. Eastern for The State of Open Source Security in DevSecOps Pipelines: A Panel Discussion, a DevOps.com webinar hosted by Snyk

The report notes the bulk of the vulnerabilities discovered continue to involve indirect dependencies (70%) within packages built using tools such as Node Package Manager (86%), Ruby (81%) and Java (74%). The survey also finds 60% of organizations do not fully inventory the dependency trees in their software.

Despite the progress being made, Miller said it’s clear much work needs to be done. For example, the survey finds more than 30% do not review Kubernetes manifests for insecure configurations. Requirements for security-related resource controls in Kubernetes are also not widely implemented, according to the survey. Many container images labeled as final contain large numbers of known vulnerabilities—the 14.3 Node image had 642 known vulnerabilities, for example.

In addition, 44% of the participants indicated that they are currently using Kubernetes to orchestrate their containers. Many respondents who said they use Kubernetes also employ Helm to package applications (40%). According to the report, 68% of stable Helm Charts contain an image with a high severity vulnerability.

Ironically, Miller noted many of the same vulnerability issues that have derailed many “golden image” initiatives in the past decade appear to be manifesting themselves again in the age of containers.

Finally, the survey finds 57% of respondents have implemented static code analysis tools (SAST), followed by employing security test cases during quality assurance (28%); dynamic application security testing (DAST) (20%); software composition analysis (19%); and threat modeling (19%).

Despite that relatively low reliance on security tools in the development process, it’s clear progress is being made as DevOps teams and cybersecurity teams collaborate more closely. As more security tools are incorporated into the DevOps pipeline, application security should begin to improve at even faster rates.