OpenSSF Community Day North America 2026

In the context of secure systems, "transparency" is often a loaded term. We will propose a precise definition: the guarantee of discoverability and auditability. Transparency is the difference between a system that merely claims to be secure and a system that provides proof of its security claims.

This session offers a high-level primer on the principles of cryptographic transparency. We will discuss how to design transparent applications and explore the tooling available to create tamper-evident systems. We will examine how this pattern has already been used, from Certificate Transparency providing auditability for web PKI, Binary Transparency securing software delivery, and Key Transparency hardening messaging applications. We will demonstrate how transparency can be applied for emerging frontiers as well, such as AI model provenance and news authenticity.

Finally, we will discuss the ongoing specifications work to standardize transparency primitives and highlight opportunities to participate. Attendees will leave with a clear mental model for transparency by design, ready to build systems where accountability is a default feature, not an afterthought.

AMPEL, the Amazing Multipurpose Policy Engine (and L), is the latest open-source project (about) to land in the OpenSSF sandbox.

AMPEL is a policy engine designed to be embeddable and easy to use in modern CI/CD environments. It brings together verification of signed in-toto attestations against policies, mapped to security framework controls, enabling projects and organizations to demonstrate compliance with security frameworks.

The OpenSSF ecosystem groups tools that produce, manage, and verify security data. AMPEL was created to combine them into a solution that actually protects you.

Just name an OpenSSF project, and AMPEL has your back:
✓ Native Sigstore verification
✓ Universal SBOM policies with protobom
✓ SLSA provenance
✓ Built-in OpenVEX support
... and more.

These scenarios compose into a coherent solution to comply with common security frameworks, such as the OSPS Security Baseline or the CRA.

This is cryptographically probable compliance for everyone!
Come and meet AMPEL, its community maintained policy library, and watch our practical examples in this hands-on session that promises a use case for everyone.

Software supply chain risk assessments increasingly rely on Software Bill of Materials (SBOMs), yet their practical value is often tested under severe time constraints. In Mergers and Acquisitions (M&A) due diligence, Application Security (AppSec) teams are frequently required to assess large codebases and their third-party dependencies within days or weeks, where the goal is informed risk visibility rather than exhaustive remediation.

This talk presents a practitioner’s perspective on using SBOMs to prioritize software supply chain risk under tight M&A timelines. Drawing from real-world due-diligence engagements, it explores how AppSec teams analyze SBOMs to identify high-impact dependencies, assess transitive risk, and correlate vulnerability intelligence with open-source license obligations that may influence post-acquisition risk.

The session also addresses common challenges such as incomplete SBOMs, noisy vulnerability data, unclear license declarations, and limited exploit or usage context. The emphasis is on practical, risk-based prioritization techniques and legal-safe framing of findings.

Attendees will leave with practical guidance on using SBOMs as a decision-support mechanism, rather than just as compliance artifacts.

If you’ve ever set a branch protection rule or configured a security scan, you’ve already entered the world of GRC. You may not have realized it at the time, though, because GRC is often seen as a combination of spreadsheets and screenshots. Framing this through Gemara reveals a different reality: these security configurations don't exist in a vacuum; they work within a larger, interconnected architecture.

In this session, we’ll explore OpenSSF's Gemara Model to show you how your existing SDLC workflows can produce the compliance evidence you’ve been looking for. Join us to learn how to stop performing GRC as a chore, and start managing it as the engineering task it already is.

Many package ecosystems produce a comprehensive list of dependencies known as a lockfile. These files serve several purposes, ranging from optimizing application assembly to verifying package integrity and ensuring reproducible builds. Newer package ecosystems such as npm, cargo, and go modules incorporated lockfiles in their designs from the start. More recently, the Python community adopted a lockfile standard that works across multiple packaging tools, and dnf is experimenting with its own lockfile standard for RPM packages.

Using recent academic research, this session will describe the key requirements for lockfiles and apply them to one of the most widely adopted package ecosystems: Apache Maven. Through the experiences of the Maven Lockfile Plugin project, you will learn the challenges of building a backwards-compatible lockfile and the barriers to generating complete Maven lockfiles in all situations. This session will conclude with other attempts within the Maven ecosystem to provide similar lockfile capabilities and the hurdles to making these features more widely adopted.

In automotive software development—such as IVI (In-Vehicle Infotainment) software—many layers of the supply chain are involved, including automotive OEMs and Tier‑1 suppliers. Automotive OEMs, in particular, are required to manage a complex and multi‑layered software supply chain under strict safety and regulatory constraints.

To evaluate supply chain security efforts within software development, we have been conducting a feasibility study on applying SLSA, a supply chain security framework being developed by the OpenSSF.

In this session, we will share insights gained through our validation of SLSA adoption and discuss approaches to supply chain security in large-scale software development projects such as AAOS.

The W3C SWAG community group (which is linked with the OpenSSF Best Practices working group) recently ran a survey of web developers to see what web security features and technologies web developers are using and how they're using them. This talk will be a brief introduction to SWAG, an overview of the surprising results, and what it means for the work ahead. I will also touch on the topic of how web developers and web browser developers are responding to the requirements of the CRA.