What does it mean to be the Ambassador Chair?

The CD Foundation Ambassador Chair reviews all Ambassador applications and selects the new cohort every year. Once the cohort is announced, the chair is responsible for leading the Ambassador meetings, once a month, leading the Ambassador Slack Channel, and guiding the cohort in contributing to and representing the CD Foundation in content and at events.

The Ambassador Chair is a voting member of the DevRel Committee and a contributor to the TOC. The Ambassador Chair has the right to delegate the role of representing in TOC and Outreach to other Ambassador Program members as needed.

Message from current Ambassador Chair

Contributed by Kris Stern | Originally posted on jenkins.io

Jenkins Accepted to Google Summer of Code 2026

Based on the report’s data, maintaining private forks can cost up to 5,160 labour hours, or $258,000 USD, per release cycle.

By simply using OSS, organizations get 4.8 x ROI, but why stop there? Being an active member of an open source foundation offers the same bonus. Companies can also unlock further gains by contributing to the code or the community.

As Chris Aniszczyk put it in the report’s foreword: 

Read more about LTS releases and our support policy.

Looking Ahead

The Tekton Pipelines project continues to focus on:

• Performance – Reducing reconciliation overhead and improving startup times
• User experience – Better error messages, observability, and debugging tools
• Resolver improvements – Working towards v2 resolvers with enhanced caching and usability
• Kueue integration (TEP-0164) – Native support for Kueue job queueing to enable better resource management and fair-sharing in multi-tenant environments

We’re also making progress on our transition to the Cloud Native Computing Foundation (CNCF), which will provide Tekton with a neutral home and access to a broader ecosystem.

Get Involved

We invite you to try v1.9.0 LTS, provide feedback, and contribute to the project:

• GitHub Repository
• Documentation
• Community Slack (#tekton)
• Release Notes

Thank you to all the contributors who made these releases possible!

Name: Luke Philips
Pronouns: He/Him
Location: Steamboat Springs, Colorado

Who are you?

I work as a Principal Software Engineer at a financial services company, having previously been at many major Telco’s and Media companies before. I enjoy the intersection of technical challenges and sharing knowledge/experiences through the open source communities. Additionally, contributing to the occasional Wardley Map research group for strategic thinking and analysis of industries I have been in. I enjoy being active, as well as finding all the best coffeeshops and enjoying a good book.

Your hobbies?

Having grown up in Colorado I greatly enjoy all the “Colorado Things”. The great outdoors and stunning mountain ranges and the various activities amongst it all – hiking, trail running, mountain biking, skiing/backcountry skiing, camping. Additionally spending time advocating for local causes, most recently getting into transit support for my community. In lieu of TV, I watch way too much cooking YouTube.

What did you want to be when you were a kid?

Astronaut

What led you to a career in tech?

As a kid having assembled every Lego imaginable, as well as disassembly of any household appliance I could get my hands on – sometimes to the chagrin of my parents. Building and exploring, the schools I grew up at gave us very early Internet access (Unix terminals) and that just set off a long path of self-learning. 

Do you remember your first open source contribution?

As a teenager learning what Linux was (kernel 2.0 days) – finding the local LUG, asking questions/commenting on docs might be an early “contribution.” First GitHub commit was to Homebrew, with a new release of Vert.X

How did you get involved in the Continuous Delivery Foundation?

Some of the early collaborations with CDF and OpenGitOps, presenting at an early GitOpsCon/cdCon combined event – sharing about the success we had with CD and GitOps principles. Most recently CDEvents has become the “missing” piece I’ve been looking for, glueing together the complex “Application Delivery” space.

What’s your favourite thing/project/tech to work on?

A few years ago I purchased a new-to-me home as well as discovered the Home Assistant project. It has been a wild journey ever since, every aspect of my home now has a Grafana dashboard associated with it, I’ve overhauled my home’s electrical systems, and there are various protocols throughout the house.

Tell us about the thing you’re most proud of and why?

Partnering, helping, and collaborating with many of my colleagues to achieve their first conference talks. Every one was an incredible opportunity to connect more and share their brilliance with the broader community.

What is the best connection you’ve made through open source?

When you meet that person who created/maintains those obscure CLI, App, Database tools, etc.. that you become so dependent on in your day-to-day – it’s like a true rockstar moment.

What’s your favourite open source conference?

Am I allowed to say anything other than cdCon? ArgoCon has been special for me and its community has been great. 

What is your #1 tip for getting involved in the community?

Keep showing up and have patience. My first GitHub contribution was also rejected, as well as many early conference talks, though I kept learning, improving, getting involved in other ways and found success.

Where can we find you?

Connect with Luke  Linktree

More from Luke

Watch the CDEvents, GitOps, and Argo CD talks and podcast Luke has recently been a part of.

The Security Gap in CI/CD Pipelines

Jenkins excels at automation before deployment, building, testing, scanning, packaging, and releasing software. Pre-deployment security tools such as SCA and SAST integrate directly into the pipeline, helping developers catch issues early with our ‘shift-left,’ offensive, commitment. 

But the threat landscape has shifted right and needs defensive measures:

• New CVEs are published every day
• Open source packages become vulnerable long after release
• Attackers exploit known weaknesses in production faster than organizations can patch
• Distributed, cloud-native environments make it harder to know exactly what is running where

By the time a vulnerability is announced, the code is already deployed. Jenkins pipelines have long finished their job, and the software continues running, often silently exposed.

This is the “last mile” of DevSecOps where most teams struggle. They know what they built but not what is actually running. They know a new vulnerability exists, but not which environments it affects. And they know it must be remediated quickly, yet lack a clear path to resolution.

Introducing Ortelius: Post-Deployment Intelligence for Jenkins Users

Ortelius, a sandbox project under the Continuous Delivery Foundation, was created to solve this last-mile challenge. It provides a standardized, open-source method for tracking what has been deployed, where, and with which dependent open-source packages.

Ortelius creates a deployment digital twin, a living model of every application version across clusters and environments. By mapping SBOM metadata to real deployments, Ortelius gives teams the one capability CI/CD pipelines cannot deliver on their own:

• Real-time insight into how newly discovered vulnerabilities impact running systems.

For Jenkins users, this shifts security thinking from a pre-deployment exercise to a continuous defensive posture.

Why the Jenkins Community Should Care

A New Architecture for the CDF Community: The Deployment Digital Twin

Ortelius introduces a concept that is rapidly becoming essential to large-scale DevSecOps: the deployment digital twin.

This model continuously maps:

• Component versions
• Open source libraries
• SBOM details
• Deployment locations (clusters, namespaces, environments)
  

With this real-time knowledge, newly published vulnerabilities can be traced instantly to affected applications, something CI pipelines alone cannot do.

For Jenkins users, a digital twin becomes the authoritative record of “what’s really running,” allowing security teams and developers to respond with surgical precision.

Post-Deployment Remediation: The Missing Step in Secure Delivery

Currently, the Ortelius community is working on auto-remediation once a new vulnerability is identified. In this step,  Jenkins re-enters the picture:

Ortelius gives Jenkins pipelines actionable intelligence, enabling them to:

• Automatically generate targeted remediation branches
• Rebuild affected components with secure package versions
• Trigger re-tests and approvals
• Roll out patched versions across environments
• Create auditable compliance records
  

By connecting vulnerability impact → code change → rebuild → redeploy, Jenkins becomes an integral component of a trusted, closed-loop remediation workflow.

Why This Matters Now

The software supply chain is increasingly weaponized. Attackers move faster than traditional patch cycles. Developers face alert fatigue. Platform teams must protect distributed, cloud-native workloads running across hybrid environments.

The CDF community is uniquely positioned to champion a new model of security, one that extends beyond the build pipeline into real-time production awareness.

Post-deployment detection and remediation is no longer optional.  It is the final mile of continuous delivery.  And Ortelius is giving Jenkins users a powerful, open source way to close the gap, including: 

Join the Movement: Help Build the Future of Defensive DevSecOps

Ortelius is a community-driven project, and its roadmap is shaped by practitioners who understand the challenges of modern software delivery. If you are a Jenkins user, DevSecOps engineer, or platform leader interested in strengthening post-deployment security, we invite you to get involved.

Join the Ortelius Open Source Project at Ortelius and bring your expertise to the community, shaping the future of post-deployment vulnerability defense.

Together, we can extend the principles of continuous delivery into continuous protection—and build a safer, more resilient open source ecosystem for everyone.

The CDF Awards process will start in March and end in May 2026. We are looking for two (2) award officers to observe the nomination and voting to ensure the transparency and sanctity of our awards. View Award Guidelines and 2026 Award Winners.

Commitment

• 1-2 hours a month for 3 months
• Review documentation, forms, and results
• Communication will be done asynchronously

Applications

Applications are now open and will close on Sunday, February 22, 2026 at 11:59 PM PST.

Thank you to last year’s award officers: Giorgi Keratishvili and Kris Stern. If you message them on the CDF Slack, they’d be happy to tell you about their experience.

In modern software delivery, speed without security is a false economy. Every commit, container, and deployment represents a potential point of compromise; yet it’s also an opportunity to embed trust. 

The CI/CD Security Blueprint for Open Source Tooling helps teams visualize how open source tools, modern frameworks, and continuous validation converge to build resilient, transparent software pipelines.

The Problem We’re Solving

Most pipelines are built for velocity, not veracity. Developers commit code quickly, builds trigger automatically, and deployments run within minutes — but too often, verification trails are incomplete or nonexistent. The blueprint addresses that gap by making security visible, measurable, and repeatable across three critical phases of the Continuous Integration/Continuous Delivery (CI/CD) lifecycle.

(This set of tools is only an example, you can use other tools. Check out our Cybersecurity Guide for more.)

Phase 1: Code and Pre-Build

Security begins long before the first build. This phase focuses on the source of truth: code, dependencies, and configuration. Teams can scan repositories for vulnerabilities and secrets before merging, analyze code for unsafe patterns or outdated dependencies, and generate an early Software Bill of Materials to establish dependency visibility.

Open source tools such as Semgrep and OSV-Scanner make these practices accessible and automatable. When integrated directly into pull requests or pre-commit hooks, they ensure unsafe code never reaches the build stage. This is where security truly shifts left…catching issues before they can propagate downstream.

Phase 2: Build and Deploy

Once code is merged, trust must be constructed. The build and deploy phase verifies both what is being built and how it is being built. Artifacts should be scanned, signed, and accompanied by provenance data and attestations.

Tools like Trivy, Cosign, and Open Policy Agent (OPA) support this process. Trivy identifies vulnerabilities in containers and artifacts, Cosign ensures each build is cryptographically signed, and OPA enforces the rules that govern what can be promoted or deployed. Together, they produce verifiable outputs: every artifact can prove its origin, composition, and integrity.

Phase 3: Post-Deploy

Security doesn’t end at deployment; it evolves. Once code runs in production, new data becomes the input for securing the next release. Teams can monitor workloads for anomalies, detect configuration drift in real time, and feed those findings back into earlier stages.

Open source tools such as Falco and OPA extend visibility into runtime behavior. Post-deploy monitoring closes the loop between development and operations, turning detection in one release into prevention in the next.

The Role of Platform Engineering

Platform engineering has become the connective tissue between development, operations, and security. Instead of forcing each team to assemble its own CI/CD pipeline, platform engineers create secure, reusable blueprints…pre-built paths that integrate open source tooling and policy by default.

In practice, platform engineering operationalizes the CI/CD Security Blueprint. Code and Pre-Build controls such as Semgrep and OSV-Scanner are built into the developer experience. Build and Deploy gates for scanning, signing, and policy enforcement are standardized within shared pipelines. Post-Deploy monitoring through Falco and OPA is unified under centralized observability systems.

This model transforms security from a checklist into a platform capability. Developers move faster not because guardrails are removed, but because trust is built into the environment itself. Platform engineering turns the blueprint into infrastructure; something consistent, observable, and scalable across teams.

Continuous Validation: The Living Loop

Beneath the three stages runs the engine of continuous trust: evidence, attestations, SBOMs, and monitoring. Each build, deployment, and runtime event generates artifacts that verify the software’s integrity. Together, these form a cycle of continuous validation, not a one-time audit but a living feedback loop between tools, frameworks, and teams.

Security evidence becomes a language that development and compliance can both understand.

Framework Alignment

The blueprint naturally aligns with frameworks such as the NIST Secure Software Development Framework (SSDF), NIST CSF 2.0, and the EU Cyber Resilience Act (CRA). Instead of referencing them as checkboxes, the blueprint translates their principles into daily automation. For example, identifying dependencies corresponds to running OSV-Scanner; protecting artifacts aligns with signing them through Cosign; and monitoring workloads is realized through Falco.

Policy statements become actions, and compliance becomes measurable and verifiable by design.

A Culture Shift in Security

This approach is not about adding more tools but about designing security as an architectural layer that developers can see, trust, and extend. In open source, transparency is a strength. When every phase of the CI/CD process is observable and verifiable, trust becomes a measurable quality rather than a promise.

Discover other tools that could work for you and your organization in our full CI/CD Cybersecurity Guide.

@WorkflowInterface
public interface SleepForDaysWorkflow {
    @WorkflowMethod
    void run();
}

public class SleepForDaysWorkflowImpl implements SleepForDaysWorkflow {

    private final SendEmailActivities emailActivities =
            Workflow.newActivityStub(
                    SendEmailActivities.class,
                    ActivityOptions.newBuilder()
                            .setStartToCloseTimeout(Duration.ofSeconds(10))
                            .build());

    @Override
    public void run() {
        while (true) {
            // Activities already carry retries/timeouts via options.
            emailActivities.sendEmail();

            // Pause the workflow for 30 days before sending the next email.
            Workflow.sleep(Duration.ofDays(30));
        }
    }
}

@ActivityInterface
public interface SendEmailActivities {
    void sendEmail();
}

There’s some interesting things to note about this Workflow:

1. Workflows and Activities are just code, so you can test them using the same techniques and processes as the rest of your codebase.
2. Activities are automatically retried by Temporal with configurable exponential backoff.
3. Temporal manages all the execution state of the Workflow, including timers (like the one used by Workflow.sleep). If the Worker executing this workflow were to have its power cable unplugged, Temporal would ensure another Worker continues to execute it (even during the 30 day sleep).
4. Workflow sleeps are not compute-intensive, and they don’t tie up the process.

You might already begin to see how Temporal solves a lot of the problems we had with Clouddriver. Ultimately, we decided to pull the trigger on migrating Cloud Operation execution to Temporal.

Cloud Operations with Temporal

Today, we execute Cloud Operations as Temporal workflows. Here’s what that looks like.

1. Orca, using a Temporal client, sends a request to Temporal to execute an UntypedCloudOperationRunner Workflow. The contract of the Workflow looks something like this:

@WorkflowInterface
interface UntypedCloudOperationRunner {
  /**
   * Runs a cloud operation given an untyped payload.
   *
   * WorkflowResult is a thin wrapper around OutputType providing a standard contract for
   * clients to determine if the CloudOperation was successful and fetching any errors.
   */
  @WorkflowMethod
  fun  run(stageContext: Map<string, any?="">, operationType: String): WorkflowResult
}
</string,>

2. The Clouddriver Temporal worker is constantly polling Temporal for work. A worker will eventually see a task for an UntypedCloudOperationRunner Workflow and start executing it.

3. Similar to before with resolution into AtomicOperations, Clouddriver does some pre-processing of the bag-of-fields in stageContext and resolves it to a strongly typed implementation of the CloudOperation Workflow interface based on the operationType input and the stageContext:

interface CloudOperation {
  @WorkflowMethod
  fun operate(input: I, credentials: AccountCredentials): O
}

4. Clouddriver starts a Child Workflow execution of the CloudOperation implementation it resolved. The child workflow will execute Activities which handle the actual cloud provider API calls to mutate infrastructure.

5. Orca uses its Temporal Client to await completion of the UntypedCloudOperationRunner Workflow. Once it’s complete, Temporal notifies the client and sends the result and Orca can continue progressing the deployment.

Sequence diagram of a Cloud Operation execution with Temporal

Results and Lessons Learned from the Migration

A shiny new architecture is great, but equally important is the non-glamorous work of refactoring legacy systems to fit the new architecture. How did we integrate Temporal into critical dependencies of all Netflix engineers transparently?

The answer, of course, is a combination of abstraction and dynamic configuration. We built a CloudOperationRunner interface in Orca to encapsulate whether the Cloud Operation was being executed via the legacy path or Temporal. At runtime, Fast Properties (Netflix’s dynamic configuration system) determined which path a stage that needed to execute a Cloud Operation would take. We could set these properties quite granularly — by Stage type, cloud provider account, Spinnaker application, Cloud Operation type (createServerGroup), and cloud provider (either AWS or Titus in our case). The Spinnaker services themselves were the first to be deployed using Temporal, and within two quarters, all applications at Netflix were onboarded.

Impact

What did we have to show for it all? With Temporal as the orchestration engine for Cloud Operations, the percentage of deployments that failed due to transient Cloud Operation failures dropped from 4% to 0.0001%. For those keeping track at home, that’s a four and a half order of magnitude reduction. Virtually eliminating this failure mode for deployments was a huge win for developer productivity, especially for teams with long and complex deployment pipelines.

Beyond the improvement in deployment success metrics, we saw a number of other benefits:

1. Orca no longer needs to directly communicate with Clouddriver to start Cloud Operations or poll their status with Temporal as the intermediary. The services are less coupled, which is a win for maintainability.
2. Speaking of maintainability, with Temporal doing the heavy lifting of orchestration and retries inside of Clouddriver, we got to remove a lot of the homegrown logic we’d built up over the years for the same purpose.
3. Since Temporal manages execution state, Clouddriver instances became stateless and Cloud Operation execution can bounce between instances with impunity. We can treat Clouddriver instances more like cattle and enable things like Chaos Monkey for the service which we were previously prevented from doing.
4. Migrating Cloud Operation steps into Activities was a forcing function to re-write the logic to be idempotent. Since Temporal retries activities by default, it’s generally recommended they be idempotent. This alone fixed a number of issues that existed previously when operations were retried in Clouddriver.
5. We set the retry timeout for Activities in Clouddriver to be two hours by default. This gives us a long leash to fix-forward or rollback Clouddriver if we introduce a regression before customer deployments fail — to them, it might just look like a deployment is taking longer than usual.
6. Cloud Operations are much easier to introspect than before. Temporal ships with a great UI to help visualize Workflow and Activity executions, which is a huge boon for debugging live Workflows executing in production. The Temporal SDKs and server also emit a lot of useful metrics.

Execution of a resizeServerGroup Cloud Operation as seen from the Temporal UI. This operation executes 3 Activities: DescribeAutoScalingGroup, GetHookConfigurations, and ResizeServerGroup

Lessons Learned

With the benefit of hindsight, there are also some lessons we can share from this migration:

1. Avoid unnecessary Child Workflows: Structuring Cloud Operations as an UntypedCloudOperationRunner Workflow that starts Child Workflows to actually execute the Cloud Operation’s logic was unnecessary and the indirection made troubleshooting more difficult. There are situations where Child Workflows are appropriate, but in this case we were using them as a tool for code organization, which is generally unnecessary. We could’ve achieved the same effect with class composition in the top-level parent Workflow.

2. Use single argument objects: At first, we structured Workflow and Activity functions with variable arguments, much as you’d write normal functions. This can be problematic for Temporal because of Temporal’s determinism constraints. Adding or removing an argument from a function signature is not a backward-compatible change, and doing so can break long-running workflows — and it’s not immediately obvious in code review your change is problematic. The preferred pattern is to use a single serializable class to host all your arguments for Workflows and Activities — these can be more freely changed without breaking determinism.

3. Separate business failures from workflow failures: We like the pattern of the WorkflowResult type that UntypedCloudOperationRunner returns in the interface above. It allows us to communicate business process failures without failing the Workflow itself and have more overall nuance in error handling. This is a pattern we’ve carried over to other Workflows we’ve implemented since.

Temporal at Netflix Today

Temporal adoption has skyrocketed at Netflix since its initial introduction for Spinnaker. Today, we have hundreds of use cases, and we’ve seen adoption double in the last year with no signs of slowing down.

One major difference between initial adoption and today is that Netflix migrated from an on-prem Temporal deployment to using Temporal Cloud, which is Temporal’s SaaS offering of the Temporal server. This has let us scale Temporal adoption while running a lean team. We’ve also built up a robust internal platform around Temporal Cloud to integrate with Netflix’s internal ecosystem and make onboarding for our developers as easy as possible. Stay tuned for a future post digging into more specifics of our Netflix Temporal platform.

Acknowledgement

We all stand on the shoulders of giants in software. I want to call out that I’m retelling the work of my two stunning colleagues Chris Smalley and Rob Zienert in this post, who were the two aforementioned engineers who introduced Temporal and carried out the migration.