Securing software repositories leads to better OSS security
Malicious software packages are found on public software repositories such as GitHub, PyPI and the npm registry seemingly every day.
Attackers use a number of tricks to fool developers or systems into downloading them, or they simply compromise the package developer’s account and update the package with malware.
Consequently, the security capabilities of public software package repositories plays a crucial factor in securing the open-source software supply chain.
OpenSSF’s efforts to improve open-source software security
Since 2020, the Open Source Security Foundation (OpenSSF) has mounted a number of initiatives to advance the open-source software security agenda:
- The Open Source Software Security Mobilization Plan, to help spur systematic efforts towards better OSS security
- The Alpha-Omega Project, aimed at finding vulnerabilities in open source code and working with project maintainers to get them fixed
- OpenSSF Scorecard, a project to assesses open source projects for security risks via automated checks
- The creation of Malicious Packages repository, a comprehensive database of malicious packages published to open-source package repositories
Most recently, the Foundation has partnered with the Cybersecurity and Infrastructure Security Agency (CISA) to create a framework outlining steps for raising the security maturity level of package repositories.
Securing software repositories
Developed by OpenSSF’s Securing Software Repositories Working Group, the Principles for Package Repository Security define four levels of security maturity.
Repos that achieve Level 3 – the highest one – must:
- Require MFA for all maintainers and phishing-resistant MFA for packages deemed critical
- Support passwordless authentication
- Provision short-lived API tokens via an OpenID Connect (OIDC) token exchange (instead of long-lived API keys)
- Make sure that package repository API tokens are integrated into common third-party secret scanning programs
- Support providing build provenance for packages
- Undergo periodic security reviews of package repository infrastructure
- Publish an event transparency log to enable detection of anomalous behaviors
- Publish advisories for malicious packages using a standardized machine readable format
- Provide CLI tooling that can produce software bills of materials (SBOM), automatically remediate known vulnerabilities in dependencies (by upgrading them), and reduce false positives of identified vulnerabilities by way of static analysis.
But all package management ecosystems should be working towards at least Level 1 (basic security maturity), the framework says.
That level includes things like having an account recovery policy and a vulnerability disclosure policy, offering (stronger) MFA, employing protections against typosquatting attacks, and CLI tooling that allows installing dependencies that are pinned based on hash or version.
“Compromises of widely used open source dependencies can have widespread consequences. Package repositories are at a critical point in the open source ecosystem to help prevent or mitigate such attacks. Even simple actions like having a documented account recovery policy can lead to robust security improvements,” said Jack Cable, Senior Technical Advisor, CISA and Zach Steindler, Principal Engineer, GitHub.
“Through our general framework (…) we hope that package repositories can kickstart or further mature their security improvement roadmap,” they said, but acknowledged that “capabilities must be balanced with resource constraints of package repositories, many of which are operated by nonprofit organizations.”
Read more: