Snyk State of Open Source Security Report Reveals Vulnerabilities Down as Cybersecurity Responsibilities Are More Effectively Shared Across Teams
Snyk, the leader in developer-first security, released its annual State of Open Source Security Report for 2020 . The study found new vulnerabilities in open source packages were down 20% compared to last year suggesting security of open source packages and containers are heading in a positive direction. Well known vulnerabilities, such as cross-site scripting, continue to be reported but aren’t impacting as many projects as they have in previous years. This is further encouraged as organizations start to drive a culture shift that embodies open source and container security as a core responsibility shared and integrated across development, security and operations teams.
This year the report took an even deeper look at vulnerability and ecosystem-level trends that impact the overall security posture of organizations relying on open source libraries. Across the six popular ecosystems the report examined, there were fewer new vulnerabilities reported in 2019 than in 2018 – a promising finding – but there are still significant improvements to strive for with slightly less than two thirds of vulnerabilities still taking more than 20 days to remediate.
While well-known vulnerabilities such as cross site scripting are reported in high numbers, the number of projects they impact are fairly low. These common threats appear to be getting caught and remediated early unlike some lesser known vulnerabilities. For example, the report found certain vulnerabilities were reported in highly popular packages, affecting thousands of projects and thereby increasing the probability of them being exploited by attackers. Based on the 2020 report, the top vulnerability currently impacting scanned projects is prototype pollution in nearly 27% of all projects.
For the first time in the last four years, the Snyk report highlighted a big shift in security mindset as organizations start embracing the core elements of DevSecOps and begin implementing more scalable programs and best practices to ensure shared responsibility. When respondents were asked the multi-answer question about who they felt should be responsible for designing and implementing security controls in their software development, development teams were commonly identified in addition to operations and security teams. This is a much more even spread across the three different teams compared to last year in which less than 25% felt security and operations played a role. However, the fact the responses were all less than 65% still indicates that respondents did not typically identify all three groups as jointly being responsible. While progress has been made, it’s clear there is still a need for a more significant shift towards a shared-responsibility culture.