OpenSSF

In today’s dynamic technological landscape, open source software (OSS) holds a crucial position. An average of 77%–90% of any given piece of modern software is OSS. Recognizing its significance, the US Cybersecurity and Infrastructure Security Agency (CISA) recently concluded a two-day Open Source Software (OSS) Security Summit in March 2024, gathering OSS community leaders, government agencies, and industry partners. This summit marked notable progress in fortifying the security of open source ecosystems, as CISA announced key actions aimed at securing this critical foundation. Emphasizing a collaborative approach, CISA underscored the importance of addressing OSS security concerns in partnership with open source communities. This collaborative spirit extends to the Open Source Security Foundation (OpenSSF), highlighting the collective commitment to ensuring the resilience and security of OSS.

CISA, in collaboration with the open source community, unveiled key actions, including close work with package repositories to adopt the Principles for Package Repository Security framework developed by CISA and the OpenSSF’s Securing Software Repositories Working Group. OSS is often retrieved through package repositories, so securing package repositories can substantially improve security for all OSS users.

About Principles of Package Repository Security 

The Principles for Package Repository Security framework version 0.1 outlines security maturity in four feature categories: authentication, authorization, general capabilities, and command-line interface tooling. Each category defines four levels of security maturity: 0 (very little security maturity), 1 (basic), 2 (moderate), and 3 (advanced security). At this time level 3 is considered more aspirational, especially for smaller package repositories.

​​The authentication category only applies to package repositories that have user accounts. It covers criteria for enabling users to prove who they are. Level 1 includes supporting basic security features like multi-factor authentication (MFA), while level 3 is requires MFA for all maintainers.

The authorization category only applies to package repositories that have user accounts and accept built packages. To achieve level 1, a package repository must allow maintainers to provision API keys scoped to specific packages (so they can maintain packages via automated workflows without needing to provide their account password).

The general capabilities apply to all package repositories. Level 1 has two key requirements: a vulnerability disclosure policy (allowing security researchers to identify and report vulnerabilities affecting the package repository) and taking steps to prevent typosquatting attacks (one of the most common attacks against users of package repositories).

The CLI Tooling capabilities focus on the CLI tools used to access the package repository. Level 1 requires that the CLI allows installing dependencies that are pinned based on hash, version, etc. This provides a countermeasure against dependency confusion attacks (the other most common attack against users of package repositories).

This framework is intended to offer a set of best practices to which package repositories should strive to adhere. Some of the most widely-used package repositories shared the actions they are taking in support of the Principles for Package Repository Security framework:

Package Manager’s Forum

The summit spent time in breakout groups determining how to further improve thislist of principles and how to help implement them widely throughout the many package repository systems. The OpenSSF continues to support the evolution and development of the Package Repository Security Principles, with a call for attendees of the summit or other interested parties to submit comments and pull requests for the next version of the principles.  Additionally, the OpenSSF looks to continue the conversation around the development and implementation of these principles through the ongoing work of the working groups with a proposed event that brings together many of the key participants and implementers of these principles with the SOSS Package Manager’s Forum later this year.

Tabletop Exercise (TTX) 

The second day CISA’s team conducted a Cyber Tabletop Exercise (TTX) focused on the Open Source ecosystem and package managers with the participants. Groups discussed how to address a challenging scenario where a critical infrastructure is impacted by a vulnerability in an open source build toolchain, where mitigations would require loss of functionality and OSS maintainers are targeted.

A number of challenges were identified and possible solutions were identified, for example:

1. OSS maintainers, especially for larger projects, often already have mechanisms in place for reporting vulnerabilities. In many cases, however, end user organizations don’t know how to identify how to report vulnerabilities.
2. While there are differences in structure, projects that are prepared to receive vulnerability reports generally perform triage (to determine if a report is a vulnerability) and jurisdiction checks (determine if the vulnerability is reported to the correct project).
3. Typically vulnerabilities can be fixed without loss of functionality, and projects are often less prepared to deal with the rarer case where functionality must be removed. There were discussions about how to better handle this case.

Coming up on April 15th, the OpenSSF will be conducting a similar Tabletop exercise at the SOSS Community Day in Seattle.  The TTX will be a 90-minute interactive session that occurs at the end of SOSS Community Day NA’s regular programming (after Track 1 and 2), we’ll stay in the same room as Track 1 to hear from 20 active participants on the TTX panel. 

The TTX session is open to all SOSS Community Day attendees as audience observers. Questions from the audience during the session can be raised via Slido. The panel will consist of panelists of diverse backgrounds from both public and private sectors. Participation for TTX speakers is now available and applications will be accepted until March 8, 2024.

Other Activities

CISA has been championing that software and systems be secure by design, including being secure by default and increased use of memory safe languages. We in the OpenSSF have also been encouraging the development of software that is secure by design. This includes a range of approaches, including education on how to develop secure software and the OpenSSF Memory Safety Special Interest Group (SIG). We look forward to working with CISA and other government agencies worldwide to work together to improve the software we all depend on.