Open Source Summit + Embedded Linux Conference North America 2026

Several guidelines such as FinOps Framework and Green Software Patterns provide principles for cloud optimization, but they include both abstract ideas and practical details with multiple concerns like cost and sustainability. This makes human reviews inconsistent. In this talk, we show how such guidance can be evaluated consistently in CI using Open Policy Agent (OPA).

We present a two-layer policy design: evaluation logic stays small and readable in Rego, while policy rules such as thresholds and exceptions are defined in structured JSON. This separation makes policies easier to maintain by contributors without Rego expertise. CI checks consume an input schema derived from configuration or IaC artifacts and return review-ready decisions—allow, warn, or block—along with a rule identifier, rationale, and a suggested follow-up.

What you will learn:
・How to extract checkable criteria from abstract guidance
・How to design a stable input schema
・How to structure a rules catalog so that policy evaluation remains possible even when multiple concerns interact
・How to run a policy change process that does not depend on a small set of Rego experts

"FreeBSD is only for servers.” “FreeBSD is for hardcore engineers.” We have all heard the myths. In this talk, Deb shares what happened when she decided to run FreeBSD on a modern laptop. Learn more about her journey to getting this rock-solid operating system on her laptop, and how it is far more accessible than its reputation suggests.

Kubernetes documentation is facing a veering wind in users. Since the start of 2026, there have been twice as many global users as there were in 2025. With 15 localizations of the Kubernetes docs and 11.59 million active users in 2025, and 3 yearly releases, maintaining Kubernetes documentation and growing contributors can be daunting. This session explores how the Kubernetes project developed a community, processes, and practices to grow contributors and aid worldwide adoption.

In February 2024, about 10% of PyPI uploads used Trusted Publishers. By October 2025, that number exceeded 25%, a massive shift toward eliminating long-lived credentials. For maintainers still using stored API tokens, this talk demonstrates why and how to modernize.

Trusted Publishing uses OpenID Connect (OIDC) to generate short-lived, automatically-scoped tokens from CI/CD environments. No passwords. No API tokens to rotate. No secrets stored in repositories.

This talk walks through setting up Trusted Publishers for GitHub Actions (as an example, but others are available), explains the security model in accessible terms, and shares case studies, including how Sigstore integration enabled forensic investigation of the 2024 Ultralytics compromise.

Attendees will learn the step-by-step setup process, common pitfalls and troubleshooting, and migration strategies for maintainers with many packages. The session also covers why token removal is critical when Trusted Publishing in place, and when restricted API tokens remain the appropriate fallback. Whether maintaining one package or a hundred, attendees will leave with everything needed to adopt credential-free publishing.

Beyond version control, git is an incredibly powerful code exploration and debugging toolkit hiding in plain sight. In this talk, we'll look under the hood at how git stores, references, and tracks data, and then leverage those internals in practical, real-world workflows to navigate and debug code.

We'll walk through hands‑on examples using tools such as reflog, blame, log -S/-G, pathspecs, grep, and bisect to answer questions developers face every day: Where did this behavior come from? Why is this code like this? and When did this bug appear?

We'll also discuss best practices for maintaining clean, informative git history; because well-crafted commits make these tools dramatically more effective. Whether you're new to git's advanced commands or already comfortable with the plumbing layer, you'll leave with actionable techniques to understand codebases faster and get more value from the tool you already use every day.

SBOMs tell you what's in your software. They don't tell you what you're allowed to do with it. License and attribution data is often missing or ambiguous -- a LICENSE file says MIT, but source files have Apache-2.0 headers. SBOM or not, you still don't know what to put in your notice file.

ClearlyDefined, an Open Source Initiative project, fills in that missing data. It runs automated license scans, then lets the community curate the results -- fixing misidentified licenses, adding missing attributions, and resolving conflicts between what a package claims and what its source files say.

In this session, I'll cover:

- Why SBOMs fall short on licensing: what's typically missing and where the gaps are worst
- How ClearlyDefined's harvest-curate pipeline works, with a walkthrough of tracing a component from ambiguous scan to curated definition
- How curations get contributed back upstream and why it matters for projects themselves, not just consumers

This talk is for anyone who's tried to build a license compliance workflow and found that the data isn't there yet.

Traditional developer relations relies on metrics that favor product adoption, but successful open source developer relations demands a more nuanced approach. Your organizational role in and goals around open source projects dictate your strategy.

We'll first dissect where and how open source developer advocacy diverges from proprietary developer relations strategies. We’ll then dive into four distinct engagement models, metrics of successful advocacy in each, and why success in one cannot necessarily be transferred to another:
* The Adopter: Companies advocating for an open source technology used heavily internally.
* The Champion: Companies serving as a major contributor to a mature open source project and its ecosystem.
* The Business: Companies building a commercial offering around an existing open source technology.
* The Founder: Companies open sourcing a new project and building its community from zero.

Attendees will leave with a clear framework for diagnosing their organization’s role in the open source ecosystem and an understanding of the which metrics, communication channels, and contribution strategies will actually lead to sustainable community growth and impact.

As a sister foundation to the Continuous Delivery Foundation (CDF) under the auspices of The Linux Foundation, the Open Source Security Foundation’s (OpenSSF) mission is to make it easier to sustainably secure the development, maintenance, release, and consumption of open source software (OSS). This includes fostering collaboration within and beyond the OpenSSF, establishing best practices, and developing innovative solutions.

In this hour long session, we’ll connect real problems to OpenSSF solutions, then invite OpenSSF Working Group Leads and Project Maintainers to demo their respective projects in shortlightning rounds that show you how they’ll make your DevOps, CI/CD, or Platform Engineering lives easier to secure!

Open source used to mean something simple: the code is open, the community builds it, and everyone benefits. That world is gone. Today, billion-dollar companies release model weights and call it "open source"

Projects launch with permissive licenses but lock their APIs behind paywalls. Foundations host projects where one vendor controls 95% of the commits. And a new generation of developers is entering open source through AI-generated pull requests they barely understand.

I've spent 7 consecutive Kubernetes release cycles on the release team, helped build and maintain Kargo - a OSS project for GitOps continuous delivery and worked as a CNCF Ambassador helping new contributors navigate this ecosystem

I've watched the definition of "open source" stretch, bend & sometimes break in real time.

This talk is about the real problems developers face today when they try to contribute to, depend on, or build careers around open source projects that don't play by the old rules. I'll share what I've learned about spotting "open-washing" evaluating project health beyond the GitHub star count, and building genuine community in an era where the incentives have fundamentally shifted.

Secure Boot is often described using cryptography-heavy terminology, vendor-specific flows, and complex diagrams that make it intimidating for embedded developers.
This talk explains Secure Boot for embedded Linux systems from first principles, using simple language and clear mental models.

We start by answering why Secure Boot exists, then walk step by step through the boot process. Concepts like Root of Trust and signature verification are explained without assuming prior security or cryptography background.

The session focuses on what actually happens at boot time, not on vendor marketing or abstract theory. Real-world examples from common embedded Linux systems are used to illustrate how Secure Boot is implemented and where it can fail if misunderstood.

By the end of the talk, attendees will be able to explain Secure Boot in their own words, understand its guarantees and limitations, and reason about Secure Boot designs in real embedded products.

Deploying apps in containers is easier than ever, but securing the image these containers come from is a dynamic security problem that on its surface has no single best answer. So when it comes to what risk you may face and what risk you are willing to accept, one of the questions that may come up is if snowflake-y multi architecture risks are something you are willing to digest?

With multi arch images, based on the system it is deployed to, its vulnerabilities profile may look different than any of the other supported systems. So in this talk I will be demonstrating a security tool agnostic way to handle identifying and remediating these threats. I will go through how anyone (at any level of security experience) can automate container security across pipelines without slowing down development. Attendees will walk away with a new understanding of the importance of minimizing exposure to these risks, as well as a clearer understanding of the layered setup of multi arch container images (index manifest, platform manifest, and image manifest). And without a doubt, walk away with container image security and not unmanaged risk, something they are willing to digest.

Your organization has a policy requiring all artifacts to pass security scanning before deployment. Simple enough. But you use three CI systems, so Team A implements it in Jenkins with a Groovy shared library, Team B uses a GitHub Actions reusable workflow, and Team C builds it into GitLab CI includes.

Same intent. Three implementations. Three syntaxes. Three maintenance burdens.

Now an auditor asks: "Prove these are equivalent."

This lightning talk examines what happens when policy lives inside tools versus above them. We'll look at an architectural pattern in which tools emit events upward and receive decisions downward via CDEvents, while policy logic lives in a single, auditable location. The tools keep doing tool things. Nothing changes, but everything works.

You'll leave with one question worth asking in your next architecture review: "Where does our policy actually live?" The answer has implications for maintenance burden, audit readiness, and the extent to which consistent governance can scale.

Many hear the word "Argo" and immediately think "GitOps" with the ability to sync what's in a git repo with what's in a live Kubernetes environment. However, "Argo CD" is just one of several tools within the Argo ecosystem.

These other tools include:
- Rollouts - Move web traffic from an old to a new version of adeployment
- Workflows - Perform work in multiple steps, or as a DAG
- Events - Perform a variety of triggers based on a variety of potential events

These tools have a lot of use and can automate otherwise mundane tasks and lessen the risks associated with change.

Each will get given an overview of how they work and how they can be useful in isolation. Then we will combine them to solve different tasks. Examples will range from practical to silly, keeping healthy parts "educational" and "entertaining".