Blog

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.

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. 

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. 

Identifying Security Threats: New Security Metrics Initiative Unveiled
This group has been working on the Security Metrics and are thrilled to unveil this as OpenSSF’s latest initiative! This initiative is used to collect, curate and communicate relevant security metrics for open source projects. This can be used, for example, to aid selection of open source software (OSS).

• Includes data for 105k projects, with metrics coming from:
  • Scorecard
  • Criticality Score
  • Best Practices Badge Program
  • Security Reviews (see below)
• Grafana-based dashboard
• Simple JSON API

For more information about the work, please visit https://metrics.openssf.org.

And to get a deep dive from the working group lead, check out this blog post, Introducing the Security Metrics Initiative, by Michael Scovetta.

This group has also released the Security Reviews repository on GitHub! This repository contains a collection of security reviews of open source software. It is a public resource that anyone can contribute to and is consumable by anyone under a permissive license.

• Curated, community-driven collection of security reviews of open source projects.
• Provides both positive and negative indicators of security quality.
• Can reference existing reviews already completed by third parties.
• Does your organization perform security reviews of open source projects? Please consider contributing to this project.
• Progress so far:
  • Linux Kernel (via Open Source Technology Improvement Fund (OSTIF))
  • Zlib (via Trail of Bits and TrustInSoft)
  • NPM (five packages)
  • Dependency Confusion Attacks

For more information, please visit: github.com/ossf/security-reviews

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:

• CII Best Practices badge
  • New tool released to simplify automated update of project data
  • Began Swahili translation, in addition to English, Chinese (Simplified), Spanish, French, German, Japanese, Brazilian Portuguese, and Russian
  • Added new “Project is maintained” criterion (was always implied, now stated)
  • Many technical updates (Rails 6.1, Ruby 3.0.1, various libraries)
• Secure Software Development Fundamentals (edX course)
  • Course content now available in Markdown format under CC-BY license
  • Markdown format enables others to more easily build on the educational materials

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: 

• Releasing Vuln disclosure Pain Points
• Vuln disclosure whitepaper for OSS projects 
• Guidance on Vuln Mgmt process for OSS projects

In Case You Missed the Initiatives from Last Quarter

Security Tooling
This working group focuses on identifying and building universally accessible, developer-focused tooling to help the open source community secure their code. It has also begun to develop some guidance on security tools.

OWASP ZAP now freely available on GitHub Actions Marketplace

• ZAP Baseline Scan
• ZAP Full Scan

Securing Critical Projects
This working group focuses on understanding which open source software projects are the most critical so that security work can be prioritized accordingly.

• package-feeds – feed parsing for language package manager updates
• package-analysis – analyzes open source packages for malicious software

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.

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

The OpenSSF would like to announce the initial release of the Security Metrics initiative. The primary objective of this initiative is to provide valuable decisive information about threats and risks associated with open source projects. Security Metrics comes with a cognitive dashboard for stakeholders to make reliable informed decisions regarding using/accommodating such projects in their software supply chain.

How Does It Work?

Security Metrics does crucial security oriented data collection from informed sources such as:

• Scorecard – measures the security posture of open source projects
• Criticality Score – determines the influence and importance of open source projects
• Best Practices Badge – communicates how well security best practices are followed
• Security Reviews – displays security assessments performed by researchers

Example

Here is an example of the information shown after a search for the Kubernetes project. While no single metric can fully describe the security risks of using a piece of software, we believe that having multiple metrics accessible from a central location can be helpful in making informed decisions.

Dashboard generated for the Kubernetes project

Where Are We Now?

Our initial “early alpha” release includes data collected on over 100,000 projects, accessible through a dashboard as well as a simple API. Over the next few months, we plan to release additional features (such as new metrics and richer API access), increase the number of projects covered, and improve the overall user experience.

You can access the Security Metrics at https://metrics.openssf.org. Your feedback is most welcome, and if you’re interested in learning more or joining this effort, please reach out to Michael Scovetta or join us at our next working group meeting.

The OpenSSF community has been working diligently to improve the security of the open source ecosystem. We would like to share all of the great work that is happening and invite you to participate.

We hope to see you at our next OpenSSF Town Hall Meeting on Monday, May 3, from 10:00 AM to 11:00 AM PDT. This event is open to the public; please help us spread the word by sharing with your social networks! Click here to register.

The OpenSSF community has been working fast and furious since its formation last year to improve the security of the open-source ecosystem. We all know this is no small mission and so we’re taking a moment to report out on all the work that’s happening and invite you to participate.

We hope to see you at our next OpenSSF Town Hall Meeting on Monday, February 22, 1:00-2:00p ET. It’s open to the public; please tell others so that they can join us! Click here to register.

The OpenSSF community has been working fast and furious since its formation last year to improve the security of the open source ecosystem. We all know this is no small mission and so we’re taking a moment to report out on all the work that’s happening and invite you to participate.  We also hope to see you at our next Town Hall Meeting on Monday, February 22, 1:00-2:00p ET.  Click here to register.

Technical Vision 

Perhaps most importantly, we’ve worked across companies and geographies to articulate our technical vision for this effort. Our challenge is a big one and a collective and intentional vision allows us to prioritize the pressing needs. 

We envision a future where participants in the open source ecosystem use and share high quality software, with security handled proactively, by default, and as a matter of course:

• Developers can easily learn secure development practices and are proactively guided by their tools to apply those practices and automatically informed when action is needed to prevent, remediate, or mitigate security issues.

• Developers, auditors, and regulators can create and easily distribute security policies that are enforced through tooling and automation, providing continuous assurance of the results.

• Developers and researchers can identify security issues (including unintentional vulnerabilities and malicious software) and have this information swiftly flow backwards through the supply chain to someone who can rapidly address the issue.

• Community members can provide information and notifications about product defects, mitigations, quality, and supportability and have this information rapidly flow forward across the ecosystem system to all users, and users can rapidly update their software or implement mitigations as appropriate.

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. The Technical Vision will help to direct this work. Here are the latest updates: 

Securing Critical Projects
This workgroup focuses on understanding which open source software projects are the most critical so that security work can be prioritized accordingly. The group is working on a Criticality Score and contributed to the Report on the 2020 FOSS Contributor Survey by Harvard & the Linux Foundation.

Security Tooling
The latest tool to come from this workgroup is the CVE Benchmark for tooling and data sets. It analyzes realworld codebases for more than 200 historical JavaScript/TypeScript vulnerabilities, using a range of static application security testing (SAST) tools. 

Identifying Security Threats
This group is making progress on a Security Metrics dashboard for open source projects. An early version of the security metric dashboard has already been demonstrated to the working group.

Vulnerability Disclosures
This group is developing user personas to focus on gaps in current practices and assessing vulnerability management practices and standards that are in use within the community today.

Best Practices
The group has established Security Scorecards, which auto-generates a “security score” through a number of checks on OSS projects. It’s simple to understand, fully automated, uses objective criteria and has the ability to make a large impact across the OSS ecosystem by driving awareness and inspiring projects to improve their security posture. 

This group is also developing a reference architecture and an educational presentation about the core components and relationships of the working group projects; working with the OWASP Security Knowledge Framework (SKF) to provide information on best practices and labs to try them out in various programming languages and improving the CII Best Practices Badge with internationalization that includes more Chinese translators and initial progress on Swahili. 

Security Representative to the OpenSSF Governing Board 

We also want to share that Ian Coldwater has been elected to the OpenSSF Governing Board as Security Representative. Ian is the director of Software Engineering – DevSecOps at Twilio and specializes in hacking and hardening Kubernetes, containers and cloud-native infrastructure. They are also the co-chair of the Kubernetes SIG Security. 

Oh, and if you haven’t already read it, the Linux Foundation’s Director of Open Source Supply Chain Security, David A. Wheeler has a new post about how to prevent supply chain attacks like SolarWinds – with specific recommendations. 

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 the 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.

Author: Kim Lewandowski, on behalf of the Digital Identity Attestation Working Group

We kicked off the first Digital Identity Attestation Working Group meeting under the OpenSSF in August, 2020. The objective of this working group is to enable open source maintainers, contributors and end-users to understand and make decisions on the provenance or origin of the code they maintain, produce and use.

We spent the first several meetings discussing different threat models as it relates to the digital identities of those involved in software supply chains, and what types of attacks are possible in each link of the chain. After this exercise, we’ve filled up our meetings with community presentations as we all try to learn more about this space and brainstorm potential opportunities to work together on mitigating these types of attacks. 

Below is a summary of the presentations to date:

Linux Kernel

• Presenter: Konstantin Ryabitsev (Linux Foundation)
• Summary: This presentation is an overview of how the Linux Kernel handles developer identity verification.
• Slides
• Youtube

In-Toto

• Presenter: Santiago Torres-Arias (Purdue University)
• Summary: This presentation introduced in-toto as a framework to automate compliance for software supply chain operations, onboarding new actors (e.g., developers) within an organization, and verifying best practices on software development lifecycles. Using in-toto, these processes can be cryptographically checked to ensure each actor performed their duties properly, that no steps were missed and no evidence of these steps was tampered with.
• Slides
• Youtube

Self Sovereign Identity

• Presenter: Arnaud Le Hors (IBM)
• Summary:  A short introduction to Self Sovereign Identity, a new system of identity management allowing individuals and organizations to have control over their digital identity. This presentation introduces the overall architecture based on a specific scenario, highlights key principles, and points to various related initiatives focusing on developing supporting standards and software.
• Slides
• Youtube

The Node.js Release Process

• Presenter: Myles Borins (GitHub)
• Summary: Myles reviewed how the Node.js project manages releases in a secure and reliable way. We looked at the tools we use to help release managers maintain multiple release lines, our testing infrastructure, and the processes we have in place to ensure reliable consistent releases.
• Youtube

Git Signing with SSH

• Presenter: Damien Miller (Google)
• Summary: Discussion of the goal of having every line of code in a git repository cryptographically attributable back to an author or importer.
  A proposal to refactor git’s cryptography support to allow more signature schemes than just the current gnupg. Proposal to add support for signing using SSH keys, based on the observation that most git users already have a SSH key that they use to authenticate to a repository.  Discussion of progress already made in OpenSSH to support arbitrary signatures that could be compatible.
  Hope that signing using SSH keys could be made near-seamless and that signing of commits and pushes could become default for most users.  Discussion of repository-host side countersigning, etc needed to retain provenance across rebase/merge operations.
• Slides
• Youtube

PKI

• Presenter: Mike Malone (Smallstep)
• Summary: An introduction to and overview of public key infrastructure (PKI) standards and technologies. Broadly, PKI deals with key distribution and management (enrollment, renewal, revocation, transparency, etc). This presentation explores the standards and practices in place for the Web PKI (HTTPS), and how they could be applied to help secure the software supply chain.
• Slides
• Youtube

Janssen

• Presenter: Mike Schwartz
• Summary: Janssen is an open source digital identity and access management platform. Organizations can use this software to self-host an identity provider or to build this capability into a product . The project includes “Janssen Auth Server”, which is an OAuth Authorization Server and an OpenID Connect Provider. Janssen Auth Server is a fork of the core component of Gluu Server 4.2.2, which was certified at the OpenID Foundation.  Other components of the Janssen Project include an implementation of a W3C WebAuthn server (FIDO 2), which enables people to enroll, authenticate and manage these new credentials.  In addition to the source code, the Janssen Project publishes cloud native assets and a distribution which can be installed on a VM or bare metal.  
• Youtube
• Project Home Page: https://jans.io

What’s Next?

We’re always looking for new presenters on topics in this space. If you are interested in presenting or would like to get involved with the working group, check out the GitHub repo for details on meetings and other communication channels.

In the future, this working group is looking to explore efforts around signature transparency throughout the software supply chain.

Thanks to all the presenters for taking the time to present and for their help compiling this recap!

Author: Bas van Schaik

Today, at Black Hat Europe, the Open Source Security Foundation (OpenSSF) unveiled its latest initiative: the OpenSSF CVE Benchmark. The benchmark consists of vulnerable code and metadata for over 200 historical JavaScript/TypeScript vulnerabilities (CVEs). It includes tooling for analyzing the real-world codebases that were affected by these vulnerabilities, using a range of different static application security testing (SAST) tools. The automatically-generated reports will help security teams evaluate different security tools on the market.

Engineering and security teams typically have one main requirement when they consider security tools: effectiveness at detecting vulnerabilities (i.e. produce few false negatives) while maintaining a low false positive rate. That’s exactly what is measured by the OpenSSF CVE Benchmark.

The OpenSSF CVE Benchmark tooling and data are open source and available on GitHub. 

A new approach to benchmarking

The benchmark addresses two problems that security teams face today when assessing security tools. First, rather than using synthetic test code, the OpenSSF CVE Benchmark uses real historical CVEs. Using this approach, security tools are tested on real codebases that contain real vulnerabilities. Second, by also analyzing the patched version of every codebase, the tools’ false positive rates can be established more accurately.

For each of the over 200 CVEs in the dataset, the CVE Benchmark determines: 

1. Is a tool able to detect the vulnerability, or does it produce a false negative?
2. Does it recognize the patch, or does it produce a false positive on the patched code?

Currently, one of the most common methods of assessing the efficacy of a security tool, is to run it on a codebase containing synthetic vulnerabilities. For each popular programming language, there exists multiple such codebases, which are maintained to various degrees. Most of such “benchmark codebases” or “test suites” are worked on by volunteers, while others are published by large organisations (like NIST’s SAMATE initiative, which maintains the Juliet test suite).

Creating codebases with synthetic vulnerabilities is challenging. In many cases, the test suites don’t resemble real codebases: every odd-looking snippet of code is almost guaranteed to be a valid result. This is far from true for real-world code. Requesting that tool vendors optimize their analysis capabilities for such codebases is counterproductive: a tool that performs well on a synthetic codebase is by no means guaranteed to perform well on real-world code.

In fact, real vulnerabilities are often the result of a complex interplay between an application’s own code and its dependencies. For example, user-controlled data might enter a web application through a web framework. It might then flow through the application’s own functions and data structures, to eventually end up in a templating framework. It is close to impossible for a group of volunteers (or a government agency) to continually keep their benchmark codebase or test suite up to date with large numbers and the latest versions of popular frameworks and libraries.

Evaluating a tool’s false positive rate is also critical: if a tool produces too many false positives, engineers will lose too much time to the triaging process, and eventually cease using the tool altogether. Unfortunately, it is hard to gauge a tool’s false positive rate by running it on synthetic benchmark codebases. These codebases don’t ship with patches for their vulnerabilities, making it impossible to ascertain whether a tool would recognize such a patch, or flag up a false positive instead.

We need your help!

The OpenSSF CVE Benchmark is a community project that was initiated by the OpenSSF’s Security Tooling working group, and we would love your help!

The CVE benchmark currently consists of 218 historical CVEs that affected open source JavaScript and TypeScript codebases. We welcome contributions to expand our dataset, or improve the framework tooling.
The benchmark framework currently provides integrations for three different security tools: ESLint, nodejsscan, and CodeQL. Developing an integration for additional security tools is straightforward; it typically requires < 200 lines of code. We invite everyone to contribute their integrations back to our open source repository!

Click here to re-tweet!

The video recording of the Open Source Security Foundation (OpenSSF)  “Public Town Hall” meeting of November 9, 2020 is now available! This meeting shares updates and celebrates accomplishments during the first three months of the OpenSSF. It includes presentations from the OpenSSF Governing Board, Technical Advisory Council, and Working Group leads. Questions and answers occur throughout. It also includes information on how to get involved.

At-a-glance, Town Hall Agenda:

• Welcome and Overview
• What’s Happening
  • Governing Board and Planning Committee
  • Technical Advisory Council
  • Working Groups
    • Identifying Security Threats – security metrics for open source projects
    • Security Tooling – state of the art, globally accessible security tools
    • Best Practices – awareness and education of security best practices
    • Vulnerability Disclosures – efficient vulnerability reporting and remediation
    • Digital Identity Attestation – ensuring the provenance of open source code
    • Securing Critical Projects – hands-on help for critical open source projects
• Discussion + Q&A