Open source software is everywhere. Open source packages are used to build mobile apps, ecommerce platforms, artificial intelligence, electric cars, streaming services… you name it. Current estimates say that 70 – 90% of software uses open source.
At companies where developers use open source, innovation is constant and iterations are short. But any third-party code (including open source packages) can introduce security risks, and the more widely used any open source package is, the bigger the impact of a security vulnerability inside that package can be. Developers and companies using open source packages need to truly understand — and know how to mitigate — the risks that come with those packages.
Snyk and the Linux Foundation collaborated in researching the current state of the open source ecosystem. The research focuses on how developers detect and address risk, and on how organizations need to adopt in order to automate and improve the testing of their open source components.
Image Credits: Snyk (opens in a new window)
Despite the increasing popularity of (and habitual reliance on) open source packages, the research revealed that many organizations still don’t have good policies and governance around open source security. It also shows an alarming lack of understanding around how to manage vulnerabilities in open source packages, as well as low confidence in organizations’ security policies. In fact, 27% of medium-to large companies don’t have an established security policy in place.
What are the big risks in open source, and how can companies manage those risks?
1. Understand that dependencies bring complexity
The average project has 49 vulnerabilities spanning 79 direct dependencies.
Open source security becomes a bigger challenge as the software supply chain becomes more complex. Nearly all modern applications are built with components that depend on other components, creating a supply chain that involves hundreds of components and multi-tiered dependencies. The software supply chain is an attractive entry point for malicious actors, because they can take advantage of vulnerabilities in small libraries that are widely used. Remember Log4Shell? It made incoming data that gets logged vulnerable to RCE (remote code execution) attacks. It was a critical weakness inside of a popular open source logging framework — a vulnerability inside of a dependency.
Only 24% of organizations are confident in the security of their direct dependencies. And while 37% of organizations report that dependencies are easy to track, these dependencies are not necessarily in a secure state.
2. Lay the groundwork with security policies
Only 49% of organizations have a security policy that explicitly addresses the development and use of open source packages. This is understandable in smaller organizations, where resources are limited. But our research also showed that 27% of medium-to large companies don’t have an established security policy in place. When you consider how much data each of these companies might be processing, 27% is an alarming statistic.
Of the people surveyed at organizations that don’t have an open source security policy, 30% readily recognize that no one on their team is responsible for addressing open source security. On a positive note, this means that 70% of those surveyed could identify someone at their organization who is, even though they don’t have clearly defined policies for it. This might suggest that even at organizations without a top-down security policy, someone is working as a security champion.
3. Use the right tools and strategies
73% of organizations are searching for best practices to improve their software security. But what does this mean?
To start: as noted above, prioritizing a security policy and (ownership of that policy) is fundamental. Beyond that, organizations need to invest in a diverse set of tools to help them build more secure applications. In addition to SCA (software composition analysis) tools, organizations use other tools depending on their preferences regarding security testing. SAST (static application security testing) tools are in use at 35% of organizations, IaC (infrastructure as code) are in use at 35% of organizations, and web application scanners at 32% of organizations. Each of these solutions provide unique security benefits.
More than half of respondents also expressed interest in obtaining training and certifications for secure software development. This suggests a growing interest in learning how to build reliable open source security practices. It also extends to an interest in encouraging developers to learn best practices and acquire certifications. Fortunately, many resources are available to train development teams on how to think about and enforce good open source security practices. Certification programs are also widely available. For example, the OpenSSF’s course on developing secure software provides both a training course and certification of completion. (The OpenSSF is part of the Linux Foundation.) Snyk also provides a full library of free security education information, designed for developers.
The future of open source security: policy, tools, best practices
Using open source packages safely requires a new way of thinking about developer security that many organizations have not yet adopted.
Every organization needs to have a CISO or a person or team tasked with key security responsibilities. When key CISO capabilities are present and available, an open source security policy will follow. Actionable policies must be put in place and socialized across teams — starting with CISOs and developers, and moving throughout the organization.
The software security tools market extends from source code management through build, package, delivery, and deployment. Organizations on average use 2.8 security tool categories; SCA (software composition analysis) and SAST (static application security testing) tools are the leading tools used to address open source security. Software security must be managed across each step, and accomplishing all of this with just two or three tools isn’t feasible. Organizations should take a closer look at additional security tools and determine where they can add the most value.
Understanding best practices for secure software development was identified by 73% of organizations as a leading way to improve the security of the open source software supply chain. A main reason for the wide interest in best practices is that building secure software involves the entire development lifecycle. At each step in the process, from source code management, build services, and packaging to software delivery and deployment, there are numerous best practices that should be followed. Many courses and certification programs on best practices are available. Organizations that want to strengthen their security posture in the future should take advantage of these.
Open source will only continue to grow. It would be ideal to see more companies in a strong position with open source security by this time next year.