Developers interested in gauging the security of the open source components have an abundant number of choices, but still have to choose to use the information to audit the components used in their applications, experts say.
On April 11, Google announced its deps.dev API service, which includes security metadata that covers more than 5 million components across five software ecosystems, including the main open source repositories for Go, Java, Python, JavaScript, and Rust. The data is both accessible through the company’s deps.dev website and a dataset that can be queried through a new API.
Developers can use the information to help choose packages, integrated development environments (IDEs) could offer security metrics as a developer works, and application-security tool makers could add the information to the list of sources they currently use to offer verdicts on the security and maintainability of open source software components, says Nicky Ringland, product manager for Google’s Open Source Security Team.
“It could also mean looking at reporting after the fact … and perhaps discovering some dependency challenges that they need to address,” she says. “Ultimately, being able to check a potentially very large set of dependencies across multiple language ecosystems for security or licensing issues, automated and at scale … is a powerful tool that we hope will benefit the whole ecosystem.”
The Google deps.dev service’s release comes as software developers, application security firms, and the US government work to find ways to improve the security of the open source software ecosystem. The exploitation of vulnerabilities in the Log4J logging package for Java — which is expected to be an “endemic vulnerability,” according to the US Department of Homeland Security’s Cyber Safety Review Board (CSRB) — underscores the importance of not only minimizing vulnerabilities in open source packages, but also eliminating the use of vulnerable packages.
A variety of efforts is already underway to give open source projects more tools to improve security and communicate their own dependencies, but developers make security a priority and use information to know which components to download, says Brian Fox, co-founder and chief technology officer of software security firm Sonatype. The firm discovered that when a developer “consumes” a software component that has a vulnerability, 96% of the time, a fix was already available.
“In other words, the problem is not really about our open source projects doing a good job; the Log4J team turned a patch over Thanksgiving weekend — in days, right — probably faster than most companies would have been able to do the same for a commercial project,” he says. “We need to do a better job. Organizations that are consuming open source are doing a terrible job of making these decisions.”
A Feast of Dependency Data
Google’s deps.dev service adds another source for developers to search for information on open source components, but it is far from the only one. Sonatype revamped its OSS Index in 2018, modernizing the service to provide access to security and maintenance data on millions of software projects from 14 different ecosystems, such as the RubyGems package system for Ruby and the RPM Package Manager for Linux, in addition to the five covered by Google.
Other services, such as OpenText’s Debricked, also offer a view into their own dependency datasets, tagging the projects and offering measures of popularity, contributor activity, and security.
The data should allow any developer to make better decisions, but also give toolmakers another source of data to improve their guidance for software programmers, says Google’s Ringland.
“Our intent for the API is that it is usable for anything from quick one-off scripts to complex tooling like editor plugins or build system integrations,” she says. “We see real appetite for this data in everything from IDEs to CI/CD systems to audit dashboards, and are excited to be bringing critical security information to developers, CISOs, open source maintainers, and more.”
Endor Labs, which focuses on helping developers make better choices using software dependency data, already uses deps.dev as one of its sources, but lauded the more streamlined database access. Endor Labs pairs such data with extensive analysis to minimize false positives, such as when an application uses an open source library but not the vulnerable functions in that library.
The company also intends to make its own dependency information more accessible through DroidGPT, a ChatGPT-based service making risk data searchable in a conversational way, says Varun Badhwar, CEO and co-founder of Endor Labs. The goal is to reduce the amount of work to select and manage open source dependencies, because selecting the wrong ones can create a great deal of future work — otherwise known as technical debt.
“Technical debt is typically created when developers are asked to constantly patch and fix vulnerabilities in open source code, despite most of that code not actually being in use,” Badhwar says. “The way to reduce technical debt with OSS is by selecting better dependencies, and prioritizing risk that actually matters.”
SBOM + Dependency Data = Better Software Security
The dependency data will really start to be useful as developers and toolmakers begin combining the data with the software bill-of-materials (SBOMs) that are increasingly being created by development tools.
SBOMs can help organizations and development teams by illuminating their use of open source libraries, such as whether they are using five different encryption libraries or a dozen loggers, says Sonatype’s Fox.
“They have that shock moment when they realize they’re using a dozen, 15 different components that all do the same thing,” Fox says. By combining SBOMs and security data, “I can look at the whole entirety of my portfolio and start reasoning about it.”
Adding security data to that allows companies to make better choices on how to streamline their software selection, and tools — such as the publicly available Security Scorecard — or commercial services can help, Endor Labs’ Badhwar says.
“As the effort starts to span multiple teams and requires much engineering effort, and as they look to start reducing development effort on false positive security alerts, companies will find better ROI with [these] tools,” he says.
