Blog

As someone who has spent their entire career in open source software (OSS), the Log4Shell scramble (an industry-wide four-alarm-fire to address a serious vulnerability in the Apache Log4j package) is a humbling reminder of just how far we still have to go. OSS is now central to the functioning of modern society, as critical as highway bridges, bank payment platforms, and cell phone networks, and it’s time OSS foundations started to act like it.

Organizations like the Apache Software Foundation, the Linux Foundation, the Python Foundation, and many more, provide legal, infrastructural, marketing and other services for their communities of OSS developers. In many cases the security efforts at these organizations are under-resourced and hamstrung in their ability to set standards and requirements that would mitigate the chances of major vulnerabilities, for fear of scaring off new contributors. Too many organizations have failed to apply raised funds or set process standards to improve their security practices, and have unwisely tilted in favor of quantity over quality of code.

What would “acting like it” look like? Here are a few things that OSS foundations can do to mitigate security risks:

1. Set up an organization-wide security team to receive and triage vulnerability reports, as well as coordinate responses and disclosures to other affected projects and organizations.
2. Perform frequent security scans, through CI tooling, for detecting unknown vulnerabilities in the software and recognizing known vulnerabilities in dependencies.
3. Perform occasional outside security audits of critical code, particularly before new major releases.
4. Require projects to use test frameworks, and ensure high code coverage, so that features without tests are discouraged and underused features are weeded out proactively.
5. Require projects to remove deprecated or vulnerable dependencies. (Some Apache projects are not vulnerable to the Log4j v2 CVE, because they are still shipping with Log4j v1, which has known weaknesses and has not received an update since 2015!)
6. Encourage, and then eventually require, the use of SBOM formats like SPDX to help everyone track dependencies more easily and quickly, so that vulnerabilities are easier to find and fix.
7. Encourage, and then eventually require, maintainers to demonstrate familiarity with the basics of secure software development practices.

Many of these are incorporated into the CII Best Practices badge, one of the first attempts to codify these into an objective comparable metric, and an effort that has now moved to OpenSSF. The OpenSSF has also published a free course for developers on how to develop secure software, and SPDX has recently been published as an ISO standard.

None of the above practices is about paying developers more, or channeling funds directly from users of software to developers. Don’t get me wrong, open source developers and the people who support them should be paid more and appreciated more in general. However, it would be an insult to most maintainers to suggest that if you’d just slipped more money into their pockets they would have written more secure code. At the same time, it’s fair to say a tragedy-of-the-commons hits when every downstream user assumes that these practices are in place, being done and paid for by someone else.

Applying these security practices and providing the resources required to address them is what foundations are increasingly expected to do for their community. Foundations should begin to establish security-related requirements for their hosted and mature projects. They should fundraise from stakeholders the resources required for regular paid audits for their most critical projects, scanning tools and CI for all their projects, and have at least a few paid staff members on a cross-project security team so that time-critical responses aren’t left to individual volunteers. In the long term, foundations should consider providing resources to move critical projects or segments of code to memory-safe languages, or fund bounties for more tests.

The Apache Software Foundation seems to have much of this right, let’s be clear. Despite being notified just before the Thanksgiving holiday, their volunteer security team worked with the Log4j maintainers and responded quickly. Log4j also has almost 8000 passing tests in its CI pipeline, but even all that testing didn’t catch the way this vulnerability could be exploited. And in general, Apache projects are not required to have test coverage at all, let alone run the kind of SAST security scans or host third party audits that might have caught this.

Many other foundations, including those hosted at the Linux Foundation, also struggle to do all this – this is not easy to push through the laissez-faire philosophy that many foundations have regarding code quality, and third-party code audits and tests don’t come cheap. But for the sake of sustainability, reducing the impact on the broader community, and being more resilient, we have got to do better. And we’ve got to do this together, as a crisis of confidence in OSS affects us all.

This is where OpenSSF comes in, and what pulled me to the project in the first place. In the new year you’ll see us announce a set of new initiatives that build on the work we’ve been doing to “raise the floor” for security in the open source community. The only way we do this effectively is to develop tools, guidance, and standards that make adoption by the open source community encouraged and practical rather than burdensome or bureaucratic. We will be working with and making grants to other open source projects and foundations to help them improve their security game. If you want to stay close to what we’re doing, follow us on Twitter or get involved in other ways. For a taste of where we’ve been to date, read our segment in the Linux Foundation Annual Report, or watch our most recent Town Hall.

Hoping for a 2022 with fewer four alarm fires,

Brian

Brian Behlendorf is General Manager of the Linux Foundation’s Open Source Security Foundation (OpenSSF). He was a founding member of the Apache Group, which later became the Apache Software Foundation, and served as president of the foundation for three years.

The Open Source Security Foundation (OpenSSF) Developer Best Practices Working Group has undertaken a project to improve the overall security and integrity of critical open source software projects and their supply chains.  Dubbed “The Great MFA Distribution Project”, the group 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.

Supply chain integrity is more important and prescient than ever.  Supply chain attacks have increased at rates that parallel the explosive growth of open source software development techniques and code.  The OpenSSF was formed in 2020 from a broad coalition of industry and open source security experts focusing on different aspects of improving the overall quality and security of OSS through deep collaboration with communities.  As the foundation grows and evolves, so does the scope of projects the group collaborates on.  The OpenSSF’s Great MFA Distribution Project is one of several active projects focused on securing OSS.

Through the use of MFA tokens a developer, contributor, or maintainer on an OSS project can add extra assurance of their identity as they engage with code and tooling within their projects instead of just using a username/password combination.  For example, these tokens will eliminate the problem of attackers using stolen passwords to “take over” OSS developer accounts to release subverted source code or packages. This helps improve the trustworthiness of this software for downstream consumers, strengthening the chain of custody and trustworthiness.

The Great MFA Distribution project has begun reaching out to a list of identified critical OSS projects and distribution of tokens will be underway during December.  The MFA Distribution project offers no-charge hardware tokens to OSS project developers and maintainers along with simple documentation on how these tools can be integrated into daily development activities.  Details on the project can be found in the Great MFA Distribution project repository.

On behalf of the OpenSSF community and staff, thank you to everyone who joined our quarterly town hall meeting today. If you weren’t able to attend the live presentation, check out the recording below and let us know if you have any questions or want to get more involved with any of the working groups or projects!

View the Zoom recording with chat, or watch the recording below.

The OpenSSF community is excited to chat more in-depth about several exciting project updates and recent announcements! We hope you’ll join us for our next community Town Hall, to be held Monday, November 15 at 10 a.m. PT (click here to see it in your local time).

This event is open to all – register now, then help us spread the word on Twitter and add the event to your calendar.

Imagine you have created an open source project that has become incredibly popular.  Thousands, if not millions, of developers worldwide, rely on the lines of code that you wrote. You have become an accidental hero of that community — people love your code, contribute to improving it, requesting new features, and encouraging others to use it. Life is amazing, but with great power and influence comes great responsibility.

When code is buggy, people complain. When performance issues crop up in large scale implementations, it needs to be addressed. When security vulnerabilities are discovered — because no code or its dependencies are always perfect — they need to be remediated quickly to keep your community safe.  

To help open source projects better address some of the responsibilities tied to security, many communities hosted by the Linux Foundation have invested countless hours, resources, and code into some important efforts. We’ve worked to improve the security of the Linux kernel, hosted Let’s Encrypt and sigstore, helped steward the ISO standardization for SPDX, and brought together a community building metrics for OSS health and risk through the CHAOSS project — among many others.

Today, we are taking steps with many leading organizations around the world to enhance the security of software supply chains. The Linux Foundation has raised $10 million in new investments to expand and support the Open Source Security Foundation (OpenSSF) and its initiatives. This cross-industry collaboration brings together an ecosystem to collectively identify and fix cybersecurity vulnerabilities in open source software and develop improved tooling, training, research, best practices, and vulnerability disclosure practices. We are also proud to announce that open source luminary, Brian Behlendorf, will serve the OpenSSF community as General Manager. 

Financial commitments for OpenSSF include Premier members such as AWS, Cisco, Dell Technologies, Ericsson, Facebook, Fidelity, GitHub, Google, IBM, Intel, JPMorgan Chase, Microsoft, Morgan Stanley, Oracle, Red Hat, Snyk, and VMware. Additional commitments come from General members, including Aiven, Anchore, Apiiro, AuriStor, Codethink, Cybertrust, Deepfence, Devgistics, DTCC, GitLab, Goldman Sachs, JFrog, Nutanix, StackHawk, Tencent, TideLift, and Wind River.

To learn more about how to join the OpenSSF or to get involved in one of its six working groups, listen in to this brief introduction from Brian Behlendorf recorded this week at KubeCon:https://www.youtube.com/embed/Mjsb6Z1Weto?feature=oembed&wmode=opaque&rel=0

In 2021, the Linux Foundation and its community will continue to support education and share resources critical to improving open source cybersecurity.  For example, this week, we also hosted SupplyChainSecurityCon, where the SLSA and sigstore projects were heavily featured.

If you are an open source software developer, user, or other community participant who just wants to help further protect the software that accelerates innovation around the world, please consider joining one of our six OpenSSF working groups, or suggest a new working group that addresses gaps in software supply chain security needs.

You can follow the latest news from OpenSSF here on our blog, Twitter (@TheOpenSSF), and LinkedIn.

Authors: Anne Bertucio, Christopher Robinson, David Wheeler, OpenSSF Vulnerability Disclosure WG members

https://github.com/ossf/oss-vulnerability-guide/blob/main/maintainer-guide.md

Vulnerability disclosure is the process of reporting, remediating, and communicating the details of a discovered vulnerability.  This is a critical component of software security both for the software communities that create the code as well as the downstream consumers that ingest and use it. It is so critical in fact, that it was one of the requirements of a recent United States Executive Order on improving software supply chain security. Vulnerability disclosure takes an organized effort on both the software maintainers and security researchers (referred to as “finders”). Within open source projects, this effort typically falls to the project maintainers.

A common saying in the vulnerability disclosure and incident response field is to, “have a plan before you need a plan.” Many open source maintainers have little-to-no familiarity with what a vulnerability disclosure plan should be. Maintainers are experts at creatively solving problems through code, not necessarily at being experts in the area of software security.  While many may have familiarity with secure coding concepts, they have little to no time for creating and drafting a plan for their project. The end result is open source projects without vulnerability disclosure policies, finders without directions on how to report, and users without a clear way to get information on vulnerabilities that may affect them.

Today the OpenSSF is releasing a guide and resources on coordinated vulnerability disclosure (CVD) for open source projects.  This guide was created by the OpenSSF Vulnerability Disclosure Working Group and has been informed by broadly-accepted industry good practices around CVD. The guide takes maintainers through CVD from pre-report preparations to publicly disclosing vulnerabilities, and puts the steps of CVD in the context of open source software development. The guide also includes commonly-needed policy and communication templates, such as a security policy (frequently referred to as a SECURITY.md), embargo notifications, and disclosure announcements. 

The Open Source ecosystem is broad and diverse. While projects may need to modify the resources for their project, the OpenSSF hopes that this encourages project maintainers who are unfamiliar with vulnerability disclosure to learn and adopt CVD for their projects, and simplifies implementation for the disclosure-familiar. These tools and practices can help improve the overall security and awareness of every community that integrates them on whatever level the project can.

This guide borrows the approaches of other open source project disclosure efforts: the Google Guide to CVD for OSS projects, the OpenStack Vulnerability Management Process, and the Kubernetes Security and Disclosure Process. 

This CVD guide is just one of many projects that the Open Source Security Foundation is actively working on to improve security within the OSS ecosystem. The OpenSSF is focused on the incredibly broad spectrum of open source software and seeks to improve the lives of developers, projects, and end-consumers of these fantastic communities.

The guide and resources are available on the OpenSSF GitHub.

Authors: Mike Maraya, Jeff Mendoza

We’re excited to announce Allstar, a GitHub app that provides automated continuous enforcement of security best practices for GitHub projects. With Allstar, owners can check for security policy adherence, set desired enforcement actions, and continuously enact those enforcements when triggered by a setting or file change in the organization or project repository. Allstar will help the open source community proactively reduce security risk while adding as little friction as possible.

Allstar is a companion to Security Scorecards, an automated tool that assesses risk to a repository and its dependencies. Security Scorecards checks a number of important heuristics (currently 18), such as whether the project uses branch protection, cryptographically signs release artifacts, or requires code review. From these scores, users can understand specific areas to improve in order to strengthen the security posture of their project. From here, Allstar takes the next step and allows maintainers to opt into automated enforcement of specific checks. If your repository fails a particular check that you enable, Allstar intervenes to make the necessary changes to remediate the issue, avoiding the extra effort of regular manual fixes. In short, Security Scorecards helps you measure your current security posture against where you want to be; Allstar helps you get there.

Continuous Automated Enforcement

Allstar works by continuously checking expected GitHub API states and repository file contents (repository settings, branch settings, workflow settings) against defined security policies and applying enforcement actions (filing issues, changing the settings) when expected states do not match the policies. The continuous nature of the enforcement protects against stealthy attacks that human enforcement might not notice: Allstar will detect and respond to a policy violation if someone, for example, temporarily disables branch protections in order to commit a malicious change before reenabling the protections. 

OpenSSF runs an Allstar instance that anyone can install and use. However, you can create and run your own Allstar instance for security or customization reasons.

User-Defined Enforcement Actions

Allstar lets you pick the enforcement actions that make sense for the organization, the repository, and the specific policies you’ve enabled. The following enforcement actions are available today, with more planned for the future:

• Log the security policy adherence failure with no additional action
• Open a GitHub issue
• Revert the modified GitHub policy setting to match the original Allstar configuration

Security Policy Enforcements Available Today

A limited number of security policy checks are currently enforced by Allstar, with additional policies planned in the coming months. Here’s what’s up and running so far:

Branch Protection

Branch protection sets requirements before a collaborator can push changes to a branch in your repository. Allstar can enforce the following requirements:

• Require approval on pull requests, which helps meet the code review requirement for Supply-chain Levels for Software Artifacts (SLSA)
• Set a number of required pull request approvals
• Dismiss stale pull request approvals
• Block force pushes

Security Policy

A defined policy for responsible vulnerability disclosure helps protect the users of your project, ensuring that you have a chance to remediate an issue before public disclosure. Allstar can enforce the presence of a security policy file (SECURITY.md).

Outside Collaborator Administrators

Allstar can enforce a requirement that users with administrator privileges on a repository be members of the owning organization. It can also disallow push access for outside collaborators. 

Binary Artifacts

Binary artifacts in a repository are threat vectors that cannot be accurately reviewed by a human. Allstar will detect these and alert the user if found.

What’s Next

Here are some of the enforcements we’re looking to build in future releases:

Automatic Dependency Update

Security vulnerabilities are regularly discovered and fixed in open source packages. Automatically updating your dependencies helps keep known vulnerabilities out of your project. Allstar will be able to ensure that automatic dependency updates via Dependabot or Renovate are enabled on your repository.

Frozen Dependencies

Automatic incorporation of new dependency versions without review is an attack vector. A lock file or similar language-specific pinning file can protect against a compromised dependency release making its way into your project. Allstar will be able to detect and enforce the presence of language-specific dependency pinning.

Get Involved

Allstar is still in the early stages of development, so we welcome adoption and community feedback. You can get started using Allstar and help improve it by submitting issues and/or pull requests for new additions. We look forward to rolling out more enforcements; in the meanwhile, taking simple steps like enforcing code review and setting branch protections can make a significant difference in protecting against supply-chain attacks. Taking these fundamental actions together can help raise the bar for security standards in open source software.

The Open Source Security Foundation (OpenSSF) community is working diligently to improve the security of the open source ecosystem. This is no small mission, so we are excited to share all of the work that is happening. In case you missed our recent Town Hall meeting, the resources can be found here. 

New members

First off, we’re excited to announce 10 new members have joined the OpenSSF. The commitments from companies industry-wide demonstrate the priority to secure the open source software that runs our business and our lives. Our newest members join at least 35 other companies and include Accurics, Anchore, Bloomberg Finance, Cisco Systems, Codethink, Cybertrust Japan, OpenUK, ShiftLeft, Sontaype and Tidelift. 

Working Group Progress

Our working groups are where the work gets done, and contributors from across the industry have made important progress in recent months. 

Vulnerability Disclosures

The OpenSSF Vulnerability Disclosures Working Group seeks to help improve the overall security of the open source software ecosystem by helping mature and advocate well-managed vulnerability reporting and communication. Its latest work includes: 

• OSS Vulnerability Disclosure good practices whitepaper, targeting September to publish.
• Setting up a call with the CVE Board to hear about the changes to the program and provide them feedback from our perspective
• Ongoing talks with CERT-CC about their open sourcing their VINCE vulnerability coordination tool

Best Practices

The Best Practices for OSS Developers working group is dedicated to raising awareness and education of secure code best practices for open source developers. Its latest work includes:

• A resource page that collects relevant security good practices, tools, resources, etc. to start advertising to OSS devs
• Rosetta Stone-style resource that shows similarities and gaps between relevant secure development frameworks/regulations
• yConnecting NIST 800-53 requirements provided by CRE project to SKF to share with developers using that tool for learning
• Scorecard 2.0 – Google Online Security Blog: Measuring Security Risks in Open Source Software: Scorecards Launches V2 (googleblog.com)

About the OpenSSF

The OpenSSF is a cross-industry organization that brings together the industry’s most important open source security initiatives and the individuals and companies that support them. It combines the Linux Foundation’s Core Infrastructure Initiative (CII), founded in response to the 2014 Heartbleed bug, and the Open Source Security Coalition, founded by the GitHub Security Lab to build a community to support open source security for decades to come. 

For more information and to learn how to get involved, including information about participating in working groups and advisory forums, please visit https://openssf.org/getinvolved.

Our communities take security seriously and have been instrumental in creating the tools and standards that every organization needs to comply with the recent US Executive Order

Overview

The US White House recently released its Executive Order (EO) on Improving the Nation’s Cybersecurity (along with a press call) to counter “persistent and increasingly sophisticated malicious cyber campaigns that threaten the public sector, the private sector, and ultimately the American people’s security and privacy.”

In this post, we’ll show what the Linux Foundation’s communities have already built that support this EO and note some other ways to assist in the future. But first, let’s put things in context.

The Linux Foundation’s Open Source Security Initiatives In Context

We deeply care about security, including supply chain (SC) security. The Linux Foundation is home to some of the most important and widely-used OSS, including the Linux kernel and Kubernetes. The LF’s previous Core Infrastructure Initiative (CII) and its current Open Source Security Foundation (OpenSSF) have been working to secure OSS, both in general and in widely-used components. The OpenSSF, in particular, is a broad industry coalition “collaborating to secure the open source ecosystem.”

The Software Package Data Exchange (SPDX) project has been working for the last ten years to enable software transparency and the exchange of software bill of materials (SBOM) data necessary for security analysis. SPDX, recognized and implemented as ISO/IEC standard 5962:2021, is supported by global companies with massive supply chains, and has a large open and closed source tooling support ecosystem. SPDX already meets the requirements of the executive order for SBOMs.

Finally, several LF foundations have focused on the security of various verticals. For example,  LF Public Health and LF Energy have worked on security in their respective sectors. Our cloud computing industry collaborating within CNCF has also produced a guide for supporting software supply chain best practices for cloud systems and applications.

Given that context, let’s look at some of the EO statements (in the order they are written) and how our communities have invested years in open collaboration to address these challenges.

Best Practices

The EO 4(b) and 4(c) says that

The “Secretary of Commerce [acting through NIST] shall solicit input from the Federal Government, private sector, academia, and other appropriate actors to identify existing or develop new standards, tools, and best practices for complying with the standards, procedures, or criteria [including] criteria that can be used to evaluate software security, include criteria to evaluate the security practices of the developers and suppliers themselves, and identify innovative tools or methods to demonstrate conformance with secure practices [and guidelines] for enhancing software supply chain security.” Later in EO 4(e)(ix) it discusses “attesting to conformity with secure software development practices.”

The OpenSSF’s CII Best Practices badge project specifically identifies best practices for OSS, focusing on security and including criteria to evaluate the security practices of developers and suppliers (it has over 3,800 participating projects). LF is also working with SLSA (currently in development) as potential additional guidance focused on addressing supply chain issues further.

Best practices are only useful if developers understand them, yet most software developers have never received education or training in developing secure software. The LF has developed and released its Secure Software Development Fundamentals set of courses available on edX to anyone at no cost. The OpenSSF Best Practices Working Group (WG) actively works to identify and promulgate best practices. We also provide a number of specific standards, tools, and best practices, as discussed below.

Encryption and Data Confidentiality

The EO 3(d) requires agencies to adopt “encryption for data at rest and in transit.” Encryption in transit is implemented on the web using the TLS (“https://”) protocol, and Let’s Encrypt is the world’s largest certificate authority for TLS certificates.

In addition, the LF Confidential Computing Consortium is dedicated to defining and accelerating the adoption of confidential computing. Confidential computing protects data in use (not just at rest and in transit) by performing computation in a hardware-based Trusted Execution Environment. These secure and isolated environments prevent unauthorized access or modification of applications and data while in use.

Supply Chain Integrity

The EO 4(e)(iii) states a requirement for

 “employing automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code.” 

The LF has many projects that support SC integrity, in particular:

• in-toto is a framework specifically designed to secure the integrity of software supply chains.
• The Update Framework (TUF) helps developers maintain the security of software update systems, and is used in production by various tech companies and open source organizations.  
• Uptane is a variant of TUF; it’s an open and secure software update system design which protects software delivered over-the-air to the computerized units of automobiles.
• sigstore is a project to provide a public good / non-profit service to improve the open source software supply chain by easing the adoption of cryptographic software signing (of artifacts such as release files and container images) backed by transparency log technologies (which provide a tamper-resistant public log). 
• We are also funding focused work on tools to ease signature and verify origins, e.g., we’re working to extend git to enable pluggable support for signatures, and the patatt tool provides an easy way to provide end-to-end cryptographic attestation to patches sent via email.
• OpenChain (ISO 5230) is the International Standard for open source license compliance. Application of OpenChain requires identification of OSS components. While OpenChain by itself focuses more on licenses, that identification is easily reused to analyze other aspects of those components once they’re identified (for example, to look for known vulnerabilities).

Software Bill of Materials (SBOMs) support supply chain integrity; our SBOM work is so extensive that we’ll discuss that separately.

Software Bill of Materials (SBOMs)

Many cyber risks come from using components with known vulnerabilities. Known vulnerabilities are especially concerning in key infrastructure industries, such as the national fuel pipelines,  telecommunications networks, utilities, and energy grids. The exploitation of those vulnerabilities could lead to interruption of supply lines and service, and in some cases, loss of life due to a cyberattack.

One-time reviews don’t help since these vulnerabilities are typically found after the component has been developed and incorporated. Instead, what is needed is visibility into the components of the software environments that run these key infrastructure systems, similar to how food ingredients are made visible.

A Software Bill of Materials (SBOM) is a nested inventory or a list of ingredients that make up the software components used in creating a device or system. This is especially critical as it relates to a national digital infrastructure used within government agencies and in key industries that present national security risks if penetrated. The use of SBOMs would improve understanding of the operational and cyber risks of those software components from their originating supply chain.

The EO has extensive text about requiring a software bill of materials (SBOM) and tasks that depend on SBOMs:

• EO 4(e) requires providing a purchaser an SBOM “for each product directly or by publishing it on a public website” and “ensuring and attesting… the integrity and provenance of open source software used within any portion of a product.” 
• It also requires tasks that typically require SBOMs, e.g., “employing automated tools, or comparable processes, that check for known and potential vulnerabilities and remediate them, which shall operate regularly….” and “maintaining accurate and up-to-date data, provenance (i.e., origin) of software code or components, and controls on internal and third-party software components, tools, and services present in software development processes, and performing audits and enforcement of these controls on a recurring basis.” 
• EO 4(f) requires publishing “minimum elements for an SBOM,” and EO 10(j) formally defines an SBOM as a “formal record containing the details and supply chain relationships of various components used in building software…  The SBOM enumerates [assembled] components in a product… analogous to a list of ingredients on food packaging.”

The LF has been developing and refining SPDX for over ten years; SPDX is used worldwide and is approved as ISO/IEC International Standard 5962:2021.  SPDX is a file format that identifies the software components within a larger piece of computer software and metadata such as the licenses of those components. SPDX 2.2 already supports the current guidance from the National Telecommunications and Information Administration (NTIA) for minimum SBOM elements. Some ecosystems have ecosystem-specific conventions for SBOM information, but SPDX can provide information across all arbitrary ecosystems.

SPDX is real and in use today, with increased adoption expected in the future. For example:

• An NTIA “plugfest” demonstrated ten different producers generating SPDX. SPDX supports acquiring data from different sources (e.g., source code analysis, executables from producers, and analysis from third parties). 
• A corpus of some LF projects with SPDX source SBOMs is available. 
• Various LF projects are working to generate binary SBOMs as part of their builds, including yocto and Zephyr. 
• To assist with further SPDX adoption, the LF is paying to write SPDX plugins for major package managers.

Vulnerability Disclosure

No matter what, some vulnerabilities will be found later and need to be fixed. EO 4(e)(viii) requires “participating in a vulnerability disclosure program that includes a reporting and disclosure process.” That way, vulnerabilities that are found can be reported to the organizations that can fix them. 

The CII Best Practices badge passing criteria requires that OSS projects specifically identify how to report vulnerabilities to them. More broadly, the OpenSSF Vulnerability Disclosures Working Group is working to help “mature and advocate well-managed vulnerability reporting and communication” for OSS. Most widely-used Linux distributions have a robust security response team, but the Alpine Linux distribution (widely used in container-based systems) did not. The Linux Foundation and Google funded various improvements to Alpine Linux, including a security response team.

We hope that the US will update its Vulnerabilities Equities Process (VEP) to work more cooperatively with commercial organizations, including OSS projects, to share more vulnerability information. Every vulnerability that the US fails to disclose is a vulnerability that can be found and exploited by attackers. We would welcome such discussions.

Critical Software

It’s especially important to focus on critical software — but what is critical software? EO 4(g) requires the executive branch to define “critical software,” and 4(h) requires the executive branch to “identify and make available to agencies a list of categories of software and software products… meeting the definition of critical software.”

Linux Foundation and the Laboratory for Innovation Science at Harvard (LISH) developed the report Vulnerabilities in the Core,’ a Preliminary Report and Census II of Open Source Software, which analyzed the use of OSS to help identify critical software. The LF and LISH are in the process of updating that report. The CII identified many important projects and assisted them, including OpenSSL (after Heartbleed), OpenSSH,  GnuPG, Frama-C, and the OWASP Zed Attack Proxy (ZAP). The OpenSSF Securing Critical Projects Working Group has been working to better identify critical OSS projects and to focus resources on critical OSS projects that need help. There is already a first-cut list of such projects, along with efforts to fund such aid.

Internet of Things (IoT)

Unfortunately, internet-of-things (IoT) devices often have notoriously bad security. It’s often been said that “the S in IoT stands for security.” 

EO 4(s) initiates a pilot program to “educate the public on the security capabilities of Internet-of-Things (IoT) devices and software development practices [based on existing consumer product labeling programs], and shall consider ways to incentivize manufacturers and developers to participate in these programs.” EO 4(t) states that such “IoT cybersecurity criteria” shall “reflect increasingly comprehensive levels of testing and assessment.”

The Linux Foundation develops and is home to many of the key components of IoT systems. These include:

• The Linux kernel, used by many IoT devices. 
• The yocto project, which creates custom Linux-based systems for IoT and embedded systems. Yocto supports full reproducible builds. 
• EdgeX Foundry, which is a flexible OSS framework that facilitates interoperability between devices and applications at the IoT edge, and has been downloaded millions of times. 
• The Zephyr project, which provides a real-time operating system (RTOS) used by many for resource-constrained IoT devices and is able to generate SBOM’s automatically during build. Zephyr is one of the few open source projects that is a CVE Numbering Authority.
• The seL4 microkernel, which is the most assured operating system kernel in the world; it’s notable for its comprehensive formal verification.

Security Labeling

EO 4(u) focuses on identifying:

“secure software development practices or criteria for a consumer software labeling program [that reflects] a baseline level of secure practices, and if practicable, shall reflect increasingly comprehensive levels of testing and assessment that a product may have undergone [and] identify, modify, or develop a recommended label or, if practicable, a tiered software security rating system.”

The OpenSSF’s CII Best Practices badge project (noted earlier) specifically identifies best practices for OSS development, and is already tiered (passing, silver, and gold). Over 3,800 projects currently participate.

There are also a number of projects that relate to measuring security and/or broader quality:

• Community Health Analytics Open Source Software (CHAOSS) focuses on creating analytics and metrics to help define community health and identify risk 
• The OpenSSF Security Metrics Project, which is in the process of development, was created to collect, aggregate, analyze, and communicate relevant security data about open source projects.
• The OpenSSF Security Reviews initiative provides a collection of security reviews of open source software.
• The OpenSSF Security Scorecards provide a set of automated pass/fail checks to provide a quick review of arbitrary OSS.

Conclusion

The Linux Foundation (LF) has long been working to help improve the security of open source software (OSS), which powers systems worldwide. We couldn’t do this without the many contributions of time, money, and other resources from numerous companies and individuals; we gratefully thank them all.  We are always delighted to work with anyone to improve the development and deployment of open source software, which is important to us all.

David A. Wheeler, Director of Open Source Supply Chain Security at the Linux Foundation

Author: Michael Scovetta, on behalf of the Identifying Security Threats Working Group

In addition to the Security Metrics initiative, the OpenSSF is proud to announce the Security Reviews initiative. Security Reviews joins a growing list of coordinated efforts spearheaded by the OpenSSF, aimed at securing the open source ecosystem. The initiative’s mission is to collect and curate a useful set of security assessments performed against open source packages. We would like to be a public resource, consumable by anyone under a permissive license, that anyone can contribute to. Through this, the project seeks to provide two important things:

1. An indicator of the security quality of a package

Individual open source projects are often reviewed by organizations to identify security weaknesses and address the health and security posture of upstream components. Sometimes these reviews are published, but more often are not. With access to a collection of security reviews in an open and collaborative environment, more individuals and organizations can remain informed and aware of the posture of the open source software they are using. 

2. Context where vulnerabilities or weaknesses exist

The open source community publishes more than 2,000 new packages on a given day, many of which form the foundation of modern technology. Individuals and organizations alike recognize the security risks associated with such a supply chain. By collecting key data from security reviews and associated work, this initiative provides insight into how much risk the open source space carries. 

Importance of this Initiative

Security reviews, source code audits, and associated work play a critical role in securing the open source ecosystem. A focused and well-scoped review executed by an experienced team has been shown to result in significant and long-lasting improvements. Organizations are increasingly supporting security reviews and recognizing the importance of cross-industry collaboration. The OpenSSF is a perfect example of this cross industry collaboration in action. With over 30 member organizations and counting, as well as multiple working groups and initiatives, the OpenSSF is enabling collaboration to secure the open source ecosystem with the Security Reviews initiative.  

We encourage all members of the security community to contribute security reviews to this project, and look forward to seeing its value and impact increase over time. For more information, please visit github.com/ossf/security-reviews.