🎙️ Submit your talk for: OpenSSF Community Day Europe by July 12

Tag

Open Source Security

May 05
Love0

What’s in the SOSS? Podcast #60 – S3E12 Packaging, Transferring, and Deploying Software in Air-Gapped Environments with Zarf

By Podcast

Summary

Host Sally Cooper is joined by Brandt Keller, a Staff Software Engineer at Defense Unicorns and Maintainer of the OpenSSF Sandbox Project, Zarf. Brandt discusses Zarf’s origins as a tool designed to reliably package, transfer, and deploy software components (like container images and Helm charts) specifically for critical, air-gapped environments that lack internet connectivity. The conversation explores Zarf’s evolution, highlighting its current role in introducing security gates, improving transparency, and consolidating various management and SBOM tools into a single, declarative workflow. Finally, Brandt explains how Zarf’s declarative manifest model is helping to secure open source software by reducing the cognitive burden on maintainers and giving integrators confidence in upstream artifacts.

Conversation Highlights

00:01: Welcome and Introduction to Brandt Keller and Defense Unicorns
02:01: What is Zarf and its history: Solving the air-gapped use case
04:33: Zarf’s critical function today: Security, transparency, and packaging
09:18: How Zarf has evolved: From niche tool to agnostic distribution and GitOps integration
12:07: Zarf’s role in OpenSSF and securing open source software
16:05: Rapid Fire and Call to Action (Zarf.dev)

Transcript

Sally Cooper (00:01.748)
Hello, hello, and welcome to What’s in the SOSS, where we talk to amazing people that make up the open source ecosystem. These are engineers, developers, maintainers, researchers, and all manner of contributors that make open source so great. I’m Sally, and today I’m really excited to be joined by Brandt Keller from Defense Unicorns. Brandt, thank you so much for being here.

And to get us started, can you tell our listeners a little bit about yourself, your role, and the kind of problems you focus on at Defense Unicorns?

Brandt Keller (00:35.742)
Absolutely. Thanks for having me. so yes, I’m Brandt Keller, primarily, a Staff Software Engineer at Defense Unicorns where I get to, know, I have the privilege of getting to focus on open source software, and maintaining that across both the open source software, projects that we have created as well as kind of the intersection of all of the things that we depend on as a company, we want to be able to be, you know,

appropriate stewards for not only consuming, but also trying to, you know, identify how we can contribute back. And so my role in particular is that of a maintainer for Zarf, which is an OpenSSF Sandbox Project. And outside of that, trying to be more of a, you know, kind of advocate in a few different spaces.

The software supply chain integrity group, working group under the OpenSSF. I try to be a contributor there, in the CNCF spaces. also contribute to, the security and compliance technical advisory group as a technical lead. And so kind of, you know, broad span, but have the definitive privilege of getting to kind of work with communities, build communities, and build technology.

Sally Cooper (02:01.972)
Oh, wow. This is so exciting to have you on the show, especially to talk about Zarf. So you mentioned Zarf. And I was just wondering if you could tell our listeners, I’m sure many of them know what Zarf is. But for those who don’t, what is Zarf and what’s its history?

Brandt Keller (02:19.02)
Yeah, for Zarf in particular, it’s, it’s evolved for sure. But I think kind of at the, at its cusp, it’s always been about trying to take this process of like, where does our software come from? and that the answer to that is varying and nuanced for everyone. but wherever it comes from, let’s try to find a way that we can package it up in a way that’s reliable and repeatable to make it secure. Ultimately, ultimately we really want to lean into that security posture.

and so what happens is software comes from many different places. people are running Kubernetes everywhere. and they have to collect all the disparate puzzle pieces in order for things to run. They have to collect their container images, their helm charts, every other file that they need to run an application. Maybe it’s their application. Maybe it’s an open source application, that their environment relies on. and we want to make that.

As easy as possible in such a way that it’s, you know, very transparent. You have everything you need. And when I say that, you know, you can maybe get to your environment and find out that you missed a piece and maybe that’s okay. But for Zarf in particular, we’ve always built for the air gapped use case, the most critical environments that don’t have connectivity back to any upstream internet connection. they have a pretty big problem here where there is no reaching back and grabbing that thing. You have to go back out and bring it back in. And that’s, been a lot of consternation for people who operate in these environments. so. Zarf really wants to make it. Let’s let’s package all that up into a single archive and make it so it’s easily transferable. It’s repeatable. So if somebody wants to take that same set of applications.

They can package it up and it’s declarative. The manifest really supports this. and in the end we have made it so that it’s, it’s a lot more repeatable to deploy to air-gapped environments where typically that has always been a lot of a juggling of many different artifacts and many different problems.

Sally Cooper (04:33.275)
Wow, yeah, that context is really helpful, especially for understanding where ZARF came from and what it was originally designed to solve. And from there, it kind of naturally leads to how ZARF is applied today. I was wondering if you could differentiate when trying to solve distinct critical environment problems.

Brandt Keller (04:53.442)
I think in the way that it’s kind of like well-postured to help people and its critical function today is to be more than its sole collection and transfer processes. We want to grab the things, we want to make sure that we have everything we need because we can’t easily reach back out. We have to go back out to the internet.

Grab more things if we don’t have them. so we want to make that process as easy to use. want to be able to kind of put those security constraints on the connected side so that we don’t bring anything that we shouldn’t bring with us to an environment that is, let’s say security critical. If you’re operating in those environments in every single piece of the, you know, software puzzle is scrutinized. we want to be very careful that nothing accidentally.

Sally Cooper (05:40.496)
Yeah.

Brandt Keller (05:51.936)
malicious or otherwise makes it into those environments. so there’s a, there’s a, you know, a wide opportunity here to introduce kind of like some security gates. how can we ensure that it’s going to be functional when it gets to the critical or secured environment? This air gapped environment in particular, is, know, first and foremost, where we, want to, you know, kind of help the community prosper. but on the outside of that is, one transparency.

If you’re pulling artifacts, where did you pull them from? What are they comprised of? And again, for those who may be operating this space, you can see, well, it’s like, well, I’m doing all those things today and that’s wonderful. but you’re probably doing them with a variety of tools. You have your, you know, container image management tool. have your Helm chart management tools. have your SBOM tooling that will then scan your.

Software artifacts. So you know what they’re comprised of know what that inventory looks like. And for Zarf, we really wanted to wrap all that up and more into a single process. You create this manifest. And after that manifest is created, you do as our package create, it’s going to grab all that stuff. We’re going to be creating SBOMS on the fly for those artifacts and putting them in the package so that again, we transfer this.

We still see things burned to CDs, as well as, that may seem. And, we want to make it so that when that artifact is in the environment, it’s very, it’s very transparent. You can look at it and be what, what am I about to install? and so there’s a, I think that’s the first layer of Zarf, which is what’s package and transfer it. there are other tools that do this and that’s wonderful. We like to kind of collaborate on solving this problem.

How do we make these artifacts more portable? but then Zarf’s kind of, you know, second, would say superpower is really to enable deployment of software. so how do you know what you deployed? Where did, where did, what are its pieces? how can you work with those pieces and kind of version control them so that the kind of parts and pieces can, you know,

be sustainable and sustainability is kind of a really big part of what we want to solve. but on the outside of that, how do we do all of that without that air gapped environment in particular, having to juggle a lot of disparate or possibly insecure infrastructure. in particular, the, problem that we most often see is that when you want to operate in an air, air gapped environment, you have to bring all this other infrastructure with you.

You have to kind of stand up a registry to pull images from and more often than not, those aren’t secured with TLS because we just want to get it up and running. We want to see that it works. and so for Zarf, we really took a step back and said, how can we bring the, everything we need for the environment to operate in such a way that we’re not going to be left with these disparate puzzle pieces of, infrastructure running that could be potentially insecure. That could be hard to maintain, hard to manage and again, leaning back into ultimately not very sustainable.

Sally Cooper (09:18.49)
One thing that stands out about Zarf is that as more teams use it in real world conditions, the project itself has continued to mature. I’m just wondering in your opinion, how has Zarf evolved?

Brandt Keller (09:34.062)
I think that it’s evolved in a variety of ways, um, kind of on the, on the cusp of in the kind of the very early days, was what’s all of a very niche use case to some. And we say that in such a way that it was like, it was very much a single, uh, Kubernetes distribution, um, air gap tool. And on its onset since then we’ve kind of seen that it really does.

prosper when we look into how can this be a, you know, a tool that is very agnostic of this underlying Kubernetes distribution model, right? Now we have cloud vendors that we want to operate with air gap in the cloud. Maybe not something people always think about, but it is very prevalent. firewalls as kind of the most basic use case of kind of isolating.

cloud infrastructure from the rest of the internet or the cloud. But then we’ve got, you know, the onset of many different new Kubernetes distributions being released, many different problems to solve where you just want to be able to transfer files and maintain, maintain state on those. And so we kind of see the evolution of, you know, taking what we’ve always wanted to solve, which is to make the transfer and deployment process easier, and then integrating the rest of the ecosystem around that.

people came to us and were requesting, you how do we integrate the GitOps ecosystem with Zarf? And how do we make it so that, you know, the mutation model, which I won’t go into unless people really want to hear about it, but how do we make it so that when some of the underlying magic is happening, that, you know, hey, that’s a really great thing, but that’s a cool pattern. Could we apply it to, let’s say, GitOps and Git?

And, you know, kind of stepping back and being like, yes, yes, we can, we can make it so that rather than it being, rather than it always being a process in the air gap where you have to transfer the artifacts and then change a bunch of references so that they point to the right place in your new environment. What’s, what’s kind of handle that for the user, let’s make it more of a, you know, nice and consolidated user experience. so it’s evolved in that way, as well as, know, kind of.

as it relates to the OpenSSF, trying to make open source software more secure.

Sally Cooper (12:21)
Love that. the mutation model, I do think we’re going to need a part two for that because now I’m super curious. But with the evolution, it’s especially interesting when you zoom out and you think about software supply chain security. You think about the broader ecosystem. Why is this a good fit for OpenSSF and how does Zarf help secure open source software?

Brandt Keller (12:30.52)
That is one of the most fun parts of my job is to really try to find new avenues, right? Zarf on again, stepping back a little bit to the early days, it’s been software integrators. They want to take software from its source. Usually these are open source projects and they want to package them up and take them to their environments.

But there’s a real like key opportunity that we’re seeing manifest here really within the last, I would say year and even last couple of months where like Zarf’s transparency models, Zarf’s packaging mechanism could be a key enabler for how software consumers look at open source projects and kind of deem, you know, how well are they doing software like supply chain security?

There’s going to be some of these like onset, I’d say issues where again, maintainers of projects, whether they’re sponsored by a company or whether they’re doing it out of their free time, because they love the technology. they only have so much time in the day. And, you know, I think supply chain security, it’s evolving quickly and it’s continuing to evolve. And most of the time that asks maintainers to do more things, right? Initially you were developing an application.

And you’re saying, Hey, it’s free for everyone to use. I’m not, I’m not asking anybody to pay me to do this. and that’s great. And then more people are like, Hey, for supply chain security, I really need to know what the SBOMs look like. Can you add SBOMs to your releases? Can you sign your releases? And you can kind of see each one of these layers is now a new cognitive burden for, maintainers to kind of normally manage, then

They have to manage the processes on top of like performing that activity. so, I kind of, see some like very distinct opportunities where. If the goal is to help secure open source software, we can really do that by using kind of like Zarf’s declarative manifest model in order for upstream projects to produce releases that consolidate all of that burden again into.

Brandt Keller (14:54.294)
A declarative manifest that they orchestrate in their pipeline, just one, one command, right? Hey, let’s do as our package create. And it’s going to create my, everything I need to run an application such as guac, for instance. we’re working with GUAC on kind of this problem statement. and it’s like, there’s some very fascinating opportunities where you’re going to have everything you need to run GUAC. You’re going to have the SBOMs for GUAC. You’re going to have.

You know, the ability to have that release artifacts signed. And so if you go back to that software integrator, they typically have wanted to deploy GUAC. would create their own Zarf package and pull all those artifacts. Well, now Zarf could just, the integrator could just do a Zarf package poll and they would have everything they would need. And they would know that it’s coming from the upstream source. They would have the confidence around it. They could check the signatures, review the SBOMs and kind of.

you know, kind of look at the posture of, Hey, everything I’ve needed now is kind of consolidated into a concise workflow.

Sally Cooper (16:05.62)
Alright, Brant, before we wrap, it’s time for Rapid, Rapid Fire. These are questions I’m going to ask you, you’re going to answer without any overthinking. No explanations, just your first instinct answers. Are you ready for Rapid, Rapid Fire?

Brandt Keller (16:32)
Let’s do it.

Sally Cooper (16:34)
Star Wars or Star Trek.

Brandt Keller (16:35)
Star Wars.

Sally Cooper (16:36)
Solid. Favorite retro video game?

Brandt Keller (16:41)
Oh, uh, Spyro.

Sally Cooper (16:46)
Ooh, nice. Marvel or DC?

Brandt Keller (16:49)
Marvel.

Sally Cooper (16:51)
Excellent. All right, and last one, favorite open source mascot?

Brandt Keller (16:56)
Oh, not counting Zarf?

Sally Cooper (16:59)
Zarf, of course, after Zarf?

Brandt Keller (17:03)
Um, probably Golang Gopher.

Sally Cooper (17:08)
Oh right, I have that one too. And Zarf is really cool. I love that. All right, perfect. No notes. As we wrap things up, what’s your call to action for our audience? If someone’s listening and wants to learn more about Zarf, try it out or to get involved, where should they start?

Brandt Keller (17:25)
They should start as a Zarf.dev, short and sweet and kind of take a look around and really what we’re trying to understand is, you know, what are the needs of users in different critical environments? I like to visit the public sector groups in a variety of different foundations to see kind of what problems they face, because most often than not, the most constrained regulatory environments are the hardest ones to solve for because they can’t rely on the internet or they have additional scrutiny and we really believe that Zarf is a a great avenue to evaluate and understand. And if it’s not, we’d love to hear from you. Like why, why not? And what are the things that we could do to improve?

Sally Cooper (18:10)
Brandt, thank you so much for joining us today and for all the work you’re doing to help secure how open source software is delivered into some of the most challenging environments. And to everyone listening, happy open sourcing and that’s a wrap.

Apr 15
Love0

From Noise to Signal: Using Runtime Context to Win the Vulnerability Management Battle

By Blog, Guest Blog

By Jonas Rosland

Security teams in 2026 have no shortage of data, alerts, or findings. In 2025 alone, 48,185 Common Vulnerabilities and Exposures (CVEs) were published, a 20.6% increase over 2024’s already record-breaking total of 39,962. That works out to roughly 130 new vulnerabilities disclosed every single day, and for seven consecutive years, the annual count has hit a new record high.

The drivers are structural: the explosive growth of open source software, the complexity of transitive dependencies hidden deep in software supply chains, and an expanding CVE ecosystem that now encompasses nearly twice as many reporting organizations as it did five years ago. With 97% of commercial applications containing open source components, inherited risk has become a routine part of working with modern software.

While only 2% of all discovered vulnerabilities are ever exploited in the wild, of that small fraction, nearly 29% were exploited on or before the day their CVE was published. Attackers are selective, but once they identify a target, the window for defenders is very narrow. The window between vulnerability disclosure and confirmed exploitation is also shrinking. Whereas that timeline was over a year in 2020, it’s now shrunk to just hours.

The old model of scanning everything, triaging by Common Vulnerability Scoring System (CVSS) score, and working through a queue simply cannot keep pace with this reality. Something has to change.

Most vulnerabilities will never be exploited

The vast majority of what your vulnerability scanner finds will never actually be used against you. That means the core challenge facing security teams isn’t patching speed, but knowing where to focus. When a scanner returns thousands of findings ranked only by CVSS score, what looks like a workload problem is really a prioritization problem. Critical vulnerabilities in libraries that aren’t loaded at runtime, or in containers that haven’t run in months, crowd out the findings that genuinely matter, such as exploitable vulnerabilities in running, exposed workloads. The result is alert fatigue, missed priorities, and growing friction between security and development teams.

The OpenSSF Best Practices criteria reflect this directly. At the “Passing” level, projects must not contain unpatched vulnerabilities of medium or higher severity that have been known publicly for more than 60 days, and critical vulnerabilities should be fixed rapidly after they are reported. The emphasis here isn’t on the volume of findings processed, but on the speed and accuracy with which the most dangerous vulnerabilities are addressed, a distinction that gets lost when teams are buried in undifferentiated backlogs.

Why static analysis alone isn’t enough

Static analysis is non-negotiable. The OpenSSF Best Practices criteria require it at the “Passing” level, and at “Silver,” projects must use tools that look for real vulnerabilities in code, not just style issues. Integrated into CI/CD pipelines, static analysis catches bugs early when they are cheapest to fix, and it remains a solid foundation of any security program. However, alone, it’s not enough.

The limitation is that static analysis sees everything, regardless of whether it matters in practice. It cannot tell you whether a vulnerable library is actually loaded in a running container, or whether that container ever receives external traffic. A CVSS 9.8 score looks identical whether the package is called thousands of times a day in a critical service or has never once been invoked in production. Runtime security fills that gap by observing what is actually executing in production. By tracking which processes are running, which packages are loaded, and which connections are being made, security teams gain much more precise intelligence about where risk actually lives.

Only 15% of critical and high-severity vulnerabilities with an available fix are in packages actually loaded at runtime. By isolating that subset, teams can reduce the scope of what needs immediate attention to a small fraction of their total backlog, in some cases by over 95%. That’s the practical difference between a list that overwhelms a development team and one they can actually act on. Static analysis provides breadth by catching everything possible during development, while runtime intelligence adds depth by showing what genuinely matters in production. Together, they give teams the context to make better decisions.

Helping security and development teams speak the same language

Runtime data also changes how security teams and developers talk to each other. Telling a developer “this CVE is rated 8.1” lands very differently than “this vulnerability is in a package actively loaded in your production authentication service.” The second statement connects a finding to a tangible business risk, and that context helps developers understand urgency in a way that a severity score on its own rarely does.

When security teams can bring developers a short, contextualized list of what needs attention and why, the conversation tends to shift from friction to collaboration. The OpenSSF Best Practices framework supports this kind of working relationship structurally, requiring documented vulnerability response processes, response times under 14 days, and release notes that explicitly identify runtime vulnerabilities fixed in each release. These aren’t bureaucratic requirements, but the scaffolding for the kind of consistent, trust-based communication that makes vulnerability management work in practice.

Neither team can do this work alone. Security engineers don’t always know which code paths are business-critical, and developers don’t always have visibility into what their software looks like from an attacker’s perspective. Runtime data helps bridge that gap by giving both sides a shared, evidence-based view of where the real risk lives.

Shrinking the problem over time

Prioritization manages the vulnerability problem today, but reducing the attack surface is how you make the problem smaller tomorrow. Runtime intelligence supports two practical strategies that static scanning alone cannot.

  1. Build leaner, more deliberate images. Runtime analysis identifies unused packages, old utilities, and bundled libraries that never get called in production, giving teams a clear basis for stripping images down. Building from scratch or distroless base images takes this further by removing shells, package managers, and other components that have no place in a production workload, and combining that with rootless containers limits the damage an attacker can do if they do gain access. Runtime data can also flag containers running on stale base images that are actively receiving traffic, making the case for a refresh concrete rather than a task that keeps getting deprioritized.
  2. Detect and respond to unexpected behavior in production. Even with good prioritization, not every risk can be patched immediately. This is where a runtime threat detection tool like Falco becomes valuable. By defining what normal behavior looks like for a given workload, Falco can flag unexpected activity in real time, such as a process spawning a shell, a container writing to a sensitive path, or an unusual outbound connection appearing. This doesn’t replace patching, but it provides a meaningful layer of protection while remediation work is underway, and it gives teams better visibility into whether a vulnerability is being actively probed or exploited.

The OpenSSF Best Practices criteria encourage minimizing the attack surface throughout, and the logic applies equally in production environments. The best vulnerability is the one that doesn’t exist because the vulnerable component was never there, and the next best outcome is knowing quickly when something unexpected is happening around the ones that remain.

Where to go from here

The 2025 numbers make one thing very clear: the volume of vulnerabilities isn’t going down, and teams that try to treat every finding with equal urgency will continue to struggle. The more practical path is to use static analysis and runtime intelligence together, letting each do what it does best, and to use that shared context to build better working relationships between security and development teams. Finding the right vulnerabilities to fix, explaining why they matter, and making it straightforward for developers to act on them is where the real progress happens.

About the Author

Jonas Rosland is Director of Open Source at Sysdig, where he works on cloud-native security and open source strategy. Sysdig supports open source security projects, including Falco, a CNCF graduated project for runtime threat detection.

Apr 03
Love0

Rethinking Post-Deployment Vulnerability Detection

By Blog, Guest Blog

By Tracy Ragan

Over the past decade, the IT community has made significant progress in improving pre-deployment vulnerability detection. Static analysis, Software Composition Analysis (SCA), container scanning, and dependency analysis are now standard components of modern CI/CD pipelines. These tools help developers identify vulnerable libraries and insecure code before software is released.

However, security does not end at build time.

Every successful software attack ultimately exploits a vulnerability that exists in a running system. Attackers can and do target code repositories, CI pipelines, and developer environments; these supply chain attacks are serious threats. But vulnerabilities running in live production systems are among the most dangerous because, once exploited, they can directly lead to persistent backdoors, system compromise, lateral movement, and data breaches.

This reality exposes an important gap in how organizations manage vulnerabilities today. While significant attention is placed on detecting vulnerabilities before deployment, far fewer organizations have effective mechanisms for identifying newly disclosed CVEs that affect software already running in production.

Across the industry, most development teams today run some form of pre-deployment vulnerability scanning, yet relatively few maintain continuous visibility into vulnerabilities impacting deployed software after release. This imbalance creates a dangerous blind spot: the systems organizations rely on every day may become vulnerable long after the code has passed through security checks.

As the volume of vulnerability disclosures continues to increase, the industry must rethink how post-deployment vulnerabilities are detected and remediated.

The Growing Post-Deployment Vulnerability Problem

Modern software systems depend heavily on open source components. A typical application may include hundreds, or even thousands, of transitive dependencies. While security scanning tools help identify vulnerabilities during development, they cannot predict vulnerabilities that have not yet been disclosed.

New CVEs are published daily across open source ecosystems. When a vulnerability is disclosed affecting a widely used package, thousands of deployed applications may suddenly become vulnerable, even if those applications passed every security check during their build process.

This creates a persistent challenge: software that was secure at release can become vulnerable later without any code changes.

In many organizations, the detection of these vulnerabilities relies on periodic rescanning of artifacts or manual monitoring of vulnerability feeds. These approaches introduce delays between vulnerability disclosure and detection, extending the window of exposure for deployed systems.

Because attackers actively monitor vulnerability disclosures and quickly develop exploits, this detection gap creates significant operational risk.

Current Approaches to Detecting Post-Deployment CVEs

Organizations today use several methods to identify vulnerabilities affecting deployed software. While each approach has value, they are often costly and introduce operational complexity.

One common strategy involves rescanning previously built artifacts or container images stored in registries. Security teams periodically run vulnerability scanners against these artifacts to identify newly disclosed CVEs. Although this approach can detect vulnerabilities that were unknown at build time, the process cannot identify where the containers are running across system assets. 

Another approach relies on host-based security agents or runtime inspection tools deployed on production infrastructure. These tools identify vulnerable libraries by inspecting installed packages or monitoring application behavior. In practice, these solutions are most commonly implemented in large enterprise environments where dedicated operations and security teams can manage the operational complexity. They often require significant infrastructure integration, deployment planning, and ongoing maintenance.

Agent-based approaches also struggle to support edge environments, embedded systems, air-gapped deployments, satellites, or high-performance computing clusters, where installing additional runtime software may not be feasible or permitted. Even in traditional cloud environments, deploying and maintaining agents across thousands of systems can be a substantial operational lift.

This complexity stands in sharp contrast to pre-deployment scanning tools, which can often be installed in CI/CD pipelines in just minutes. Integrating a software composition analysis scanner into a build pipeline typically requires only a small configuration change or plugin installation. Because these tools are easy to adopt and operate earlier in the development lifecycle, they have seen widespread adoption across organizations of all sizes.

Post-deployment solutions, by comparison, often require significantly more effort to deploy and maintain. As a result, far fewer organizations implement comprehensive post-deployment vulnerability monitoring. While most development teams today run some form of pre-deployment vulnerability scanning, relatively few maintain continuous visibility into vulnerabilities impacting software already running in production. This leaves a critical visibility gap in the environments where vulnerabilities are ultimately exploited: live operational systems.

SBOMs Are an Underutilized Security Asset

A more efficient model for detecting post-deployment vulnerabilities already exists but is often underutilized.

Software Bill of Materials (SBOMs) provide a detailed inventory of the components included in a software release. When generated during the build process using standardized formats such as SPDX or CycloneDX, SBOMs capture critical metadata, including component names, versions, dependency relationships, and identifiers such as Package URLs.

SBOM adoption has accelerated in recent years due in part to initiatives such as Executive Order 14028 and ongoing work across the open source ecosystem. Organizations increasingly generate SBOMs as part of their software supply chain transparency efforts.

Yet in many environments, SBOMs are treated primarily as compliance documentation rather than operational security tools. Instead of being archived after release, SBOMs can serve as persistent inventories of the components running in deployed software systems.

Detecting Vulnerabilities Without Rescanning

When SBOMs are available and associated with deployed releases, detecting newly disclosed vulnerabilities becomes significantly simpler.

Vulnerability intelligence feeds, such as the OSV.dev database, the National Vulnerability Database (NVD), and other vendor advisories, identify the packages and versions affected by each CVE. By correlating this vulnerability information with stored SBOMs and release metadata, organizations can quickly determine whether a deployed asset includes an affected component.

Because the SBOM already describes the complete dependency graph, there is no need to reanalyze artifacts or rescan source code. Detection becomes a metadata correlation problem rather than a compute-intensive scanning process.

This model enables organizations to continuously monitor deployed software environments and identify newly disclosed vulnerabilities almost immediately after they are published.

Digital Twins and Continuous Vulnerability Synchronization

To operationalize this approach at scale, organizations need systems capable of continuously tracking the relationship between software releases, deployed environments, and their associated SBOMs. One emerging concept is the creation of a software digital twin, a continuously updated model that represents the software components running across operational systems.

A digital twin maintains the relationship between deployed endpoints and the SBOMs that describe the software they run. By synchronizing these SBOM inventories with vulnerability intelligence sources such as OSV.dev or the NVD at regular intervals, organizations can automatically detect when newly disclosed CVEs impact running systems.

Rather than waiting for scheduled scans or relying on agents installed on production infrastructure, this model enables continuous vulnerability awareness through metadata synchronization.

Once an affected component is identified, remediation workflows can also be automated. Modern development platforms already rely on dependency manifests such as pom.xml, package.json, requirements.txt, or container Dockerfiles. By automatically updating these dependency files and generating pull requests with patched versions, organizations can rapidly move fixes back through their CI/CD pipelines.

This type of automation has the potential to reduce vulnerability remediation times from months to days, dramatically shrinking the window of exposure. And, it is easy to scale, giving developers more control and visibility into the production threat landscape. 

Aligning with OpenSSF Security Initiatives

Efforts across the Open Source Security Foundation (OpenSSF) ecosystem have helped establish the foundational infrastructure needed for this approach.

The OSV.dev vulnerability database provides high-quality vulnerability data tailored to open source ecosystems. Standards such as SPDX and CycloneDX enable consistent representation of SBOM data across tools and platforms. Projects like OpenVEX provide mechanisms for communicating vulnerability exploitability context, helping organizations determine which vulnerabilities require immediate attention.

Together, these initiatives create the building blocks for a more efficient and scalable vulnerability management model, one that relies on accurate software inventories and continuous vulnerability intelligence rather than repeated artifact scanning.

The Future of Vulnerability Management

Pre-deployment security scanning will continue to play an important role in software development. Identifying vulnerabilities early in the development lifecycle reduces risk and improves software quality.

But the security landscape is evolving. As software ecosystems grow more complex and vulnerability disclosures increase, organizations must also strengthen their ability to detect vulnerabilities that appear after software has already been deployed.

Rethinking post-deployment vulnerability detection means shifting away from repeated artifact scanning and toward continuous monitoring of software composition.

SBOMs provide the foundation for this shift. When combined with digital twin models that track deployed software, continuous synchronization with vulnerability databases, and automated dependency remediation, organizations can dramatically improve their ability to defend operational systems.

One thing is certain: attackers ultimately focus on exploiting vulnerabilities running in live systems. Gaining clear visibility into the attack surface, understanding exactly what OSS packages are deployed, where they are running, and how quickly they can be remediated, is essential to securing live systems from cloud-native to the edge. 

Author 

Tracy Ragan is the Founder and Chief Executive Officer of DeployHub and a recognized authority in secure software delivery and software supply chain defense. She has served on the Governing Boards of the Open Source Security Foundation (OpenSSF) and currently serves as a strategic advisor to the Continuous Delivery Foundation (CDF) Governing Board. She also sits on both the CDF and OpenSSF Technology Advisory Committees. In these roles, she helps shape industry standards and pragmatic guidance for securing the software supply chain and advancing DevOps pipelines to enable safer, more effective use of open-source ecosystems at scale.

With more than 25 years of experience across software engineering, DevOps, and secure delivery pipelines, Tracy has built a career at the intersection of automation, security, and operational reality. Her work is focused on closing one of the industry’s most critical gaps: detecting and remediating high-risk vulnerabilities running in live, deployed systems, across cloud-native, edge, embedded, and HPC environments.

Tracy’s expertise is grounded in decades of hands-on leadership. She is the Co-Founder and former COO of OpenMake Software, where she pioneered agile build automation and led the development of OpenMake Meister, a build orchestration platform adopted by hundreds of enterprise teams and generating over $60M in partner revenue. That experience directly informs her current mission: eliminating security blind spots that persist long after software is released.

Apr 02
Love0

From AIxCC to OpenSSF: Welcoming OSS-CRS to Advance AI Driven Open Source Security

By AI, Blog, Global Cyber Policy

By Jeff Diecks

Artificial intelligence is changing how we approach software security. Open source is at the center of that shift.

Over the past year, DARPA’s Artificial Intelligence Cyber Challenge (AIxCC) showed that cyber reasoning systems (CRS) can go beyond finding vulnerabilities. These systems can analyze code, confirm issues, and generate patches. This brings us closer to a future where security is more automated and scalable.

When the competition ended, one question remained. How do we take these breakthroughs and make them usable in the real world?

Today, we are taking an important step forward.

The Open Source Security Foundation (OpenSSF) is welcoming OSS-CRS as a new open source project under the AI / ML Security Working Group.

OSS-CRS emerged from AIxCC and is a standard orchestration framework for building and running LLM-based autonomous bug-finding and bug-fixing systems.

The open framework is designed to make CRS practical outside of the AIxCC environment. During the competition, teams built powerful systems that were released as open source. However, many of them depended on the competition infrastructure, which made them difficult to reuse or extend. OSS-CRS addresses that gap.

OSS-CRS Features include:

  • Standard CRS Interface: OSS-CRS defines a unified interface for CRS development. Build your CRS once following the development guide, and run it across different environments (local, Azure, …) without any modification.
  • Effortless Targeting: Run any CRS against projects in OSS-Fuzz format. If your project is compatible with OSS-Fuzz, OSS-CRS can orchestrate CRSs against it out of the box.
  • Ensemble Multiple CRSs: Compose and run multiple CRSs together in a single campaign to combine their strengths and maximize bug-finding and bug-fixing coverage.
  • Resource Control: Manage CPU limits and LLM budgets per CRS to keep costs and resources in check.

Read the OSS-CRS research paper: https://doi.org/10.48550/arXiv.2603.08566

From Competition to Community

The move of OSS-CRS into OpenSSF marks a clear transition from research and competition to open collaboration and long term development.

OpenSSF provides a neutral home where projects like OSS-CRS can grow. Contributors can work together to improve the tools, validate results, and support adoption across the ecosystem.

OSS-CRS is already producing real results. Using OSS-CRS, Team Atlanta discovered twenty-five vulnerabilities across sixteen projects spanning a broad range of software including PHP, U-Boot, memcached, and Apache Ignite 3.

OpenSSF will continue to support this important work by providing human connectors between CRS tools and open source communities. The goal is to help triage and validate vulnerability reports and proposed patches before they reach maintainers, ensuring findings are accurate, actionable, and respectful of maintainers’ time.

Recent research from the OSS-CRS team validates the necessity of having a human in the loop. The team manually reviewed a set of 630 AI-generated patches and found 20-40% of the patches to be semantically incorrect. The incorrect patches pass all automated validation but are actually wrong — a dangerous failure mode only catchable by manual review.

A key benefit of the OSS-CRS project is its Ensemble feature. The Ensemble feature enhances accuracy and reliability by combining patches from multiple CRS approaches and using a selection process to pick the one most likely to be correct. The research showed this approach consistently matches or outperforms the best single component in improving semantic correctness, which is hard to eliminate at the single-agent level. This collaboration of systems helps produce more robust results for open source defenders.

Get Involved

With projects like OSS-CRS, OpenSSF will continue to support AI-driven security work to help turn innovation into practical outcomes for open source.

We offer several options to get involved including:

Author Bio

Jeff Diecks is a Senior Technical Program Manager at The Linux Foundation. He has more than two decades of experience in technology and communications with a diverse background in operations, project management and executive leadership. A participant in open source since 1999, he’s delivered digital products and applications for universities, sports leagues, state governments, global media companies and non-profits.

Mar 24
Love0

What’s in the SOSS? Podcast #57 – S3E9 From Noise to Signal: Security Expertise and Kusari Inspector with Mike Lieberman

By Podcast

Summary

In this episode, CRob talks with Mike Lieberman from Kusari about the current state of open source security. They discuss the growing burden on maintainers from the “deluge” of noisy, low-quality vulnerability reports, often generated by AI tools, and the vital role of “a human in the loop.” Mike introduces Kusari’s tool, Inspector, explaining how it uses codified security expertise to process data from tools like OpenSSF Scorecard and SLSA, effectively filtering out false positives and giving maintainers only high-quality, actionable reports. They also dive into the design philosophy of “don’t piss off the engineers” and share a vision for the future of security tooling that focuses on dramatically better user experience and building security primitives that are “secure by design”.

Conversation Highlights

00:06 Introduction: The Biggest Challenge in Security Tooling
01:12 Overwhelmed Maintainers: The Deluge of Low-Quality AI Reports
04:00 Introducing Kusari’s Inspector: How it Filters False Positives
08:40 The Secret Sauce: Security Expertise and the Need for Reproducible Tests
12:03 Meeting Engineers Where They Are: Design Choices to Reduce Maintainer Burden
18:16 The Future of Open Source Security Tooling: Focusing on Better UX
22:19 Call to Action: The Responsibility of Large Organizations

Transcript

(0:00) Intro Music

Mike Lieberman (00:06)
I think the biggest thing in security tooling is better user experience. I think that to me is one of the biggest challenges.

CRob (00:25)
Welcome, welcome, welcome to What’s in the SOSS?, the OpenSSF’s podcast where I talk to developers, maintainers, security experts, and people in and around this amazing open source ecosystem. Today, again, we have a real treat. Friend of the show, Mike Lieberman from Kusari is joining us again after – I don’t know if your podcast was toppled from its place of the most listened to before, but we’re gonna see if we can make another hit for us. But we’re here today to talk about some interesting developments that you and your crew are involved in and just things going on in open source security. So how have you been, sir?

Mike Lieberman (01:07)
Well, thank you for having me back and yeah, things are going pretty well.

CRob (01:12)
Well, let’s dive right into it. Recently, and this is a topic that I’m actually dealing with this very moment while we’re recording this podcast, that open source maintainers are just currently overwhelmed by just this deluge of noisy, low quality reports, a lot of them generated by AI tools. So kind of thinking about it with your, many hats you wear, as you know, business owner, a community member, and a long time developer, a security expert. From your perspectives, what is actually creating the most burden today? And think about it through the lens of this project you’re going to share with us in a moment.

Mike Lieberman (01:57)
Yeah, sure. So I think to kind of start, the problem has been the same problem since, know, throughout human history, it is a combination of either bad actors or just lazy people that are I would say the biggest issue here. Right. We have a lot of things like AI reports generating awful sort of vulnerability, know, fake vulnerabilities or whatnot. But if we kind of look at it through the lens of like history through tech, we saw the same thing with any sort of automation, right? When, yeah, exactly. When people could kind of create scripts, hey, let me go in spam this one project with my script. Let me spam a whole bunch of projects with my sort of automation or whatever. And, you know, the same thing sort of happened when people, when we started moving away from mailing lists to sort of GitHub and those sorts of things as well. So I think it’s really to kind of take a step back. It’s kind of how people are using the tools more so than the tools themselves. But I do think when it comes to a lot of the security reports, yeah, it is folks who are just kind of asking an LLM.

Hey, find me find me some zero day. And of course, that’s never going to work because the LLMs don’t have that information. And it’s just it kind of comes back to you need people who understand what they’re doing, using the tools in the right way in order to kind of figure out some of this stuff.

CRob (03:42)
Yeah, human in the loop. Our dear friend, Dr. David Wheeler has a saying, he says, a fool with a tool is still a fool. So again, having those experts in there, helping out is critical. So let’s…

Mike Lieberman (03:43)
Yeah.

CRob (04:00)
You’ve been in this space for a long time, focusing in on supply chain security, and you’ve written or contributed to a ton of tools. And most recently, you all helped create over at Kusari a tool called Inspector. So from just a high level TLDR, how do you see things like Inspector kind of changing this dynamic of getting more people involved or getting more expert knowledge in?

Mike Lieberman (04:26)
Sure. I think like the things. So actually to take a step back, right? There’s a lot of great tools that are being built. The challenge with those tools is, and the way I kind of think about it is like, you know, home security, right? It’s, hey, there’s a ton of tools out there that are helping out with open source security the same way that there’s a ton of tools out there for, you know, a smarter lock. A better security system.

CRob (04:59)
A doorbell that can find your dog.

Mike Lieberman (05:02)
There’s privacy concerns on that one. think, you know, we can all agree on that. But I think to that extent, when it comes to sort of these tools, it’s in how they’re used. And also, the expertise that’s required in how to use them. And also, when building the tools, what sort of expertise went into building the tools? And I think that to me is where the big gap is with just sort of some of the AI related things is you have folks using a very generic system like an LLM. And just saying, hey, LLM become a security expert and do this stuff. And of course the LLM makes a lot of mistakes and whatever. But if you were to kind of say through things like MCP and LLM skills and all these other things, if you have a way of codifying, run open SSF scorecard, run, you know, SLSA and run all of these various things and put all of this together and generate me an SBOM using these tools and whatnot. And then you can take all that, then hand the output to the LLM and say, hey, here’s everything I discovered. Here’s also the code. Help me make sense of it. And I think that to me is kind of where a lot of the benefit is. And again, what I just described is essentially inspector, right?

We’re running all of these various tools, again, that we understand because we’ve contributed to those tools, we’ve helped maintain some of those tools, we have been users of these tools for years. So we understand how they’re supposed to be used. We understand how a human who is, before the age of AI would be using these tools. And we recognize the burden of that expertise. And we’ve sort of encoded it. Had the LLM kind of come in at the last mile and then take all that information, and say, hey, if there is a finding, a vulnerability, great. Where does that vulnerability live? Is that a vulnerability in a core piece of my code, which yes, I need to address right now, or is it like, it’s in a test? Yes, it’s probably something I should fix, but maybe not the biggest issue right this second. And so I think tools like that are really helping because the thing that we found, and again, a user of inspector told us this, and I won’t call out the exact AI tool they were using, but they were using a generic LLM with some stuff. And then they were using inspector. And one of the things that they had said was, wow. Yeah. Like inspector is actually catching the issue with all of the, the, uh, it detected that a particular issue was essentially a, um, a false positive because it looked at a potential remote code execution and looked at all the stuff alongside the code and said, you are clearly have an allow list. So given that you have this allow list, we recognize it’s not a remote code execution, or rather arbitrary code sort of execution attack. And I think it’s stuff like that, that we’re seeing starting to get developed more and more. Whereas a lot of the tradition, I want to say traditional with AI, even though it’s been, you know, like in the past year, everything shifts. Yeah.

When we look at sort of how folks were using LLMs even just a year ago, a lot has shifted and we’re seeing less of these false positives coming out of AI because people are using AI the way it should be used, where it’s you’re supplementing all these other tools that are out.

CRob (08:40)
That’s awesome.

And this might lead into this next question. AI and automation are finding a lot more potential issues, but they’re not always better. And is that what you think that secret sauce of having that security expertise and that helps kind of balance out finding a vulnerability and then kind of sharing that information with the maintainer effectively?

Mike Lieberman (09:08)
Yeah, so I mean, I think when it comes to stuff like that, the way I, you know, I was actually having a conversation with a friend just a few days ago about this issue and I’m reminded of issues just even before AI. And one of the big things that maintainers would ask is, give me a way to reproduce this. If you’re not gonna give me a way to reproduce this, I’m not gonna, you know, I’m not gonna accept your report here and I’m not gonna do a ton of investigation to figure out what you intended to mean.

And I think it’s the same way with AI here, where we’re starting to see with some of the stuff coming out of AI XCC and some other places, we are starting to see tools that are being built that are actually generating the tests and whatnot that can reproduce these vulnerabilities that the LLMs are claiming, or AI tools are claiming. And I think that to me is important because when I look at Daniel from Curl or some of these other folks who are like,

I am so sick of all of these AI reports. It’s like every single one that they’re claiming is an AI report, it’s like they didn’t give me a way to reproduce it. Or even worse, the AI said, here’s a list of steps to reproduce. folks are coming out and saying, that function that you were claiming needs to get run doesn’t exist. And so I’m just thinking to myself, well, why not just write a test that does that thing, you know, and have the LLM write the test, whatever, but prove out that like, hey, an AI tool generated a test and I can run that test and I could see, yep, that is an exploit. That is actually a vulnerability. Now I can go and take that and package it up, it over to, you know, hand it over to the maintainer. And I think if I’m as a maintainer of various open source projects,

If I received something that said, hey, here is a test, you can run that test. And again, by the test, mean like an actual test, a test that makes up other code and tries to do whatever, but an actual test. If you have that, I as a maintainer would say, absolutely, that is a real vulnerability. But I think the thing that we’re seeing right now is we’re seeing all this sort of slop, which is.

Again, it’s just similar to the slop we saw years ago with other sort of automated vulnerability reporting and just generally in tech. And I think the problem here is still kind of comes back to lazy maintainer or sorry, not lazy maintainers, but lazy submitters and just other sort of bad actors who are just like, yeah, I’m just gonna throw a thing out there and hopefully one of these is right. And I’m gonna get it, make a name for myself.

CRob (11:58)
A wise man once said that knowing is half the battle.

Mike Lieberman (12:01)
Yes.

CRob (12:03)
And thinking about it from this maintainer developer perspective, almost always maintainers are volunteers first. They’re there because they have amazing idea they wanna share, they have a problem they’re trying to solve. Some people are paid to do a specific thing, but the majority of folks are volunteers first. And security experts 12th, 18th, security is not necessarily a core skill that most developers have. what design choices, kind of thinking about when you were looking at Inspector, what design choices did you make to help meet the maintainers where they are, where they are experts in languages or frameworks or kind of these techniques or algorithms? But how are you helping them where they are rather than expecting them to become a full-time securityologist like you or I?

Mike Lieberman (12:58)
So we have a mantra here at Kusari, which is essentially just don’t piss off the engineers, right? As engineers ourselves, as folks who, myself, I am a software engineer first, or really more of a dev ops, dev sec ops engineer first, became more of a software engineer over time. But one of the big sort of mantras was, one of the things that always frustrated me was you have to do all the security stuff.

And they were burdens to my daily job, right? Where I was not being, you know, again, this is me both as a maintainer of open source projects and also just, hey, I get paid as an engineer or whatever. What, but at the end of the day, I wasn’t incentivized to do secure things. I might’ve been yelled at. I might’ve been told thou shalt do this security thing, but my incentives were getting out this new feature, making my customer or my user happy, right?

And so when it comes to those sorts of things, that’s kind of how we’ve encoded all of this, where if somebody told me, hey, Mike, you put in a potential remote code execution attack or arbitrary code, whatever it is, like you put a SQL injection attack or some other, you’re not handling this off thing correctly. If you told me, yeah, that’s the thing. And you told me what I might need to look at. yeah, let me get on that. Let me fix that.

If you were to tell me, hey, you’re using a library that isn’t maintained and that everybody has mostly moved over to this other library, cool. I’ll, I’ll work on that, but don’t make the burden. Hey, there’s a, this library is unmaintained. Okay. What am I, what am I supposed to do about it? I don’t know what I’m supposed to do about it. Help me with suggestions. So when it comes to inspector, those are the sorts of things that we sort of baked in is we’re not just telling you this project. Is it maintained?

We’re telling you, hey, this project isn’t maintained, but it’s used in just one test. So maybe it’s not the immediate thing that needs to be fixed versus, hey, this thing is completely unmaintained and it’s potentially vulnerable. And this is something new you’re adding. Like this isn’t something that already exists. This is just bad practice. Like you should probably not include this new thing. Or, you know, and again, providing the suggestions to the user on what to actually do about it.

And some of those things can then be, know, know, inspector has a CLI tool that you can use. And I use it myself with Claude where, Hey, I run it kind of come in and, you know, uh, fix it. And like, it works pretty well. So I think again, it’s, it’s having, um, it’s, it’s the combination of things to sort of make sure that it, as an engineer, you know, you’re not being asked to become an expert in this thing, right? Uh, it’s okay to ask an engineer.

You are a database expert, you should be reasonable at securing databases, but securing the underlying OS and yada yada, hey, maybe you don’t need to be an expert in that. And that’s where tools like Inspector I think really help is they’re the ones who are being experts. Again, kind of going back to that, the home analogy, right? If I run a house, if I have a house, I don’t need to know the inner mechanics of know, a pin tumbler lock and yada, yada and, and, and how the various cameras, you know, that that are looking at the outside of my house, how they all interoperate. No, I just need to know, are they working if something kind of, you know, the battery died on this, I know how to change your battery, let me kind of focus on that. But if they were kind of come in and say, No, no, you need to understand the innards of the networking and you need to understand audio visual processing, I’d be like, No, just not gonna work.

So again, make sure that developers can focus just on what their experts in, and what their primary responsibility is, which is usually to the user. And yes, security is a responsibility there, but they’re not going to be generic security experts. And so what can we do to help them hold their hand and tell them what needs to be done in a way that they can kind of say, yeah, you’re asking me to do two or three small little things. Awesome. By the way, we here at Kusari have made Inspector free for open source, but not just open source, specifically for CNCF and open SSF. You have full sort of unfettered access, no rate limits, no quotas. And love to see folks sign up. The website is kusari.cloud. And yeah, yeah, I want to see folks using it.

CRob (17:45)
It’s really interesting and I love the focus on again, because you’re all you grew up through this. are in software engineer. So I love the focus on trying to how to relieve that burden from these, this army of volunteers. So let’s do something else we do often in cybersecurity. Let’s get our crystal ball out and, you know, thinking ahead from your perspective, what do you think, you know, good security tooling for open source looks like in three to five years?

Mike Lieberman (18:16)
I think the biggest thing in security tooling is better user experience. think that to me is one of the biggest challenges. And right today, and I think that’s where a lot of folks are focusing their efforts, it’s, you we need to some extent, you know, and I know, like, the first thing that came to mind, is Kubernetes, but for security, right? And I recognize that Kubernetes, depending on who you talk to, you know, YAML files,

But no, it really did democratize and make simpler the orchestrating complex container workloads, right? And I think when it comes to security, user experience is often kind of a secondary concern compared to just the, did I prevent the security, you the issue, but that’s kind of, as our world continues to get more complex and complicated and things are scaling up and we’re having AI and all these different things. The need for security continues to increase more and more every day. But with that said, if the answer is using these security tools requires, you know, tons of certifications and whatnot for just to use the security tool, right? Not to become an expert, but just to use the security tool, if you need to be an expert in all these different things, it becomes super difficult, nobody’s gonna do it. So I think we’re gonna start to see to some extent, more tools like Inspector, but also in addition to that, more tools like, and I know we’re working on this in OpenSSF, tools that make adopting of Salsa trivial for the average project. Tools that help just sort of generally with security build out that UX, make it simpler for the average engineer to do that. Similar to how we saw stuff

in that space with DevOps, right? Where you had developers and operations, those worlds kind of became more combined. And what happened was you had tools like your Terraforms or, you know, Open Tofu and Ansible and all of these great things that kind of came out of that space to kind of make it easier for both folks who are focused in operations to get a little closer to developers and then developers to actually also help out with some of the operations, infrastructure, engineering, those sorts of things. And I think we’re gonna start to see more of that as time kind of goes on where those like, I’m gonna call like security primitives are more encoded in the tools we have. So I think we’re gonna start to see a lot of tools out there become secure by design and have a lot of the security features baked in. And then also the security tools that we have just generally become a little bit simpler and where areas where they can’t be super simple, we’re gonna see tools more tools like Inspector that kind of come in and operate similar to how you might imagine the security expert to kind of come in and put the pieces together, which again, doesn’t eliminate the security engineer. I just want to be clear, like security engineers are very much still needed. The challenge is the security engineer is now being tasked. Whereas before you had to be an expert in a small set of domains. Now you’re being asked to be an expert across everything and they need to understand that they’re going to be the ones who are like taking these new security tools and given that better UX are going to be able to scale that across, you know, 10,000 projects, you know, a hundred different AI agents, all of this, like, you know, a million containers, all of those things. So I think we’re going to start seeing a lot more of the security tools working better to scale up what we’re doing.

CRob (22:04)
That is an amazing vision. look forward to observing that over the years. Hopefully your vision becomes a reality. Yeah, thank And as we’re winding down, do you have any closing thoughts or any call to action for the audience?

Mike Lieberman (22:19)
Yeah, I think the, so there’s two big ones. One is, hey, if you’re a maintainer and engineer, right? I know you care about security because even when I was not a security engineer, I cared about security. So what I want to hear from maintainers is how can the open source world help, right? How can we help you not get clobbered by a million?

letters from lawyers and other people demanding security features in your stuff. How can we, as an open source community, help out, open source security community, help out? How can we make the tools easier? How can we make sure that those tools fit your needs? And that includes whether it’s inspector or, you know, other things, hey. And on that note as well, you know, CNCF and OpenSSF projects can use inspector..

And the other call to action, I know I say this a lot, large organizations that are using open source, it is your responsibility to provide the incentives to make sure that open source is more secure. Like we can all demand, hey, we need better open source security tooling. We need this, that, and the other thing. But if nobody’s paying for it, if at the end of the day, you know, a random engineer who’s making that open source security tool, if they can’t pay the bills, they’re not going to do that. If they are getting clobbered with a million different feature requests, it’s just not going to work. So we need to make sure. And I know that there’s things like the sovereign tech fund want to see more of that. But just sort of generally, I think it needs to come from these multi billion, multi trillion dollar companies coming in and saying, hey, we are willing to foot a good deal of this bill right in order to make the world more secure for everybody.

CRob (24:17)
Those are some wise words and also I think a wonderful vision we all can work towards together. Mike Lieberman from Kusari, thank you my friend. I loved having you on. And with that, we’re gonna call this a wrap. I want everyone to stay cyber safe and sound and have a great day.

Mar 23
Love0

Kusari Partners with OpenSSF to Strengthen Open Source Software Supply Chain Security

By Blog, Guest Blog

Cross-post originally published on the Kusari Blog

Open source software powers the modern world; securing it remains a shared responsibility.

The software supply chain is becoming more complex and more exposed with every release. Modern applications rely on vast ecosystems of open source components, dependencies, and increasingly AI-generated code. While this accelerates innovation, it also expands the attack surface dramatically. Threat actors are taking advantage of this complexity with more frequent and sophisticated attacks, from dependency confusion and malicious package injections to license risks that consistently target open source communities.

At the same time, developers are asked to move faster while ensuring security and compliance across thousands of components. Traditional security reviews often happen too late in the development lifecycle, creating friction between development and security teams and leaving maintainers overwhelmed by reactive work.

Kusari is proud to partner with the Open Source Security Foundation (OpenSSF) to offer Kusari Inspector at no cost to OpenSSF projects. Together, we’re helping maintainers and security teams gain deeper visibility into their software supply chains and better understand the relationships between first-party code, third-party dependencies, and transitive components.  

Projects adopting Kusari Inspector include Gemara, GitTUF, GUAC, in-toto/Witness, OpenVEX, Protobom and Supply-chain Levels for Software Artifacts (SLSA). As AI coding tools become standard in open source development, Kusari Inspector serves as the safety net maintainers didn’t know they needed. 

“I used Claude to submit a pull request to go-witness,” said John Kjell, a maintainer of in-toto/Witness. “Kusari Inspector found an issue that Claude didn’t catch. When I asked Claude to fix what Kusari Inspector flagged, it did.”

Maintainers are under growing pressure. According to Kusari’s Application Security in Practice report, organizations continue to struggle with noise, fragmented tooling, and limited visibility into what’s actually running in production. The same challenges affect open source projects — often with fewer resources.

Kusari Inspector helps OpenSSF projects:

  • Map dependencies and transitive risk
  • Identify gaps in attestations and provenance
  • Understand how components relate across builds and releases
  • Reduce manual investigation and security guesswork

Kusari Inspector – Secure Contributions at the Pull Request

Kusari Inspector also helps strengthen the relationship between developers and security teams. Our Application Security in Practice research found that two-thirds of teams spend up to 20 hours per week responding to supply chain incidents — time diverted from building and innovating. 

For open source projects, the burden is often even heavier. From our experience in co-creating and maintaining GUAC, we know most projects are maintained by small teams of part-time contributors and already overextended maintainers who don’t have dedicated security staff. Every reactive investigation, dependency review, or license question pulls limited capacity away from priorities and community support — making proactive, workflow-integrated security even more critical.

By increasing automated checks directly in pull requests, projects reduce review latency and catch issues earlier, shifting from reactive firefighting to proactive prevention. Instead of maintainers “owning” reviews in isolation, Kusari Inspector brings them integrated, context-aware feedback — closer to development and accelerating secure delivery.

This partnership gives OpenSSF projects the clarity they need to make informed security decisions without disrupting developer workflows.

“The OpenSSF welcomes Kusari Inspector as a clear demonstration of community support. This helps our projects shift from reactive security measures to proactive, integrated prevention at scale,” said Steve Fernandez, General Manager, OpenSSF.

“Kusari’s journey has always been deeply connected to the open source security community. We’ve focused on closing knowledge gaps through better metadata, relationships, and insight,” said Tim Miller, Kusari Co-Founder and CEO. “Collaborating with OpenSSF reflects exactly why Kusari was founded: to turn transparency into actionable trust.”

If you’re an OpenSSF project maintainer or contributor interested in strengthening your supply chain posture, use Kusari Inspector for free — https://us.kusari.cloud/signup.

Author Bio

Michael LiebermanMichael Lieberman is co-founder and CTO of Kusari where he helps build transparency and security in the software supply chain. Michael is an active member of the open source community, co-creating the GUAC and FRSCA projects and co-leading the CNCF’s Secure Software Factory Reference Architecture whitepaper. He is an elected member of the OpenSSF Governing Board and Technical Advisory Council along with CNCF TAG Security Lead and an SLSA steering committee member.

Mar 23
Love0

OpenSSF Celebrates New Members, No-Cost Tooling, and Project Milestones

By Blog, Press Release

Foundation welcomes Helvethink, Spectro Cloud, Quantrexion as members, offers Kusari Inspector for free to projects, and celebrates increased investment in AI security 

AMSTERDAM – Open Source SecurityCon Europe – March 23, 2026 – The Open Source Security Foundation (OpenSSF), a cross-industry initiative of the Linux Foundation that focuses on sustainably securing open source software (OSS), today announced new members and key project momentum during Open Source SecurityCon Europe. 

New OpenSSF members include Helvethink, Spectro Cloud, and Quantrexion, who join the Foundation as General Members. As members, these companies will engage with working groups, contribute to technical initiatives, and help guide the strategic direction of the OpenSSF. Together, members support open, transparent, and community-driven security innovation, and the long-term sustainability of the Foundation.

“Open source security continues to evolve significantly in the face of new, automated threats,” said Steve Fernandez, General Manager of OpenSSF. “Our member organizations are seeding a more secure future, built with longevity in mind, by working with the OpenSSF. This network of projects, maintainers, and thousands of contributors is key to reinforcing reliable, sustainable open source software for all.”

Foundation Updates and Milestones

In the past quarter, OpenSSF has furthered its mission to secure open source software with the following achievements:

  • A new partnership with Kusari to offer Kusari Inspector at no cost to OpenSSF projects – this offering provides maintainers with deeper visibility into their software supply chains and enables proactive security checks at the pull request level.
  • The SLSA (Supply-chain Levels for Software Artifacts) project achieved Graduated status – this recognition advances SLSA’s stability, maturity, and broad adoption as a critical framework for supply chain integrity.
  • The release of the Gemara Project’s inaugural white paper – the findings outline a new framework for integrating security-as-code principles directly into the software development lifecycle.
  • The launch of new Special Interest Groups focused on Model Lifecycle Provenance and GPU-Based Model Integrity – these groups, under the AI/ML Security Working Group, expand the Foundation’s focus on securing the rapidly evolving field of AI/ML software security.
  • OpenSSF is approved as a CEN / CENELEC Liaison Organization for cybersecurity – this designation, through the Linux Foundation Europe, strengthens OpenSSF’s position in global standards development and policy influence.
  • The official launch of the OpenSSF Ambassador Program – applications are now open for the initial cohort.
  • Over 7,300 learners enrolled in OpenSSF’s free course, “Understanding the EU Cyber Resilience Act (LFEL1001)” – the Foundation has had over 75,000 enrollments in OpenSSF training programs to date.

OpenSSF growth follows the announcement of $12.5 million in grant funding awarded to OpenSSF and Alpha-Omega from leading AI providers. Funding from these leaders underscores broad industry support for more sustainable AI security assistance that empowers maintainers. Learn more about how OpenSSF and Alpha-Omega are using this grant to build long-term, sustainable security solutions, here. 

Supporting Quotes

“At Helvethink, we work at the intersection of cloud architecture, platform engineering, and DevSecOps. Open source components are foundational to modern infrastructure from Kubernetes and IaC tooling to CI/CD pipelines and security automation. Strengthening this ecosystem requires measurable standards, robust software supply chain security practices, and active collaboration across the community. By joining OpenSSF, we are actively participating in several working groups to contribute to initiatives focused on supply chain integrity, secure-by-design principles, and the continuous improvement of cloud-native security practices.”

– José Goncalves, co-founder, Helvethink

“Quantrexion is proud to join OpenSSF and support its mission to strengthen the security, resilience, and trustworthiness of open source software. As a company focused on governance and human risk management, we see secure open ecosystems as a critical part of long-term digital resilience.”

– Dionysis Karamitopoulos, CEO, Quantrexion

“Open source is the foundation of modern infrastructure — and its security is a shared responsibility. By joining the OpenSSF, Spectro Cloud is investing directly in the community work that raises the bar for everyone. Just as importantly, it strengthens the standards and practices behind the software we ship, so our customers can deploy Kubernetes with confidence in the integrity of every component. We’re proud to support the OpenSSF mission and to keep translating that momentum into real product capabilities that make secure software a default, not a bolt-on.”

– Saad Malik, CTO and co-founder, Spectro Cloud

Events and Gatherings

OpenSSF members are gathering this week in Amsterdam at Open Source SecurityCon Europe. To get involved with the OpenSSF community, join us at the following upcoming events:

Additional Resources

About the OpenSSF

The Open Source Security Foundation (OpenSSF) is a cross-industry organization at the Linux Foundation that brings together the industry’s most important open source security initiatives and the individuals and companies that support them. The OpenSSF is committed to collaboration and working both upstream and with existing communities to advance open source security for all. For more information, please visit us at openssf.org. 

Media Contact
Grace Lucier
The Linux Foundation

pr@linuxfoundation.org  

Mar 17
Love0

Leading Tech Coalition Invests $12.5 Million Through OpenSSF and Alpha-Omega to Strengthen Open Source Security

By Blog

Securing the open source software that underlies our digital infrastructure is a persistent and complex challenge that continues to evolve. The Linux Foundation announced a $12.5 million collective investment to be managed by Alpha-Omega and The Open Source Security Foundation (OpenSSF). This funding comes from key partners including Anthropic, Amazon Web Services (AWS), Google, Google DeepMind, GitHub, Microsoft, and OpenAI. The goal is to strengthen the security, resilience, and long-term sustainability of the open source ecosystem worldwide.

Building on Proven Success through OpenSSF Initiatives

This new investment provides critical support for OpenSSF’s proven, maintainer-centric initiatives. Targeted financial support is a key catalyst for sustained improvement in open source security. The results of the OpenSSF’s collective work in 2025 are clear:

  • Alpha-Omega invested $5.8 million in 14 critical open source projects and completed over 60 security audits and engagements.
  • Growing a Global Community: OpenSSF grew to 117 member organizations and was advanced by 267+ active contributors from 112 organizations, working across 10 Working Groups and 32 Technical Initiatives.
  • Driving Technical Impact: The OpenSSF Technical Advisory Council (TAC) awarded over $660,000 in funding across 14 Technical Initiatives, strengthening supply chain integrity, advancing transparency tools like Sigstore, and enabling community-driven security audits.
  • Measurable Security Uplift: Focused security engagements across critical projects resulted in 52 vulnerabilities fixed and 5 fuzzing frameworks implemented.
  • Expanding Education: Nearly 20,000 course enrollments across OpenSSF’s free training programs, with new courses like Security for Software Development Managers and Secure AI/ML-Driven Software Development empowering developers globally.
  • Global Policy Engagement: Launched the Global Cyber Policy Working Group and served as a challenge advisor for the Artificial Intelligence Cyber Challenge (AIxCC), ensuring the open source voice is heard in evolving regulations like the EU Cyber Resilience Act (CRA).

AI: A New Frontier in Security

The security landscape is changing fast. Artificial intelligence (AI) accelerates both software development and the discovery of vulnerabilities, which creates new demands on maintainers and security teams. However, OpenSSF recognizes that grant funding alone is not the sole solution to the problems AI tools are causing today on open source security teams. This moment also offers powerful new opportunities to improve how security work is completed.

This new funding will help the OpenSSF provide the active resources and dedicated projects needed to support overworked maintainers with the triage and processing of the increased AI-generated security reports they are currently receiving. Our response will feature global strategies tailored to the needs of maintainers and their communities.

“Open source software now underpins the majority of modern software systems, which means the security of that ecosystem affects nearly every organization and user worldwide,” said Christopher Robinson, CTO and Chief Security Architect at OpenSSF. “Investments like this allow the community to focus on what matters most: empowering maintainers, strengthening security practices across projects, and raising the overall security bar for the global software supply chain.”

Securing the Open Source Lifecycle

The true measure of success will be execution. Success is not about how much AI we introduce into open source. It is determined by whether maintainers can use it to reduce risk, remediate serious vulnerabilities faster, and strengthen the software supply chain long term. We are grateful to our funding partners for their commitment to this work, and we look forward to continuing it alongside the maintainers and communities that power the world’s digital systems.

“Our commitment remains focused: to sustainably secure the entire lifecycle of open source software,” said Steve Fernandez, General Manager of OpenSSF. “By directly empowering the maintainers, we have an extraordinary opportunity to ensure that those at the front lines of software security have the tools and standards to take preventative measures to stay ahead of issues and build a more resilient ecosystem for everyone.”

To learn more about open source security initiatives at the Linux Foundation, please visit openssf.org and alpha-omega.dev.

Mar 17
Love0

What’s in the SOSS? Podcast #56 – S3E8 Empowering New Maintainers: Inside the OpenSSF Mentorship Program

By Podcast

Summary

In this episode of What’s in the SOSS? host Sally Cooper sits down with Yesenia Yser, co-lead of the OpenSSF Mentorship Program and the BEAR Working Group, and Kairo De Araujo, Open Source Software Engineer and mentor for rstuf. They dive into the success of the OpenSSF Mentorship Program, which focuses on bringing underrepresented voices into software security. Kairo shares an incredible outcome from the last cycle – where two out of three mentees became project maintainers – while Yesenia discusses the evolution of the BEAR Working Group (Belonging, Empowerment, Allyship, and Representation) mentorship program. Whether you are a potential mentor or a mentee looking to break into open source, this episode provides a roadmap for the upcoming paid mentorship cycle.

Important Dates for the 2026 Mentorship Cycle:

  • Applications Open: March 24, 2026
  • Applications Close: April 12, 2026
  • Selection Period: April 13 – April 30, 2026
  • Notification Date: May 1, 2026
  • Onboarding: May 5 – May 29, 2026
  • Mentorship Period: June 1 – August 21, 2026

Conversation Highlights

00:01 – Welcome
01:43 – Kairo on his work with the Repository Service for TUF (rstuf).
02:30 – Yesenia on the BEAR Working Group and making open source accessible.
04:30 – The “Why” behind mentorship: Solving the barrier to entry for security beginners.
07:28 – Success strategies: Working as a team across time zones with multiple mentees.
09:28 – The ultimate goal: Moving mentees from learners to official project maintainers.
10:58 – Challenges and growing pains: Managing deadlines and interview chaos.
13:48 – Advice for Mentors: The importance of clear communication and flexibility.
15:02 – Advice for Mentees: Don’t be afraid to join; focus on “pre-onboarding”.
17:13 – Key Dates for the 2026 Mentorship Cycle.
20:15 – Call to Action: Get to know this year’s participating projects (gittuf, rstuf, SBOMit, Minder) and how to get involved.

Transcript

00:00 – Music & Intro clip

Sally Cooper (00:24)
Hello, hello and welcome back to What’s in the SOSS? An OpenSSF podcast where we get to talk to some amazing people who are involved in open source software and open source software security. And today we have a very special treat two repeat offenders coming back and they do some critical work in the OpenSSF community.

They have firsthand knowledge of the mentorship program, which we’re going to talk about today, which is a hands-on initiative designed to help underrepresented voices break into software security. So first, have Kairo. Hi, Kairo, an open source software engineer who served as one of the key mentors during last year’s program.

And we’re here to talk about the powerful impact of that mentorship program and also dive into the important work of the BEAR Working Group. So we have Yesenia also joining us from the perspective as a co-lead of the mentorship program in the BEAR Working Group. And I just have to say, Yesenia, it’s super nice to have you on this side of the microphone as a guest. So Kairo, Yesenia, welcome back and introduce yourselves.

Kairo De Araujo (01:43)
Yeah, thank you. Well, my name is Kairo, as you said, and I’m based in the Netherlands and I’m working as a software engineer for a few years. And the past six years, actually, I really focused on the security supply chain. And I’m an author of Repository Service for TUF (rstuf). That is a project to help the security supply chain, that’s part of OpenSSF. And I’m also maintainer of other critical open source projects in the security supply chain. Yeah, and last year, as you mentioned, and we’ll talk more about I participated in the mentorship program with the rstuf project, the repository size for tuf.

Yesenia (02:30)
Oh how the tables have turned tables. Hey everyone, soy Yesenia, not your co-host today, but a guest on today’s episode. I have a extensive background in security. I usually like to say I’ve been Jacqueline of all, cyber master of none, working in various umbrellas and have made my way into open source, love it, and do a lot of advocacy and outreach for it because of just the amazing folks that I’ve met on here that have done amazing things, as you’ve heard in many other episodes.

So, based out in the sunny state of Florida, I’ve seen snow once and then another time through a window. So I always forget that winter’s here. So if you show me snow in the background, I’m going to be so surprised. But that’s great. I love the work that we’re doing with bear. It was originally our DEI group. But since the man banned the word DEI, we chose the bear. So this is our belonging empowerment, allyship, and representation.

group in which we are making this more accessible for folks to enter into open source, giving them opportunities like these mentorships because I firsthand, have seen it from a mentorship that I’ve hosted several years ago. Seeing the folks that have come onto this mentorship enter into the field for very fancy Fortune 100 companies doing amazing work and align with their career. So, That’s a little about me and I’m excited for today’s episode.

Sally Cooper (04:02)
Wow, that’s incredible. It’s a lot to unpack. First off, the winter comet. I will get you back on that one. I’m going to send you lots of pictures of snow. But no, in all seriousness, it’s such great work that’s going on in the bear working group. for the mentorship program, maybe Kairo, can you tell me a little bit about like the why for your mentorship in open source security? What is the problem that you were trying to solve and by showing up for this?

Kairo De Araujo (04:30)
Well, besides security, it’s something really important. There are a lot of people that are a little bit afraid to step in in open source projects like that. Sometimes because they don’t have a huge security background, or they are just coming out of the university or learning coding, but they are not, let’s say, comfortable to step in in open source.

It happened with me as well. Everybody here once was like a beginner in something, and we need to trust ourselves. And I think that it’s really important for products like rstuf to get new people in, new ideas, and also looking to the future like a, keeping more contributors in the project or making, spreading the security, what we are doing, what the project is doing, because we know how it works. like spreading the knowledge, it’s not only talking about the project, but getting people involved in that. And we have some good engineers that would like to try it and they don’t have opportunity. And I think that, for example, this mentorship is a very good opportunity.

And me as a maintainer, I need more contributors for my project because we know that the success and how the product can grow, it’s based on contributions, right? People really writing code, understand how the project works. And this was our goal. Like let’s try to give opportunity to people to step in the project.

And give opportunities to people to understand how we can do security in different ways. Because rstuf is a really specific project based on the the update framework (TUF) that’s really complex. And maybe it can also give more knowledge to others to let’s contribute with a project in a way that I can participate and maybe grow, get knowledge and I don’t know, get a new job or…

Just knowing a little bit more about the language or the service or how I can help the security and participating in OpenSSF as well. Because it can be an entry point for people to get to the community as we have many different other products inside.

Sally Cooper (07:11)
Yeah, I love that. When you think about last year’s program, what would you say stands out the most? What worked better than you expected about the mentoring? And what lessons really stuck with you?

Kairo De Araujo (07:28)
Well, I have done a few mentorships before, not in OpenSSF, but in other companies that I worked at, helping junior engineers and so on. And usually we are afraid to have multiple mentees because how I will manage different people all together in one folks.

And what we experiment really last year that was really nice was to not get only one mentee, but at least three mentees in the product in the way that we can try to work as a team to not teach only about how to make the open source, but they could really feel how the open source works, how they can work from different time zones, from different projects and how, because we had people working documentation, another working on a specific feature and how these overlaps with each other and how we can work as a team.

This was something really that we did different in the project, giving a lot of freedom to them. Like we have the projects that we want to accomplish as the goal of the mentorship, but let’s try to work in the…as a team with a very flexible way that we can help each other. And really, this was very positive for the product last year. And everybody did very well.

Sally Cooper (09:06)
Yeah, it sounds like you set it up in a way with the freedom, the flexibility, you know, and the education to really do well. That’s great. I love to hear that. Just thinking back like to last year’s program, is there anything that surprised you and how did that shape the experience and how do think it will shape the experience going forward?

Kairo De Araujo (09:28)
What really surprised me was the commitment from the mentees. The process also for us to selecting the mentees with the proper like basic skill, not being really a job interview, right? Making it…understand what they can bring as a background to us was very nice. And…

But what surprised me in the end, and I think we will have another podcast about that in the future, that will be that now out of three…the two of the three mentees become maintainers of the project. It means that they started as mentees, then they jump as contributors of the project, and right now they are helping how to run the product. And this is…for me, is amazing as a maintainer. It’s really a relief for me, right? Because I have more people to help me running the product.

Sally Cooper (10:30)
Right best case scenario there. That’s an incredible outcome. I love to hear it. Okay, let’s shift gears. Yesenia, what would you say are some of the challenges or growing pains that you learned in running this program? And what did these lessons teach you? About how to build a sustainable mentorship program in an open source community that you could share with with our audience here

Yesenia (10:58)
Good question. Like first I want to say like… what Kairo just mentioned, the fact that these mentees go to maintainers is the ultimate goal. It doesn’t have to be one of the goals, but it’s one of the reasons we set up the mentorship was to allow folks to enter and come in and see these new projects that they may have never heard of or had visibility to. And really just come in and dive in, become part of a team and see…my experience with open source, it’s the same team kind of dynamic, but in a different aspect – as what you would feel and see in a corporate space.

So, hats off to you, Kairo and the maintainers. I’m very excited to interview them or at least hear the podcast once they’re on. So, future plug for when it will be released. And when we think back on last year’s mentorship, well, I had already done one with OpenSSF, the Linux Foundation.

One of the biggest challenge was the amount of time, right? So was the first time we had to do this. We had the deadlines and the maintainers had about a week to put together the project description. They had a week to like shift through all the mentees and interview them and make their selection. So there was a lot of chaos to the front. So big kudos to them to like push through and find the mentees and get that program kind of running.

I think once the program started running within a few weeks, it just kind of smoothed, and there was a lot less questions, was a lot less friction. And what we decided to do this year is just start early. So we won’t release the date just yet. You got to listen in a little bit further in the episode. But we are looking to run a next iteration of the mentorships, starting the program early, giving the mentees enough time before the official quote unquote start date to get onboarded. So that they can really take advantage of those 12 weeks. That’s kind of what we’re thinking of and just keep an eye out for later for those dates and important information.

Kairo De Araujo (13:04)
Yeah, I want to say that this year I will be participating again. And the good thing is that the mentees from last year will help me doing the mentorship. So we will distribute the tasks. So as you can see how beneficial it can be for our project and for mentors also, engaging to do that.

Sally Cooper (13:26)
Yeah, that’s really full circle. Thanks for sharing that. Well, since the mentorship cycle is on the horizon and the expectations are set or being set, if someone wanted to participate and join this year’s cycle for the first time, what would you give for a potential mentor for key advice based on what you did last time?

Kairo De Araujo (13:48)
Well, communication is the key because everybody is remote, everybody has different backgrounds. So, I advise to really making clear the communication with the mentees, understand what are the goals, understand what are their backgrounds, right? And we have preset projects within the product to be…done by the mentees.

Be flexible as well, because maybe you need to shape a little bit those projects to fit well for the mentees. These are my key advice that I can give. And focus on the communication with the folks, because they can deliver very good outcomes from that.

Sally Cooper (14:48)
Yeah, the outcomes will definitely come from communication. And that’s key. So for a potential mentee, what are expectations you’d set to help them make the most of this structured and paid opportunity?

Kairo De Araujo (15:02)
What I can say for the mentees is that don’t be afraid to join. Don’t care about your background or from where you are coming. You have something to help in the project. Work together with your mentor and now also work together if you have other mentees together with you in the mentorship program, try to work together. Because everybody is here to help. Be relaxed, try to do the best you can, get committed with what you want to deliver.

But as I said before to the mentors, communication, also communicate well. Ask questions, and try to help as well because you…And try to do what I always say, try to do a good pre-emboarding that it’s like, try to understand the project. I’m not saying that you need to know everything, just to understand what are you doing, what are the products, what you need to deliver and enjoy it because it’s really, really good.

Yesenia (16:17)
Yeah, one thing I wanted to jump in and add is for the project maintainers, if you need help with some of your onboarding documents, the BEAR working group is working through a process to create onboarding documents. So it is an added bonus that we can help you with that, especially if you’re a single maintainer or your team is just over at capacity right now. We are working through onboarding documents for OpenBao. So we could expand that process to other teams just to something on the floor to make it a lot easier.

Sally Cooper (16:51)
Wow, that’s so helpful. It’s really great to know that the bear working group’s doing that. For those listening who are excited to join the next cycle, can you walk us through those dates, Yesi, that we were talking about? So if you’ve stayed long enough for this, here’s your payoff because we’re gonna learn all about these upcoming dates.

Yesenia (17:13)
Yes, so the application will be released around March 24th and will be open for a few weeks ending April 12th. So that’s a good amount of time. Check us out at OpenSSF on our socials, on Slack, follow me on LinkedIn, me and Kairo, OpenSSF. I go ahead and will be reposting this and blasting it everywhere. Then from April 13th to April 30th, the mentors are going to be reviewing the applications. May 1st, you should expect an accepted decline notification by May 1st.

May 5th to the 29th, we’ll be working with getting you onboarded to the LF platform and onto the project. So this is when you’ll be getting your environment up, getting any documentation that could take some quiet time. So we’ll ask for you to be a part of it. And then the mentorship kicks off June 1st to August 21st. Within there, these we forgot to mention. This is a paid mentorship.

So, there are two evaluation points. July 10th will be your first evaluation. After that, you get half of the siphon. And then August 28th, that’s an important date for me, you get the final siphon from after you perform your evaluation. The cool part of this is not only do you get to do your mentorship program, but you’ll be part of a BEAR welcome call, where we would showcase your project.

So you’ll be able to get a public recording where you present the work that you’ve done over the mentorship. And as an option, as you heard previously, the mentees that became mentors will be on podcasts. So as an added option, if you’re welcome to share your voice, we will also love to interview you after the project for the OpenSSF, What’s in the SOSS Podcast.

These are great because you get to put them on your resume, you get to put them on your LinkedIn, show your parents, show your mom, show your dad, your grandma, your grandpa, your dog, whoever it is that you want to share it with. I definitely give my dogs my podcast episodes because they’re very proud of me. But those are just some key highlights and if you have more questions, find us on Slack and ask us and we’ll let you know.

Sally Cooper (19:43)
love it. And cats too. Plug to my cats.

Yesenia (19:47)
My cats are always here, so they hear everything anyway.

Sally Cooper (19:50)
Okay. Yeah, they hear it all. I love it. Well, thank you both so much. This has been a really interesting conversation. I learned a lot. Really excited for this next session. And to see all the great work that’s going to come out of it. Thank you. But before we wrap, are there any other calls to action for the audience if someone’s listening?

I know you gave the dates, what’s like the next best step for them?

Yesenia (20:15)
From the BEAR working group perspective, we have, we didn’t name the projects. We have gittuf, rstuf, thank you, SBOMit and Minder that are coming on board as mentors. So if you’re not sure what those are, take a moment, go to the openssf.org/getinvolved page, look at the working groups, check out their GitHub, get on Slack and check out the groups. Join one of the public calls. If you’re too nervous or introverted (I dropped after my first call, so don’t worry). Find different resources so you can be familiarized with the project that you might like and enjoy.

We also have a BEAR welcome call that we did in January that walks through all the working groups. So that’s also a good avenue to start. Let’s say you look at the projects, none of them really excite you. Mind you, they are paid. You can check out some of the other working groups and start getting involved in there as well.

Kairo De Araujo (21:18)
Yeah, even beside the mentorship, if you are not able to join the mentorship this summer, or if you don’t feel comfortable yet to join, our project repository service for tuf (rstuf) is really looking for new contributors. And we’ll do like in the mentorship, we’ll guide you to join the project, get the community, we’ll help you through that.

You can make a lot of difference out there if you want to collaborate with us. So everybody is welcome in our project as well.

Sally Cooper (21:54)
Fantastic. Well, Yessenia, Kairo, thank you so much for your time today and all the work that you’re doing for the mentorship program and the bear working group. We appreciate you both and to everyone listening, happy open sourcing and that’s a wrap.