Blog

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

Author: Kim Lewandowski, Google Product Manager

One of the first things I wanted to do when the OpenSSF launched was help people make better decisions about security when consuming open source projects, and draw more awareness to the health of these critical projects we all depend on. Some might argue that it’s almost too easy to introduce a new dependency into your software systems. I’m definitely guilty of this in my previous life as an engineer. I remember pulling in random Python packages when building my own websites and not putting any thought into security. It should be fine if so many other people are using the same package, right?

With the uptick of open source software attacks, there’s more general awareness now that pulling in open source code you didn’t write into your software supply chains should warrant closer review. At large organizations this can get a bit tricky when trying to scale out automated analysis and trust decisions of any new dependencies, or keeping updated on the hygiene of existing ones. These issues are what inspired the new “Scorecards” project with the OpenSSF that we are releasing today. 

The goal of Scorecards is to auto-generate a “security score” for open source projects to help users as they decide the trust, risk, and security posture for their use case. This data can also be used to augment any decision making in an automated fashion when new open source dependencies are introduced inside projects or at organizations. For example, organizations may decide that any new dependency with low scores has to go through additional evaluation. These checks could help mitigate malicious dependencies from getting deployed to production systems like we’ve seen recently with malicious NPM packages.

We have defined an initial evaluation criteria that will be used to generate a scorecard for an open source project in a fully automated way. Currently the code only works with software repositories from GitHub, but we will extend it to cover other source code repositories. Some of the evaluation metrics used include a well-defined security policy, code review process and continuous test coverage with fuzzing and static code analysis tools.

Using the scorecard data, we want to build a culture of security through improved visibility. We want to work with the community and improve the security health of the critical projects we all depend on.

It’s early days for this project, though we have made some progress on this problem, we have not solved it and need the community’s help in improving these security evaluation metrics, and adding new ones. There’s a small wishlist of issues already in the repo. Let’s work together on a more secure future for open source software!

The Open Source Security Foundation (OpenSSF) has developed a trio of free courses on how to develop secure software. These courses are part of the Secure Software Development Fundamentals Professional Certificate program, all available on the edX platform. This material is intended for all software developers so they can learn to develop secure software. It focuses on practical steps that any software developer can easily take, not theory or actions requiring unlimited resources.

Those interested can sign up starting October 29, 2020. The course material is expected to be released on November 5, 2020. For more information click here.

Almost all software is under attack today, and many organizations and developers are unprepared in their defense. The Secure Software Development Fundamentals courses will enable software developers to create and maintain systems that are much harder to successfully attack, reduce the damage when attacks are successful, and speed the response so that any latent vulnerabilities can be rapidly repaired. The best practices covered in this program apply to all software developers, and include information especially useful to those who use or develop open source software.

Today 48% of technical hiring managers stated hiring professionals with security expertise is a high priority (as reported in the 2020 Open Source Jobs Report), so there is not a better time to engage in this course. Similarly, Security Software Developers earn 35% more than Software Developers in a US nationwide average (according to ZipRecruiter Sep 25, 2020 data).

The courses in this program discusses risks and requirements, design principles, and evaluating code (such as packages) for reuse. It then focuses on key implementation issues: input validation (such as why allowlists and not denylists should be used), processing data securely, calling out to other programs, sending output, cryptography, error handling, and incident response. This is followed by a discussion on various kinds of verification issues, including different kinds of security tools. The program concludes with a discussion on deployment and vulnerability reporting.

Chris Aniszczyk (CTO of Cloud Native Computing Foundation (CNCF)) said, “In today’s world where more companies are using more software, becoming software companies themselves and everything is becoming connected, security education is more important than ever. At CNCF, we are excited about this new security professional certificate, and intend to have all of our project leadership pass the courses in the program and recommend you do the same in your communities.”

Software developers can take each of the three courses at no cost. They can enroll at any time, and they will then have limited-time access to the course material on EdX. Developers who wish to prove mastery of the material (or have unlimited access time to the material on EdX) can enroll in the Secure Software Development Fundamentals Professional Certificate program for a fee. The courses included in the program are:

1. Secure Software Development: Requirements, Design, and Reuse (LFD104x)
2. Secure Software Development: Implementation (LFD105x)
3. Secure Software Development: Verification and More Specialized Topics (LFD106x)

Those interested can sign up starting October 29, 2020. The course material is expected to be released on November 5, 2020. For more information click here.

Please join us for the first-ever OpenSSF Town Hall Meeting on November 9, 2020 from 10 AM to 12 PM Pacific Time (US and Canada).

In this meeting, we will share updates and celebrate accomplishments during the first three months of the project. Attendees will hear from the Governing Board, Technical Advisory Council, and Working Group leads, have an opportunity for Q+A, and learn more about how to get involved in the project. Click here to register.

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

This is a public meeting and everyone is welcome!  Please register using the link below to receive a  confirmation email with an option to add the meeting to your personal calendar.

http://bit.ly/OpenSSFTownHall

We are actively seeking individuals and companies to join us and get involved in securing the open source ecosystem. The town hall meeting is a great opportunity for those not currently involved to learn more about the work we are doing at OpenSSF and how to become a part of it!

We hope to see you there!

The Open Source Security Foundation (OpenSSF) is accepting nominations for the Security Community Individual Representative seat on our Governing Board. The nomination period is open until October 23 2020, after which voting will occur, to conclude on November 5 2020. In this post, we would like to provide some additional information about the role, including its’ activities and our rationale behind creating this position. At the bottom of the post, we share a link where nominations can be submitted, as well as contact information.

What is OpenSSF?
The OpenSSF is a cross-industry collaboration that brings together leaders to improve the security of open source software (OSS) by building a broader community, targeted initiatives, and best practices. Current initiatives are linked to from our GitHub page.

The OpenSSF was established on the premise that security researchers need a mechanism to allow them to collaboratively address methods needed to secure the open source supply chain. It recognizes that security researchers across the globe within organizations have common interests and concerns. OpenSSF facilitates sustained dialogue and project work among private entities, foundations/nonprofits, individual contributors, and academia.

What is involved in serving on the OpenSSF Governing Board?
Governing Board members are responsible for the overall organization and funding of the OpenSSF.  Some activities in which they participate include things like:

• establishing criteria for membership and dues
• overseeing business and community outreach
• adopting and maintaining policies and procedures
• establishing advisory bodies, committees, programs and councils to support the mission of the OpenSSF
• approving a budget and fundraising proposals
• publishing use cases, user stories, websites and priorities to help inform the ecosystem and technical community
• voting on all decisions or matters coming before the Governing Board

Governing Board (GB) members typically spend 2-3 hours per month preparing for and attending a monthly Governing Board meeting. Many GB members choose to spend additional time in Governing Board related committees which could include strategy, finance, and communications committees.

Like all Governing Board seats, the Security Community Individual Representative seat is unpaid and is held on a volunteer basis, generally as a complement and component of an individual’s primary employment within the industry. As outlined in Section 3 of the OpenSSF Charter, the Security Community Individual Representative will serve a one year term (i.e.: until August 2021), coinciding with the OpenSSF Member Representative elections.

More details about the Governing Board and general organization and operations of OpenSSF are available in the OpenSSF Charter, which should be considered the authoritative document about this role.

Additional OpenSSF governance information can be found on GitHub.

Rationale for Security Community Individual Representative Governing Board seat

When drafting the original Charter for OpenSSF, one thing we were keen on was the prompt introduction of dedicated seats to diversify the perspectives and professional experiences of our Governing Board. Ultimately this included adding and reserving a seat for a representative from a Nonprofit organization or Academia (“Associate Member Representative”), as well as adding and reserving a seat for an individual from the broader technical community who could help bring further perspective (“Security Community Individual Representative”).

Perhaps a bit of a misnomer, the “Security Community Individual Representative” is a dedicated seat for an individual from the open source software maintainer community and/or the security community.

We envisioned that such a seat would be filled by a nominee who showed a longtime dedication to the open source software ecosystem and/or is someone from the security community who has expertise in areas like application security and vulnerability management. We imagined that such a candidate probably would not work at any of the organizations of which the founding members of the OpenSSF GB are members/employees, is likely to have played a fundamental role in the development and maintenance of one or more large or critical open source projects, and/or has worked on securing software at scale through research, engineering, or other security roles, and could help us to ensure that decisions we make and security initiatives we support are a net positive for maintainers, their projects, and the OSS ecosystem. The intention behind the role was to better represent the range of perspectives, backgrounds, needs, and motivations amongst OSS maintainers and security researchers, including individual contributors, and to ensure that a person with this viewpoint would have a dedicated “seat at the table” within OpenSSF governance to help us broaden the range of feedback, ideas, and expertise that would be represented at the Governing Board level.

It should be noted that these are merely some suggested criteria, and anyone who feels they would make a great community rep for an organization focusing on OSS and security is warmly welcomed to apply. By no means are the items listed above a hard requirement for nomination

Submit your nomination
Nominations for the Security Community Individual Representative seat will be open until October 23 2020, and voting will take place until November 5 2020. See nomination instructions below. Once the nomination period closes, voting will be open to members of the openssf-announcements@lists.openssf.org mailing list. Click here to sign up for an OpenSSF mailing list.

Nominations (including self-nomination) can be submitted to the form below (Due October 23rd 2020):
https://docs.google.com/forms/d/e/1FAIpQLSd61bqfR_siMDvWlCC4s3jKxaVAVbOIIrt9_EwDqZ23VPmMlQ/viewform

Questions and Feedback
To share feedback with the OpenSSF Governing Board, please complete this quick form. Additionally, learn more about how to get involved here.

[Editor’s note: This post was updated October 7 2020 to add clarifying language around desirable qualities for a nominee]