Cloudsmith Supports OpenSSF's Efforts to Secure OSS

First published in March 2022 and updated in September 2022

As part of our mission to make it simple to secure software at scale through Continuous Packaging, Cloudsmith is proud to be an Open Source Security Foundation (OpenSSF) member. The OpenSSF-aligned Alpha-Omega Project recently announced over $1.5M in Grants for securing critical open source projects and developing the New Omega Analysis Toolchain.

OpenSSF is a cross-industry forum for a collaborative effort to improve security in open source software (OSS). One software pipeline's output is another's dependency- we are all splashing around in each other's supply chains. To truly secure software supply chains, a coordinated effort is needed from the whole software community, with OSS as the foundation. OpenSSF is the tide that raises all boats for software security.

In this article, we’ll discuss:

• Open source and the maintainers that create it
• Threats specific to open source software
• OpenSSF and their work to secure the supply chain
• Cloudsmith's integrations with OpenSSF projects with support for SBOMs and Sigstore’s Cosign.

Open Source Rocks

“Open source is the foundation on which all software is built,” said Brian Behlendorf, executive director at OpenSSF.

OSS enables faster, cleaner code and promotes code reuse. The benefits of OSS are overwhelming - this is why over 80% of software contains OSS.

Usage is governed by OSS licenses - if the maintainers use permissive licenses like MIT you can more or less do anything with the software as long as you include the original copyright and license notice in the copy of the software.

Who creates all this beautiful free software? OSS maintainers, of course. OSS maintainers are often volunteers who have donated their time and expertise to maintain or contribute to open source projects. Everybody has busy lives, including OSS maintainers, but they choose to share their expertise with the world.

Why do Maintainers contribute to OSS? Well, why does anyone volunteer for clubs, charities, or community projects? They may have a passion for a project, have a friend that pulled them in, feel a responsibility towards a project, want to learn, have used a project in work, or maybe they enjoy the community aspect of OSS.

These maintainers drive innovation and are a positive force in the world.

Software Supply Chain Attacks in OSS

OSS comes with clear security benefits -  Linus's law contends that "given enough eyeballs, all bugs are shallow," promoting the idea that transparency advances software security over closed source security through obscurity.

Proprietary software is not more secure than OSS; but attackers target vulnerabilities in OSS as they know they can maximize their impact and reach many organizations with the same vulnerability.

There are other reasons why vulnerabilities exist in OSS:

• Maintainers may not be resourced to fix vulnerabilities.
• Consumers of OSS often don’t know all the packages their software uses, especially if it is a dependency of a dependency.
• Developers don’t have tools to inform them of vulnerabilities in their OSS dependencies or verify their OSS is trustworthy.
• Patching vulnerabilities in OSS dependencies may not be a priority for Development teams.

Let’s look at some recent threats specific to OSS and how they fit into the supply chain.

Critical security vulnerabilities in legacy software

The persistence of legacy software in the open source space is a major problem. Is it reasonable to expect maintainers to add features, fix issues, update docs, perform code reviews, reply to inquiries, etc., in a timely manner? Is it proper or realistic to expect this from people doing this for free?

Easily exploitable vulnerabilities that exist in commonly used open source software (OSS) are likely to be a threat for years, even if the maintainers fix them. Research from 2020 exposed that a vulnerability called Heartbleed is still exploitable even though a patch was released promptly in 2014. I covered the impact of a critical vulnerability called Log4Shell in a previous blog, found in an OSS logging package called Log4J. Some companies are still looking for Log4J packages vulnerable to the Log4Shell vulnerability, 9 months after the event. Developers that consume OSS can help mitigate against critical vulnerabilities by updating dependencies to the latest. But more than that, we need to establish a model where maintainers are supported to ‘fund the mundane,’ which Dr. Trey Herr, Director of Cyber Statecraft, testified to before the United States Senate Committee held in response to the Log4Shell Vulnerability.

Public repository based attacks

Languages with community-based package management, e.g., NPM and PyPI, make publishing and consuming packages easy. One downside to that, though, is that hackers can also easily publish malicious packages to these repositories with the goal of tricking developers into installing the wrong package.

Typosquatting

Typosquatting is the process of bad actors uploading compromised packages named similar to popular, existing packages. If the developer makes a typo in the package name, the maliciously named package is then downloaded and installed instead. This type of attack, called typosquatting, is tough to detect and can lead to malware execution.

Public repositories can help combat this by removing packages that are likely to be malware and putting in place a standardized naming schema for packages.

Dependency Confusion

Alex Birsan, a security researcher, revealed that over 35 major companies were vulnerable to the injection of malicious packages via public sources into their software supply chains. The Dependency Confusion Attack or Package Namesquatting Attack can occur when attackers find out or guess package names that should only lie in your organization's private repository. This attack was rated top in portswigger’s annual web hacking list by security professionals.

Maintainer-based threats - hijacked, abandoned, or otherwise

Hijacked Maintainer accounts, projects with vulnerabilities, abandoned projects, or - very rarely - a Maintainer intentionally introducing bugs are other types of threats. These maintainer-based threats are more likely to happen in projects that have one or very few maintainers, which are very common for public repositories like NPM and PyPI.

Hijacked

On the 23rd of October, crypto-mining, password-stealing malware was found in a popular npm package named ua-parser-js. The hijacked package containing malware was the result of a maintainer account takeover.

Public repositories can help by introducing two-factor authentication (2FA) or even enforcing 2FA for popular projects - NPM has recently enforced 2FA for the top 100 NPM maintainers. Developers can mitigate against this risk by pinning their builds.

Abandoned

Open source projects get abandoned all the time. The original maintainer may move on or no longer have time, and there is nobody else to step in. These abandoned projects pose a security risk as the vulnerabilities won’t get patched.

WordPress and Jenkins have a way for Developers to find and adopt an abandoned project. Working groups in OpenSSF, the NPM maintenance group, and others are working to identify critical OSS projects and keep them up to date. Before adding a new dependency to your project, check at least two things on Github - when was the last update, and what is the number of active contributors. After that, knowing what dependencies you use in your software is key to understanding if an inactive and potentially insecure project in your codebase.

Rogue

Although very rare, it is not unheard of for maintainers to intentionally introduce bugs or delete code in an update for political or other reasons.

On March 8th, the popular npm package 'node-ipc' was sabotaged by it's maintainer to protest the ongoing war on Ukraine. The developer and maintainer Brandon Novaki Miller released an update to 'node-ipc' to npm and GitHub that sent peace messages to all users and seemingly deleted files for users based in Russia and Belarus.

Colors and Faker NPM packages were corrupted by their Maintainer, Mark Squires. Mark intentionally introduced an infinite loop that broke thousands of projects that depend on 'colors' and 'faker' partly to protest Fortune 500 companies using OSS for free, and partly to highlight his political interests. Initially, Mark was locked out of his Github accounts but eventually allowed to take down his popular faker package legitimately.

Another incident occurred in 2016 on npm when Azer Koçulu, removed over 250 of his modules from NPM after a disagreement.

Again this highlighted the risk of using OSS packages. Developers can mitigate against this by pinning their builds and staying away from adding dependencies that have a single contributor, which is most exposed to security risks.

Open Source Security Foundation (OpenSSF)

To address the security problems with OSS highlighted in the last section, we need:

• To support maintainers, especially of commonly used open source projects.
• Improved security policies for public repositories that host OSS, including promoting 2FA for its maintainers and funding public repositories to fund support for 2FA resets.
• Removal or tagging of malicious, troll, and abandoned projects.
• Automated tooling, including tools to check what OSS is in your code, what vulnerabilities are present, prove that your build wasn’t tampered with, and tools to update code to fix security vulnerabilities.
• The software community needs to adopt tooling and security practices that improve security in their development process.

OpenSSF was set up to address these problems with OSS security and collaborate with all the stakeholders, including Maintainers, Tech companies, Public Repositories, DevOps community, Security Engineers, Vulnerability Database Maintainers, and more. Having a single entity interested in all the overlapping areas in OSS software security and listening to the roadblocks involved in adopting tools is the only way to make a significant impact.

OpenSSF outlines that securing OSS supply chains requires a combination of automated tooling, best practices, education, and collaboration. Some of their projects include:

1. 10 Point mobilization Plan

The Linux Foundation and OpenSSF gathered with representable from Big Tech along with leaders and experts from key U.S. federal agencies, in May 2022, to improve the resiliency and security of open source software.

A 10 point mobilization plan was launched with $150 million of funding over two years. The 10 streams include:
- Security Education
- Risk Assessment
- Digital Signatures
- Memory Safety
- Incident Response
- Better Scanning
- Code Audits
- Data Sharing
- SBOMs Everywhere
- Improved Software Supply Chains

Projects include:
Enabling the OpenSSF to fund work on the SPDX Python library as part of the SBOMs everywhere stream.

2. Sigstore

Sigstore is an OpenSSF project that developers, software maintainers, package managers, and security experts can use for signing, verifying, and protecting OSS. Sigstore combines OSS like Fulcio, Cosign, and Rekor to handle digital signing, verification, and provenance checking, making it safer to distribute and use OSS. Its goal is to remove the effort, time, and risk of error that comes with more traditional ways of signing.

3. Software Bill of Materials (SBOM)

The Software Bill of Materials (SBOM) lists all components, including licenses and dependencies contained in a software product and other data, including checksums. SBOMs can be used to identify all your software components and improve supply chain security. President Biden issued an executive order requiring an SBOM from vendors that provide software to the federal government.

OpenSSF has been involved in creating educational materials, conducting surveys, and developing tools and frameworks to help users generate, sign and scan SBOMs in an automated way. The SBOM tools and projects around SBOMs include SLSA, Sigstore, gitbom.

The 1st effort of the SBOM Everywhere project was to create a plan that enabled the OpenSSF to fund work on the SPDX Python library & work has started this month https://hubs.la/Q01mnwts0

4. Alpha Omega Project

The Alpha Omega Project was announced in February and is intended “to improve software supply chain security for OSS projects through direct engagement of software security experts and automated security testing.” Microsoft and Google have supported this project with an initial investment of $5 million, which has been topped up by $1.5M this September. The projects they fund include:

• A $460K grant for the Rust Foundation to sponsor critical security work.
• The Omega Analysis Toolchain, which orchestrates over 20 different security analyzers to identify critical security vulnerabilities in open source packages.
• $800,000 in funding split equally among the Python Software Foundation (PSF) and the Eclipse Foundation to fund critical security roles.
• The Secure Open Source Rewards pilot program will be managed by the Alpha-Omega Project.
• A $300K grant for Node.js to improve security release process, security fixes, developing a security and threat model for Node.jsand adding automated vulnerability to the Node.js CI

5. The Great MFA Distribution Project

The Great MFA Distribution Project is putting hardware multi-factor authentication (MFA) tokens into the hands of open source software (OSS) developers and providing them simple ways to integrate them into their projects’ daily workflows. These tokens are provided through the generous donation of multi-factor authentication tokens from OpenSSF members GitHub and Google.

At the end of 2021, the WG helped distribute 102 Yubikey and 65 Titan keys donated by GitHub and Google to help OSS maintainers protect their identities using 2FA

6. Scorecards

Scorecard is a OpenSSF project that allows you to run automated checks to review the security of OSS projects. This helps users fix security vulnerabilities and helps consumers of OSS decide their OSS dependencies are safe.

7. SLSA

Supply chain Levels for Software Artifacts, or SLSA is a framework for improving and hardening software supply chains. SLSA outlines four compliance levels of increasing assurance in your build integrity. At each stage of SLSA you are reducing the risk of tampering to your supply chain. SLSA brings practical measurable ways to harden the security of your development process.

8. Securing Critical Projects

A big focus for OpenSSF is identifying critical projects. Once identified, they can help allocate resources to secure these critical open source projects. Number 1 on the criticality list is Node. When projects are identified they can then help inform other projects like the Project Alpha-Omega and the Great MFA Project.

9. Working Groups

OpenSSF has working groups on best practices, security tooling, vulnerability disclosures, identifying critical projects, and others. OpenSSF welcomes anyone to join their open discussions - you do not have to be a member of OpenSSF. They are very transparent with their activities using public repositories, advertising meetings to the public, and Slack channels.

OpenSSF’s transparency and open-door policy is a great way to ensure as many stakeholders as possible are involved with OpenSSF’s projects. Having as many stakeholders interested and involved is an excellent way to encourage adopting the best security practices and tools.

Cloudsmith and OpenSSF

Cloudsmith is committed to providing the tools our customers need to secure their software supply chains. We help developers and organizations today by letting them isolate their software from public OSS feeds, extract and surface information on packages and their dependencies, and control and visualize all that information in a central location.

Getting to a place where software supply chains are secure end-to-end will take a lot of work. Securing the software supply chain is a hearts and minds operation - the best tools and practices need to be identified, and those tools need to be adopted into the development process.

The key to getting there will be developing and identifying tooling, standards and frameworks that are easy and, therefore widely, adopted. That’s why Cloudsmith are aligning with OpenSSF and their initiatives. Cloudsmith has integrated with Sigstores cosign for signing images and hosting SBOMS:

• Cosign
  Cosign, part of Sigstore, aims to make signatures invisible architecture. Cloudsmith users can use Cosign as a method for signing containers.
• SBOMs
  You can host your SBOM alongside your image in Cloudsmith using sigstore/cosign tooling.

Cloudsmith is proud to be a member of the Open Source Security Foundation and plans on integrating with OSSF projects that will help our customers secure their OSS dependencies and thus secure their software supply chain.

Liked this article? Don\'t be selfish (:-), share with others:   Tweet