By Jacques Chester, Shopify and Brandon Lum, Google
Each software repository faces a challenging task to protect producers and consumers of open-source software. They must defend against a variety of threats, juggling a complex menu of options to harden their systems and procedures against attackers.
The OpenSSF Securing Software Repository Working Group (SSR WG) last year surveyed the maintainers of 11 leading software repositories to learn about their current security posture and what they want to do in the future. The results of this survey are now available, both in raw CSV and with a summary of findings.
The survey covered integrity (for example, what signing mechanisms do repositories support?), typos and dependency confusion, protecting the repository servers and more.
Package manager maintainers (and/or reputable sources) from 11 different package manager ecosystems responded to the survey including PyPI (Python), Gradle (Java), Basalt (Bash), Opam (OCaml), RubyGems (Ruby), npm (javascript), Pkg.go.dev (Go), Cargo (Rust), Pub.dev (Dart), Apache Maven (Java), and Maven Central (Java).
Findings from the survey included:
- All are interested in security and in improving their security against attackers.
- Most support is still around developer-owned keys for signing (with PGP being the most supported signature type), while some ecosystems do not support signing yet – but there is interest/plans.
- 45.5% of package managers surveyed do not require and do not plan on having DNS verification proof when reserving/exercising a domain/namespace or domain name attribute of a package, which could lead to impersonation of organizations/entities. A method to reduce the cost of protecting against this threat or education of the seriousness of this threat is needed.
- Most ecosystems don’t see the responsibility of finding malware in the packages as their responsibility. They often view their task as providing the software requested, not as gatekeepers to that software. There appear to be many reasons, e.g., many repositories have a large number of packages, it is challenging to identify malware, there are concerns about false positives, and most don’t have resources to do this to a significant degree. However, they provide the ability to flag and handle malware in releases when it happens and they are alerted to it.
- Most ecosystems are not currently performing any security testing against code/infrastructure. However, all of them are interested or have it planned. These ecosystems could be funded for security testing.
- Generally, there is interest in MFA hardware token security, which is a positive sign. Many support some form of MFA. There are 2 ecosystems that currently have no plans on requiring MFA. Further investigation on why would be helpful.
- When consuming a package, it’s helpful to allow users to specify policies on which packages they want to use. For example, all packages must be signed, must have a certain age, etc. There are several implementations that help provide the ability to create policy on keys/hashes and to check for known vulnerabilities. A significant number of ecosystems currently do not have mechanisms to define and enforce these policies but are interested in adding them.
- 7 of 11 ecosystems do not currently have support for generating SBOM but are interested or planning to. Additional tooling support is required and could be a place where the OpenSSF SBOM Everywhere Special Interest Group can be helpful.
- In general, most ecosystems allow verification of dependency immutability. However, there are 3 ecosystems that do not have this yet. Further investigation on why would be helpful.
Additional takeaways are available on the Securing Software Repositories Work Group GitHub page. The goal of this exercise was to understand overall security priorities, and to cross-pollinate ideas, threat models and designs across the ecosystems. We look forward to community feedback and questions (via our Slack channel #wg_securing_software_repos or by joining our regular calls) and hope to run this survey again next year!