Open Source Summit + Embedded Linux Conference North America 2026

It's Friday afternoon, and you've got plans for this evening. You've just finished the feature. you push to main and click deploy. OR DO YOU?
Let's talk about Friday deployments and what they can teach us.

A talk about platform engineering, DevOps, DevSecOps, sprawl, chaos, compliance, and security. Why engineer an Internal Developer Platform when I have DevOps? DevOps works fine when you are a 20 person start-up but it often doesn't scale to Enterprise level development efforts. When you have 3000 developers with different needs and you are responsible for EO compliance and security a modular self-service platform is a good choice to build. In this talk I cover the challenges we have faced in a 3000 developers enterprise and how we are working to address them. I also cover how we are working on automating, integration, and scaling the creation of our internal developer platform. Leveraging SBOMs, SLSA, and other tools to help build out a secure and compliant platform. Attendees will learn the benefits and challenges of Platform Engineering
Attendee Takeaways
Answers for the following questions:
- Do we need a Platform Engineering Team?
- Is an IDP the right solution for my situation?
- What does a large scale IDP look like?
- What does it take to support a large scale IDP?
- What does security and compliance look like in an IDP?

Many cloud-native GitOps systems quietly treat a Git merge as both a change proposal and a deployment authorization. While this works in low-risk environments, it collapses two very different responsibilities into a single decision. As systems grow more complex, that shortcut creates ambiguity around authorization, accountability, and audit trails that many environments simply cannot tolerate.

In this lightning talk, we’ll reframe that assumption as a cloud-native architectural concern, not just a tooling or security issue. Using GitOps as the example, we’ll look at how proposal, approval, and enforcement often become unintentionally coupled, and why that coupling makes it harder to reason about who is actually allowed to deploy.

The talk will walk through the architectural implications of letting Git act as the final authority, including where deployment decisions truly occur and how auditability and accountability can be lost when authority boundaries are unclear. We’ll then show how treating deployment authorization as a first-class architectural concept leads to clearer responsibility boundaries and more defensible cloud-native systems.

Somewhere along the way, the security ecosystem started asking you to add more steps, update more plugins, and generate more outputs without asking what that actually costs you.

We asked for feedback during a lunch time session at cdCon last year. The feedback was blunt, honest and exactly why we are back for this open-floor discussion hosted by the OpenSSF Developer Relations (DevRel) community. No slides, no demos, no pitches. This is a no-shame venting session with purpose; bring your lunch, your coffee, and your honest feedback. We want to hear from the people implementing and operating these tools. Share where security tools are missing the mark and what's standing between "this is a good idea" and "this is actually working for us."

This session leads directly into sessions with OpenSSF project maintainers, so the people who can act on your feedback will already be in the room.

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 software is foundational to modern application development, but it has also become one of the fastest-moving and hardest attack surfaces to defend. For years, organizations have relied on “shift-left” security to catch vulnerabilities early in the lifecycle. While necessary, this approach alone is no longer sufficient. New vulnerabilities are disclosed daily, often long after software is deployed, leaving IT teams struggling to understand what is truly at risk in production and how quickly they must respond.

In this session, Tracy reframes software supply chain security around the realities of live systems. She explains why teams must move beyond offensive, prevention-only strategies and refocus on rapid detection, prioritization, and response for newly reported vulnerabilities attacking live systems. Tracy also addresses how the pursuit of a zero-vulnerability posture has driven alert fatigue and burnout among developers, security teams, and CIOs.

Attendees will learn how to manage vulnerability alert noise, shorten response times, and focus remediation, protecting open-source-driven systems without slowing delivery or exhausting the teams responsible for them.

GitOps promises safety and automation, but it will faithfully ship your mistakes at scale. With AI-assisted coding and emerging autonomous agents in the loop, those mistakes now move faster than humans can fully reason about their impact.

This talk dissects real-world GitOps failures where tiny configuration changes triggered outages, overly trusted pipelines amplified risk, and AI-generated patches were merged without understanding their consequences. None of these incidents were tooling failures. They were safety failures.

We’ll show how teams put guardrails back in place by enforcing policy before merge, using progressive rollouts to contain blast radius, applying Crossplane constraints to keep infrastructure changes reversible, and adding automated verification gates that catch problems before they reach production.

Security frameworks such as SLSA require software builds to run in isolated environments to guarantee they are “free of unintended external influence”. In practice, this means full control of the runtime environment and every dependency entering a build, ensuring no malware slips into released software
But how can you verify isolation after the fact? How do you know a container image or binary was compiled in a truly hermetic environment, free from tampering processes or hidden tooling? Can you confidently prove your release used only the dependencies declared in your SBOM?
In this talk, Marina and Puerco will demonstrate practical techniques to verify build isolation and runtime characteristics. Want cryptographic proof of hermetic builds? We’ll show it. Need confidence in software components and complete SBOM coverage? Covered. Trace provenance to the exact VM that executed the build? Absolutely.
Using Cocoon, an open source build packager running inside Edera Protect isolated zones, we will verify attested machine identity via SPIFFE SVIDs, environment features, and SBOM completeness, all enforced with reusable policy code powered by technologies like in-toto, SLSA and Sigstore.

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.

In this talk, I'll show how what happens DURING the build and deployment can be fatal.
Using eBPF, we created an Open Source app that monitors the kernel in real time to detect access to secrets, suspicious commands, and data exfiltration at the exact moment they occur.
In my consulting work, I've seen real-world scenarios where compromised runners handed over database secrets and cloud keys without anyone noticing.
The pipeline is a huge blind spot in current security.