Open Source Summit North America 2025

As cyber threats become increasingly sophisticated, the traditional perimeter-based security model no longer suffices. Zero Trust Security offers a modern framework that assumes no entity—user, device, or application—can be trusted by default, emphasizing "never trust, always verify." But how can this framework be applied effectively within automated CI/CD pipelines like Jenkins?

In this talk, we’ll provide a practical introduction to Zero Trust Security, exploring its key principles and the critical role it plays in modern software delivery. Attendees will learn how to integrate Zero Trust practices into Jenkins pipelines using powerful open-source tools. From secrets management to policy enforcement and continuous vulnerability management, this session will provide actionable steps to secure the entire software development lifecycle.

Software supply chain attack is an emerging threat for today’s enterprises. An attacker first gets an internal network access of the target enterprise, typically by using social engineering. Next the attacker gets administrator access to a software supply chain of the enterprise. Finally the attacker injects a backdoor into a built artifact and steals confidential information or digital assets from the enterprise, or even worse from customers.

A critical attack surface here is the administrator of the software supply chain. Confidential Containers is an open source project to protect containers from administrators by using trusted execution environments (TEEs). It protects a Kubernetes pod from a cluster administrator by running the pod inside of a TEE and validating the pod by remote attestation.

This talk presents a use case of Confidential Containers to protect a Tekton task. You will understand how Confidential Containers protects a task and artifacts even when the cluster administrator is compromised.

As the number of software vulnerabilities grows, the need for robust, automated security practices in DevOps pipelines is more critical than ever. OpenSSF Scorecard, an initiative by the Open Source Security Foundation (OpenSSF), provides a framework for evaluating the security posture of open-source projects. Ortelius, an open-source platform and dashboard, builds on this foundation by offering continuous vulnerability tracking and management, integrating with tools like OpenSSF Scorecard and OSV.dev.

Adding to this ecosystem, Jenkins plays a pivotal role as a CI/CD powerhouse, making it an ideal candidate for advancing continuous vulnerability management. In this talk, we’ll explore how integrating Ortelius and OpenSSF Scorecard into Jenkins pipelines empowers teams to automate vulnerability scanning, track security metrics, and respond to threats more efficiently. Attendees will learn how to leverage these tools together to create a secure and automated development lifecycle.

Imagine your source repository is a kitchen, and the CI task that builds your software is a chef cooking soup. Most attempts to obtain the list of ingredients for the soup will fall into one of two categories.

"Source SBOM" tools gather the list of ingredients by scanning the entire kitchen. There are some recipes and ingredients in the kitchen, but are all of them relevant? Are they correct and complete? What if the chef looks up the recipe online and then orders the missing ingredients?

"Analyzed SBOM" tools try to derive the list of ingredients from the finished soup. This is hard to do well, impossible when the ingredients dissolve completely. And the tool has no chance of knowing where the ingredients came from.

How about we do this: Select the right recipe(s) for the soup. Buy all the ingredients ourselves. Leave them in the kitchen and lock the chef in there until the meal is done. We now have a complete list of ingredients (or a failed soup), and we know where we got them.

Meet Hermeto, a tool that enables your CI pipeline to lock the chef in the kitchen!

In 2023 Supply-chain Levels for Software Artifacts (SLSA) was released. It provided a framework for protecting software from tampering within the CI/CD workflow from source to publication. Now it’s nearing completion of the SLSA Source Track which brings a similar level of assurance to the management of source code.

The Source Track addresses the threat of tampering with source code within the repository and allows malicious changes to source to be attributed to the actors that introduced those changes. In addition, it provides a framework for recording additional results about source revisions such as if a code review was performed or if the source was analyzed by SAST tools.

We’ll cover how this track can prevent attacks like the 2021 attack against PHP where malicious commits were added to the PHP repository and how it can be used to ensure additional controls (like code review) are implemented to protect against attacks like the recent one against xz. Finally we'll discuss how the source track can be implemented in existing source control systems by examining a proof-of-concept that enables Source Level 3 without specialized support from the source control platform.

OIDC and workload identity are fantastic ways to improve the security of CI/CD workflows. They offer a mechanism to get rid of traditional long lived keys and access tokens, with many APIs offering ways to use these tokens across environments.

However, the security of identity federation is only as strong as the policies that back them. If used incorrectly, it can be exploited to gain access to sensitive resources and potentially compromise your supply chain to use your own CI/CD platform against you.

In this talk we'll do a deep dive on OIDC and identity federation. We'll look at some of the common risks that come while using it, and strategies to help secure your environment and define strong security policies.

This is the case study of how we changed how we ship software.

With thousands of customers, each in their own Kubernetes container, deploying updates was tough. Off-hours schedules meant it took over 24 hours to push a new version. If something broke, we had to scramble. Canary deployments let us update small groups of customers at a time. We built a tool to stop rollouts fast when issues appeared, limiting the damage.

In the past, new features went to everyone at once. Rolling back wasn't an option. If something failed it'd leave customers stuck in the mess. Now, using OpenFeature, we hide new functionality behind feature flags. We release features to small groups, gather feedback, and test internally for weeks. If things go wrong, we flip the flag off and move on.

This two-pronged approach lets us avoid risky big-bang releases. We went from deploying every 10 days to every 4, with fewer than 1% high-severity defects. Most of these are resolved before customers notice them.