Open Source Security Foundation
Projects Overview
Projects
OpenSSF Working Groups
AI/ML Security
BEAR
Belonging, Empowerment, Allyship, and Representation
BEST
Best Practices for
Open Source Developers
Global Cyber Policy
ORBIT
Open Resources for Baselines, Interoperability, and Tooling
Securing Critical Projects
Securing Software Repositories
Security Tooling
Supply Chain Integrity
Vulnerability Disclosures
Visit the Working Groups page at https://openssf.org/community/openssf-working-groups/ for information on each group.
OpenSSF Technical Initiatives Landscape
B1. OpenSSF Best Practices Badge project
B2. OpenSSF Scorecard project
B3. Education SIG
B4. Memory Safety SIG
B5. C/C++ Compiler Options SIG
B6. Python Hardening SIG
Source code
Build
Package
Package selection information
Vulnerability information
Dependencies
Consumer
Developer
T1. SBOM Everywhere SIG
T2. OSS Fuzzing SIG
T3. SBOMit project
T4. Protobom project
T5. bomctl project
T6. Fuzz Introspector project
T7. Minder project
T8. OpenBao project
C1. Security Insights project
C2. SLSA project
C3. S2C2F project
C4. Gittuf project
C5. GUAC project
C6. Zarf project M
Securing Software Repositories
R1. RSTUF Project
A1. Model Signing SIG & Project
B3
B4
C3
B5
B6
C1
C5
CP1
CP2
P1
P3
R1
B2
C4
B1
T1
T2
T3
C2
P2
C3
V1
V2
V3
C1
C6
A1
T4
T5
T6
T7
O1
O1
T8
OpenSSF Scorecard
Quickly assess open source projects�for risky practices.
OpenSSF Scorecard: Use Cases
For individual maintainers
For an organisation
For consumers
Automated Checks with Weighted Scoring
OpenSSF Scorecard: Running the Checks
OpenSSF Scorecard: Viewing Scores
OpenSSF Scorecard: Sub-projects
OpenSSF Scorecard: Get Involved
Graph for Understanding Artifact Composition
GUAC gives you directed, actionable insights into the security of your software supply chain.
GUAC: Use Cases
For developers
For operations engineers
For open source program offices
GUAC: Mapping the relationships between software
GUAC aims to fill in the gaps by ingesting software metadata, like SBOMs, and mapping out relationships between software. When you know how one piece of software affects another, you’ll be able to fully understand your software security position and act as needed.
GUAC: Components
The full GUAC component deployment is a set of asynchronous services that combine to form a robust and scaleable pipeline.
GUAC: Get Involved
OpenVEX
A simplified Vulnerability Exploitability�eXchange implementation
What is VEX?
V.E.X. - Vulnerability Exploitability Exchange
A sequence of messages to communicate the impact of a vulnerability on a piece of software.
Designed to work with SBOMs but also independently.
Created by a community of stakeholders facilitated by CISA.
OpenVEX: Use Cases
The primary use cases for VEX are to provide users (e.g., operators, developers, and services providers) additional information on whether a product is impacted by a specific vulnerability in an included component and, if affected, whether there are actions recommended to remediate.
The VEX Statement
VEX centers on the notion of a statement. In short, a statement can be defined as an assertion intersecting product, a vulnerability, and an impact status:
OpenVEX
OpenVEX is one of the 4 VEX flavors developed under the CISA VEX working group.
Designed to be lightweight, embeddable and with linked data in mind.
The primary use cases for VEX are to provide users (e.g., operators, developers, and services providers) additional information on whether a product is impacted by a specific vulnerability in an included component and, if affected, whether there are actions recommended to remediate.
OpenVEX is…
A Specification
OpenVEX documents are minimal JSON-LD files that capture the minimal requirements for VEX as defined by the VEX working group organized by CISA. The OpenVEX Specification is owned and steered by the community.
A Go Library
The project has a go library (openvex/go-vex) that lets projects generate, transform and consume OpenVEX files. It enables the ingestion of VEX metadata expressed in other VEX implementations.
A Set of Tools
Work is underway to create the tools software authors and consumers need to handle VEX metadata. The current flagship project is vexctl, a CLI to create, merge and attest VEX documents.
OpenVEX Creators
vexctl Features
VEX Document Edit
Creating documents, adding statements,
Document Merging
Merging data from one or more documents into one.
Generation
Generate VEX documents from existing data
Attest & Sign
Generate signed attestations and sign them natively with Sigstore.
OpenVEX: Ecosystem
The project has a growing ecosystem with known implementations in:
OpenVEX: Get Involved
Protobom
A format-neutral SBOM data representation and I/O library
28
Protobom: The Original Cohort
Protobom Core
Protobom Core
In essence, the protobom spec and intermediate representation allows applications to work with a consistent SBOM data graph.
… instead of a bunch of ever changing JSON.
Protobom Universe
The protobom universe of libraries and tooling aims to abstract operations that applications commonly perform on SBOM data.
The protobom ecosystem enables the creation of advanced SBOM applications without worrying about the underlying formats.
Graph
I/O
Storage
Query
Protobom: Compatibility
The protobom library can be used to read in and write out SBOM documents in these formats:
Protobom: Examples
Protobom: Get Involved
SBOMit
Specification of an SBOM format independent
method for attesting components
SBOMit
An SBOMit document is effectively an SBOM, only with additional verification information added that was generated at the time the supply chain was generated. This verification information, which uses in-toto attestations and layouts, can be validated by a party to get a high degree of assurances about the software.
SBOMit
Prepare
Sources
Resolve
Dependencies
Compile
SBOMit: Document Components
SBOMit: Advantages
SBOMit: Get Involved
Sigstore
A wax seal of security for the digital era.
42
Sigstore: Vision
Sigstore was started to improve supply chain technology for anyone using open source projects. It's for open source maintainers, by open source maintainers.
And it's a direct response to today’s challenges, a work in progress for a future where the integrity of what we build and use is up to standard.
Sigstore: How it Works
Sigstore is a set of tools developers, software maintainers, package managers and security experts can benefit from. Bringing together free-to-use open source technologies like Fulcio, Cosign and Rekor, it handles digital signing, verification and checks for provenance needed to make it safer to distribute and use open source software.
A standardized approach
This means that open source software uploaded for distribution has a stricter, more standardized way of checking who’s been involved, that it hasn’t been tampered with. There’s no risk of key compromise, so third parties can’t hijack a release and slip in something malicious.
Sigstore: Components
Sigstore: Benefits
Sigstore: Get Involved
Supply-chain Levels
for Software Artifacts (SLSA)
Safeguarding artifact integrity across any software supply chain
SLSA
Supply-chain Levels for Software Artifacts, or SLSA ("salsa").
It’s a security framework, a checklist of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure. It’s how you get from "safe enough" to being as resilient as possible, at any link in the chain.
If an SBOM is like a list of ingredients, SLSA is like all of the food safety handling guidelines that make an ingredient list credible.
SLSA: Use Cases
SLSA is for everyone involved in producing, consuming, and providing infrastructure for software such as build platforms and package ecosystems.
SLSA: The Supply Chain Problem
Any software can introduce vulnerabilities into a supply chain. As a system gets more complex, it’s critical to already have checks and best practices in place to guarantee artifact integrity, that the source code you’re relying on is the code you’re actually using. Without solid foundations and a plan for the system as it grows, it’s difficult to focus your efforts against tomorrow’s next hack, breach or compromise.
SLSA offers…
SLSA: Levels of Assurance
Level | Requirements | Focus |
Provenance showing how the package was built | Mistakes, documentation | |
Signed provenance, generated by a hosted build platform | Tampering after the build | |
Hardened build platform | Tampering during the build |
SLSA: Get Involved
Zarf
A free open source tool that enables continuous software delivery on systems that are disconnected from the internet.
DevSecOps for Airgap
Zarf eliminates the complexity of air gap software delivery for Kubernetes clusters and cloud-native workloads using a declarative packaging strategy to support DevSecOps in offline and semi-connected environments.
Modern software assumes your systems have access to the internet. This may work for 99% of the world, but certain SECURE systems need to maintain capabilities while being disconnected or intermittently disconnected from the internet. Zarf keeps your software running, no matter your connection status.
Zarf: Use Cases
Zarf: Use it to…
Zarf: Features
Zarf: Get Involved
gittuf
Protect the contents of a Git repository from unauthorized or malicious changes
gittuf
gittuf is a platform-agnostic Git security system. The maintainers of a Git repository can use gittuf to protect the contents of a Git repository from unauthorized or malicious changes. Most significantly, gittuf’s policy controls and enforcement is not tied to your source control platform (SCP) or “forge”, meaning any developer can independently verify that a repository’s changes followed the expected security policies. In other words, gittuf removes the forge as a single point of trust in the software supply chain!
gittuf: Features
gittuf: Goals
While developing gittuf, we have the following goals.
Unopinionated / Agnostic
gittuf provides features to implement different policies without requiring the use of specific systems or tools. For example, gittuf supports a variety of signing mechanisms such as GPG keys and Sigstore’s gitsign.
Compatible
gittuf is designed with great care to be compatible with standard Git repositories. All additional artifacts are stored in Git’s object store in a gittuf-specific namespace. These artifacts are not visible in the “main” contents of a repository, and therefore do not create any clutter.
gittuf: Get Involved
Open Source Vulnerability Schema (OSV Schema)
Better vulnerability triage
for open source
66
66
OSV Schema
OSV Schema defines a standard interchange format for describing vulnerabilities in open source packages.
We hope to define a simple format that all vulnerability databases can export, to make it easier for users, security researchers, and any other efforts to consume all available databases. Use of this format would also make it easier for the databases themselves to share or cross-check information. Ultimately, this format aims to enable automated, accurate, and distributed management of vulnerabilities in open source dependencies.
OSV: Use Cases
OSV consists of:
OSV: How it Works
OSV enables developers to identify known third-party open source dependency vulnerabilities that pose genuine risk to their application and its environment, so they can focus remediation efforts on the vulnerabilities that matter and sustainably manage vulnerabilities that do not affect them.
The OSV repository contains the infrastructure code that serves osv.dev (including the API). This infrastructure serves as an aggregator of vulnerability databases that have adopted the OpenSSF Vulnerability format.
osv.dev additionally provides infrastructure to ensure affected versions are accurately represented in each vulnerability entry, through bisection and version analysis.
OSV Schema: Get Involved
Package Analysis &
Malicious Packages
Improving security by detecting and reporting malicious open source software
Package Analysis
The project looks for behaviors in packages available on open source repositories that indicate malicious software:
This effort is meant to improve the security of open source software by detecting malicious behavior, informing consumers selecting packages, and providing researchers with data about the ecosystem.
Package Analysis: How it Works
The project's components are:
The goal is for all of these components to work together and provide extensible, community-run infrastructure to study behavior of open source packages and to look for malicious software. We also hope that components can be used independently, to provide package feeds or runtime behavior data for anyone interested.
Package Analysis: Pipeline
Malicious Packages
An open source system for collecting reports of malicious packages�identified in package repositories, consumable via the OSV format.
The aim is to be a comprehensive, high quality, database of reports of malicious packages published on open source package repositories.
Public reports help protect the open source community, and provide a data source for the security community to improve their ability to find and detect new open source malware.
Malicious Packages: Metrics
Total Reports
33,573
Package Analysis: Get Involved
Repository Service
for TUF (RSTUF)
Better vulnerability triage for open source
RSTUF
Repository Service for TUF (RSTUF) is a collection of components that provide services for securing content downloads from tampering between the repository and the client (for example, by an on-path attacker).
RSTUF security properties are achieved by implementing The Update Framework (TUF) as a service.
Repository Service for TUF is platform, artifact, language, and process-flow agnostic.
RSTUF: Use Cases
Some RSTUF use case examples include but are not limited to:
RSTUF: Design/Solution
RSTUF: API Integrations
If a user wants to integrate RSTUF into an existing CI/CD pipeline the only requirement is to make a REST API request to RSTUF:
The same can be said when a user wants to integrate RSTUF into an existing distribution platform:
RSTUF: Get Involved
Secure Supply Chain
Consumption Framework (S2C2F)
The S2C2F guide outlines and defines how to securely consume OSS dependencies into the developer’s workflow.
S2C2F
The S2C2F is a combination of processes and tools for any organization to adopt to help establish a secure OSS ingestion process to protect developers from OSS Supply Chain threats and to help establish a governance program to manage your organization’s use of OSS.
S2C2F: Objective
The objective for the S2C2F Project is to develop and continuously improve upon a guide that provides the following:
S2C2F: Core Concepts
The S2C2F is modeled after three core concepts—control all artifact inputs, continuous process improvement, and scale.
S2C2F: Get Involved
Best Practices
Badge Program
Best practices for Free/Libre and
Open Source Software
Best Practices Badge Program
The Best Practices badge is a way for Free/Libre and Open Source Software (FLOSS) projects to show that they follow best practices. Projects can voluntarily self-certify, at no cost, by using a web application to explain how they follow each best practice. The OpenSSF Best Practices Badge is inspired by the many badges available to projects on GitHub. Consumers of the badge can quickly assess which FLOSS projects are following best practices and as a result are more likely to produce higher-quality secure software.
Best Practices Badge Program
The OpenSSF Best Practices Badge website outlines the criteria for the passing badge, provides an example, shows participating projects, and supports queries to show projects that have a passing badge. This project was formerly known as the Core Infrastructure Initiative (CII) Best Practices Badge and was formally renamed as part of OpenSSF in late 2021. More information on the OpenSSF Best Practices Badging program is available on GitHub.
Best Practices Badge Program
Getting a passing badge is a significant achievement; on average only about 10% of pursuing projects have a passing badge. We have established two higher levels beyond passing: silver and gold. Here is a summary of the gold criteria:
Best Practices Badge Program: Get Involved
Criticality Score
Defining the influence and importance of a project
Criticality Score
The Criticality Score gives criticality score for an open source project.
Goals:
A project’s criticality score defines the influence and importance of a project. It is a number between 0 (least-critical) and 1 (most-critical). It is based on the following algorithm by Rob Pike:
Criticality Score: Get Involved
Fuzz Introspector
Improving the fuzzing experience of a project
Fuzz Introspector
Fuzz introspector is a tool to help fuzzer developers to get an understanding of their fuzzer’s performance and identify any potential blockers. Fuzz introspector aggregates the fuzzers’ functional data like coverage, hit frequency, entry points, etc to give the developer a birds eye view of their fuzzer. This helps with identifying fuzz bottlenecks and blockers and eventually helps in developing better fuzzers.
Fuzz-introspector aims to improve fuzzing experience of a project by guiding on whether you should:
Indexing OSS-Fuzz Projects
Open Source Fuzzing Introspection provides introspection capabilities to OSS-Fuzz projects and is powered by Fuzz Introspector.
Fuzz Introspector: Architecture
Fuzz Introspector: Get Involved
Security Insights Specification
Machine-processable project security information reporting
Security Insights Specification
This specification provides a mechanism for projects to report information about their security in a machine-processable way. It is formatted as a YAML file to make it easy to read and edit by humans.
The data tracked within this specification is intended to fill the gaps between simplified solutions such as SECURITY.md and comprehensive automatable solutions such as SBOMs. In that gap lay elements that must be self-reported by projects to allow end-users to make informed security decisions.
As the adoption of Security Insights grows, so does the opportunity to automatically ingest it. For example, the Linux Foundation's CLOMonitor parses a project's Security Insights file to determine whether projects have reported on select security factors prioritized by the foundation.
Security Insights Specification: Get Involved
bomctl
Bridging the gap between SBOM generation
and SBOM analysis tools.
bomctl
bomctl is format-agnostic Software Bill of Materials (SBOM) tooling, which is intended to bridge the gap between SBOM generation and SBOM analysis tools. It focuses on supporting more complex SBOM operations by being opinionated on only supporting the NTIA minimum fields or other fields supported by protobom.
It is intended to help developers who need to manipulate SBOMs at the CLI or within a workflow. Example operations would be merging in project specific SBOM data that would not be detected by a SBOM generation tool.
bomctl: Goals
bomctl: Features
bomctl: Get Involved
OSPS Baseline
Structured security requirements aligned with international frameworks, standards, and regulations
111
What is the Baseline?
The OpenSSF’s Open Source Project Security Baseline (OSPS Baseline or simply “Baseline”) refers to a collection of efforts led by the OpenSSF in collaboration with members and LF partners (CNCF, FINOS, OpenJS).
The Baseline includes a Catalog of requirements that map to industry standards, frameworks, and regulations, and Tooling to assist in determining Baseline-compliance, that automate Baseline configuration settings, and links to evidence and attestations.
112
112
Est. 2024
All your Base are belong to us
The OpenSSF Security Baseline was officially released Feb 2025
Based on a library of well-known cybersecurity frameworks, standards, and global regulations
It includes 40 requirements across 3 levels of maturity covering 8 areas of cyber and application security practices
113
What are these levels you speak of?
114
Level 1
Level 2
Level 3
20
18
9
Compliance Crosswalk
115
Level 2 & 3
Building a Better Catalog
Baseline currently maps alignment across multiple cyber compliance frameworks and/or cyber legislations. “Baselining” helps downstream select projects that align with and that support their compliance obligations!
116
Have a framework or a particular piece of legislation you’d like to see integrated into the Baseline? Patches Welcome!
Why Baseline Matters
Value-prop for Devs
Value-prop for Downstream
117
Tying it all together
As the group settles into a working rhythm, we’re now ready to start engaging with the broader LF and ecosystem.
We’ll begin work on a “Baseline workflow” on how projects can “Get Baselined”, work on docs, education, and continue work on automation and attestations .
Tools Like LFX, Scorecard, and BP Badges will be outward signs for developers and consumers about the “Baselineness” of a project.
118
Future Workflow
119
Follow the ORBIT Working group
(Open Resources for Baselines, Interoperability, and Tooling) for more details - https://github.com/ossf/wg-orbit
OSPS Baseline: Get Involved
Is your organization a member of OpenSSF?
Questions? Contact membership@openssf.org
121
openssf.org/join
Legal Notice
Copyright © Open Source Security Foundation®, The Linux Foundation®, & their contributors. The Linux Foundation has registered trademarks and uses trademarks. All other trademarks are those of their respective owners.
Per the OpenSSF Charter, this presentation is released under the Creative Commons Attribution 4.0 International License (CC-BY-4.0), available at <https://creativecommons.org/licenses/by/4.0/>. You are free to:
The licensor cannot revoke these freedoms as long as you follow the license terms:
122