Securing open source software: Whose job is it, anyway? – Source: go.theregister.com

The US government and some of the largest open source foundations and package repositories have announced a series of initiatives intended to improve software supply-chain security, while also repeating calls for developers to increase support for such efforts.

On the government side of things, this includes a voluntary threat intelligence sharing program between the Feds and open source software developers and operators, which the US Cybersecurity and Infrastructure Security Agency (CISA) will lead.

“We want to help foster real-time collaboration around security incidents,” CISA director Jen Easterly explained in a keynote address at the agency’s Open Source Software Security Summit this week.

Easterly used her speech to announce new public-private collaborations.

“We recognize that working with this community will be a little different than how we typically work with companies, especially given the unique international complexities at play due to open source’s global nature,” she noted, adding “As such, your participation and feedback will be critical to ensuring this initiative is a success.”

In addition to the threat-sharing initiative, five major open source software orgs pledged a series of steps to improve safety in their respective projects.

The Rust Foundation will develop public key infrastructure for the crates.io package repository for mirroring and binary signing. The organization also published a threat model for crates.io and tools to identify malicious packages.

Additionally, the Python Software Foundation will expand its Python Package Index (PyPI) “Trusted Publishing” effort to additional providers beyond GitHub. Trusted Publishing allows PyPI maintainers to verify their identity via the OpenID Connect (OIDC) standard, which uses short-lived identity tokens instead of long-term credentials to guarantee identity.

When it launched in April 2023, Trusted Publishing supported GitHub. At the summit, the Python Software Foundation revealed it will soon support GitLab, Google Cloud and ActiveState.

It’s also working to provide an API and related tools for reporting and mitigating malware in PyPI. Plus, it’s finalizing index support for digital attestations. This will enable uploading and distributing digitally signed attestations and metadata used to verify these attestations on a Python package repository – like PyPI.

• Pushers of insecure software in Biden’s crosshairs
• US cybersecurity chief: Software makers shouldn’t lawyer their way out of security responsibilities
• Feeling VEXed by software supply chain security? You’re not alone
• Homeland Security warns: Expect Log4j risks for ‘a decade or longer’

Packagist and Composer recently added vulnerability database scanning and other measures to prevent attackers from taking over packages without authorization. The projects’ maintainers will also complete a security audit of existing codebases this year.

Maven Central, the largest open source repository for Java and JVM languages – which is maintained by Sonatype – is this year transitioning publishers to a new publishing portal with better repository security. This, we’re told, includes planned support for multi-factor authentication (MFA).

Sonatype is also working on key security including Sigstore implementation, and it’s evaluating Trusted Publishing (like PyPI has in place now), and access control on namespaces.

And while it’s not exactly new, in 2022 NPM – which bills itself as the world’s largest software registry – began requiring maintainers of high-impact projects to use MFA. Last year, NPM developed tools that allow maintainers to automatically generate package provenance and Software Bill of Materials (SBOMs), which allow anyone using the open source packages to trace and verify code dependencies.

Lessons learned from Log4j

Securing software, with a particular focus on open source software (OSS), has been a key focus for the Biden administration since serious vulnerabilities in the open source Java-based Log4j logging library were discovered in late 2021.

“We at CISA are particularly focused on OSS security because, as everyone here knows, the vast majority of our critical infrastructure relies on open source software,” Easterly declared in her keynote.

“And while the Log4Shell vulnerability might have been a big wakeup call for many in government, it demonstrated what this community has known and warned about for years: due to its widespread deployment, the exploitation of OSS vulnerabilities becomes more impactful,” she added.

In addition to holding software developers liable for selling vulnerable products, Easterly has also repeatedly called on vendors to support open source software security – either via money or dedicated developers to help maintain and secure the open source code that ends up in their commercial projects.

Software manufacturers’ role

Easterly repeated this call to action at this week’s Summit, citing a Harvard study [PDF] that estimates open source software has generated more than $8 trillion dollars in value globally.

“I do have one ask of all the software manufacturers,” Easterly noted – though it ended up being technically two asks.

“We need companies to be both responsible consumers of and sustainable contributors to the open software they use,” she continued. “This means properly vetting their open source software and contributing back – either through financial support or through contributions of employee time – to help ensure that everyone who relies on that OSS can benefit from increased quality and security.”

And while the Feds’ support for open source software is important, patching is even more so, Mike McGuire, a senior software manager at Synopsys, told The Register.

“No matter what is done because of these exercises, no commercial application will be made any more secure if development organizations don’t invest more in managing the open source that they leverage,” McGuire warned.

Synopsys recently published its 2024 open source security report, and McGuire pointed to its findings: “When over 70 percent of commercial applications have a high-risk open source vulnerability, and the average age of all vulnerabilities is 2.8 years old, it’s clear that the biggest concern is not with the open source community, but with the organizations failing to keep up to date with the varying security patching work that the community is doing.” ®