

In this episode of “What’s in the SOSS,” Derek Zimmer and Amir Montezari from the Open Source Technology Improvement Fund (OSTIF) discuss their decade-long mission of providing security resources to open source projects. They focus on collaborative, maintainer-centric security audits that help projects improve their security posture through expert third-party reviews, without creating fear or overwhelming developers.
00:00 Introduction
00:22 Podcast Welcome
01:04 OSTIF Founders Introduction
02:31 OSTIF’s Mission and Approach
05:28 Relationship Management and Expertise
08:01 Evolution of Security Engagement Methods
12:15 Making Security Audits Less Intimidating
18:00 Rapid Fire Questions
20:45 Closing, Call to Action
CRob 0:22
Welcome, welcome. Welcome to What’s in the SOSS, the OpenSSF podcast, where I get to talk to some of those amazing people on the planet that are helping secure the open source software we all know we all use every day and that we love today, I have some very special friends with us that are doing the yeoman’s work trying to help work with projects to help improve their security posture. I have Amir and Derek from OSTIF. Can I give you guys just a brief moment to introduce yourselves?
Derek Zimmer: 0:54
Sure, I’m Derek Zimmer, founder of OSTIF. We’ve been doing this for 10 years now and take it away. Amir.
Amir Montezary: 1:04
Thank you. Amir Montezary, Managing Director of OSTIF, open source technology improvement fund, yeah, absolutely thrilled to be here on the podcast and to be talking with you, CRob, and to be talking about the work that we do. As Derek mentioned, this is our 10 year anniversary. So coming up on 10 years of really developing this organization, the processes and really fine tuning to a degree what we do and the value that we provide to the open source ecosystem. So absolutely thrilled to be here and to talk about it.
CRob 1:40
That’s amazing. So happy birthday OSTIF, for our audience that might not be familiar directly with your work. Could you maybe tell it? Tell us what OSTIF is, and what do you all do?
Derek 1:53
Sure. So we founded the organization 10 years ago on the idea that we needed a maintainer centric organization that could bring security resources to projects. There were some efforts in the past to do something similar to what we do, but most of the time, those were very corporate centric. So the ideas that circulated around them were very were dictating what open source should be doing and not we’re here to help. And here’s some resources so that that different perspective was the the kickoff for why we wanted to create something different.
Amir 2:36
Yeah, absolutely. And and still today we see that open source projects, because of their very nature, you know, they need a very strong, independent body to to help them. We provide that platform, being a nonprofit organization, being vendor neutral, being neutral in all senses of the word, and just solely focused on, as Derek mentioned, helping projects, getting them the security resources that they need, and in a way, most importantly, being able to provide those resources in a way that directly impacts the project and its security posture was really what drove us to start this organization. You know, typically, open source developers, maintainers, are not security experts, and that’s okay. Security is a very difficult topic, and like, like a lot of other things, it’s best to be left to the experts. So while, of course, there are things individual developers and maintainers can do to, you know, improve their their hygiene, so to speak, and improve the security posture of their projects, we found that getting independent third party expert audit review in a way that is again meant to be collaborative, as in, these auditors work with the maintainers, as opposed to kind of dictating to maintainers or telling them, you know, things to do, work with them on improving, kind of the holistic security posture of their project, and we found that to be really successful. A lot of research suggests that this is a very good practice to do. I come from a background in it, auditing, reviewing critical payment systems in the United States. That is a great field, and that we saw that that level of independent review, or third party review, that kind of due diligence, really helps improve the the state or posture of a software project. So so it was really. Founded on the need for it to exist. We saw there was a big need for this, that a mechanism to get security help, to open source projects, working directly with maintainers, and doing it in a way that is inclusive and impactful and most importantly, efficient, is kind of what drove us to do what we do, and so in terms of kind of how we do that, it’s largely a lot of just relationship management. So we’ve in the last 10 years, built a really vast network of security experts, researchers, a lot of which are solely focused in the open source security space, so they kind of understand some of the idiosyncrasies involved in open source software, and can, again, can actually provide meaningful review work and collaboration and essentially handle that whole process, because there are quite a lot of moving parts between. You know, typically you have a separate body funding the work, you have the maintainers or contributor base that could be very much distributed around the world. You don’t always have, I guess, established kind of decision making structures, as you might see in a corporate setting or in a more commercial environment. So we kind of handle all of that, all of that goodwill building, relationship building, project management, contract management, basically all of the pieces so that all that, all that’s needed for a funder, for example, someone who wants to fund security outcomes, or the project you know that would like to improve their security posture, they can just focus on that, and we, as an organization, as an independent body, essentially handle all of the all of the minutia and the administrivia and the facilitation and management to make it, to make it a very streamlined and efficient process. So that’s kind of high level overview.
CRob 7:23
As you both are aware, you have been long time participants and partners with our foundation and also our friends over at Alpha-Omega. From your perspective, kind of with your 10 years of working in this particular space. What do you all see as the main value that projects get out of these types of engagements?
Derek 7:47
So actually, this has changed over time, because we started out experimentally trying things just to see what works and what doesn’t. Initially, we started out as a bug bounty organization. So our concept was that companies would donate money to us, we’d establish bug bounties for projects, and then those projects would get the security benefits. What we quickly found out was this does not work well for projects that don’t have a lot of security resources, because they get buried in bunk reports things that are not actually problems. And then there’s also the bag bounties, where some dependency has a vulnerability, and then someone will go shop around to every project that depends on that dependency and try to get a bug bounty out of it and and so on and so forth. And then, increasingly, AI is also becoming a problem because it is doing automated reports to maintainers which are not accurate and then have to be thrown away, and they can be done at a much greater pace than an individual could just a few years ago. So essentially, we, we abandoned that entire thing and went to the idea of having professionals come in, give all of the support that they can give to the project, and kind of meet them where they are, and then extend their their testing so that they get long term benefit from the review as well. So So it started out with skin in our knees and finding stuff that didn’t really work, and then progressed over time, after a lot of feedback to where we are now, which seems to be extremely helpful.
Amir 09:34
So yeah, and to echo that, I would say, I would say the main value of our engagements is that direct impact. You know, we go directly to the project, to the main work with the maintainers or contributors of a project, actually going to the source. You know, the source as in reviewing and improving the code of a project. Project its design, and as Derek mentioned, one way we’ve added even more value as part of our engagements over time is creating or augmenting tooling for projects as well, so that they can continue to have security scrutiny and tools that can help them in their development cycles and to help projects mature. So I would say that that direct focus on the projects, on their code base and on the on the tried and true practice of a expert third party review is how we’re really delivering a lot of value. I would say through our engagements, we’re coming up, as I mentioned on our on our 10 year anniversary next month, and I think we have found well over 100 high or critical vulnerabilities and these projects as parts of our as part of our audits. Thank you. Thank you. We’re really we’re really proud of what we’ve been able to do and the positive impact we’ve been able to make. And yeah, and I think that really comes from sticking to our mission and to our commitment to this best practice of, you know, expert third party review, but doing it in a way that is collaborative and impactful. So so we didn’t just find all of those, those vulnerabilities, those have all been fixed and remediated, and a lot of those, at least a good portion of them were kind of design bugs or or classes of bugs that very well, you know, could eliminate future problems very effectively, not in a, unfortunately, not in a very Easily, easy to measure way, but, but the feedback suggests that the projects are, in fact, much in a much better state after our engagements. So we’re really happy to be able to do that.
CRob 12:15
That’s phenomenal. I love the fact that you all started off in one direction, and then you learned a little bit, and you’ve pivoted so you’ve evolved yourselves. Thinking about your engagements over the last almost decade, is there one thing you wish a project or a developer knew or did prior to coming into one of these engagements that would make the whole enterprise be more successful or go more smoothly. What was one thing you wish people did or knew?
Derek 12:46
So the big takeaway is that if you do a security engagement with us, it’s not scary, because we are here to help. We will offer you any support and resources that we have. You know we’re not going to find a big pile of bugs that you don’t understand, dump a document on you and walk away. The whole point of this is to help projects improve by giving them everything that they need and meeting them where they are. So the FAQ we usually get from maintainers is, you know, how long is this going to take? How much time do I have to invest into this? And then always the questions about, are you going to drop zero days on me at the end of this engagement? And of course, we follow disclosure policies that everybody agrees on and also we are very flexible. So if there’s a design level problem that requires a big rewrite, we’re not going to just drop it on the internet in 90 days. We’re going to be forgiving. So the pressure from us is very low, and I think that that’s one thing that maintainers would really like to hear from, you know, working with us.
Amir 14:07
yeah, plus one to that, Derek, I would say it’s very not meant to be a collaboration. It’s meant to be a engagement that is collaborative in nature. And I, I do wish more developers knew that it wasn’t as again, to echo you Derek, it’s not, it’s not a scary thing. It’s not you’re like, you’re going to be going in front of a tribunal, and you know, it’s very much, let’s work together to make this project better. And I’ve, I’ve I’ve observed personally that it’s one of those types of things where the more you put in, so the more that developers, maintainers, contributors, the more that they’re able to put into the engagement, in terms of providing audit teams with in. Site or with feedback or context, because I think that’s the piece that really is missing significantly with a lot of the, as Derek mentioned, kind of the tooling and some of the other kind of at scale things that at scale solutions, they really lack that context that is really important, especially in terms of security, when it comes to security in a code base, so it definitely has a multiplier effect. You know, the more we’ve seen projects being engaged in the audit, typically, we found much better results. And I can even give a direct case study example, where one an engagement that we were involved in. The audit team and the developer team happened to be our train ride apart, so they were able to arrange, essentially, an in person kind of orientation, kind of to really just discuss and get to know each other and gets in, you know, it was a really cool thing, and we learned that that led to a much better understanding of the code base as the team was auditing it, and that allowed them to find more significant findings, because, again, they had that greater understanding as a result of the context provided By the by the team and and, and actually that that same team that we worked with on this direct engagement yesterday at one of our virtual meetups, we learned that they did something similar. So their client wasn’t as was a quick it was a flight. But flights in Europe are shorter just and they were able to get together with the with the main maintainers of the project, and do, again, a very similar thing, where they were able to get together discuss, and that led to a much better understanding of the project, and allowed the auditors to add that much more value as part of the audit. So I to sum it up, I would say, as I said, add value. That’s I would that’s how I would sum it up. Is that I wish more developers knew that this is about adding value. It’s about collaborating. It’s not about, you know, making you feel bad about making mistakes or anything like that. You know, human beings will always, will always, you know, will always have that, that, you know, human error, and it’s totally normal and fine. And that’s why this as a practice is so important, because, you know, it’s such a common practice in software and really in the in the greater kind of landscape, you know, independent review. And so, yeah, I would say, you know, it’s meant to be collaborative. It’s not the scary thing. It’s really more about, as Derek said, helping and giving you resources to make your project better than anything else.
CRob 17:53
That’s amazing, and I really appreciate just kind of the innovative ideas and the coming to where the project is mentality and really you guys are making sure that security audits aren’t scary at all. But let’s move on to the rapid fire part of the interview. Are you ready for rapid rapid rapid fire? Got a couple wacky questions. Just give me the first thoughts to come out of your mouths, vi or Emacs?
Derek 18:22
oh, VI
Amir 18:25
yeah. Second that excellent.
CRob 18:26
There are no wrong answers, but there are better answers than others, right? What’s your favorite open source mascot?
Derek 18:36
Oh, I’d have to say the VLC cone. Nice, just because it’s nonsense, and they admit that it’s nonsense, and they constantly get asked about it and give nonsense answers. So it’s fantastic.
Amir 18:51
That’s a good point. And you can always tell who the VLC people are at, like FOSDEM, for example, because they have the big, the big cone on the head. And that’s a really good question. There’s a lot of really good ones out there. I’ve honestly found that the this the simpler ones mascots are, I tend to remember them more, but there’s, I’d say, for me, there’s too many good ones to pick so…
CRob 19:16
That’s a very diplomatic answer. I appreciate that. Spicy or mild food?
Derek 19:22
spicy all the way
CRob 19:28
nice, that is always the right answer.
Amir 19:30
Some of our greatest ideas came over spicy food. So…
CRob 19:35
And finally, and most importantly, Star Trek, or Star Wars.
Derek 19:40
So I’d say I’m Star Trek. I I like the idea of everybody working together toward, you know, a peaceful, wide, reaching society,
CRob 19:52
Open source of you. That’s awesome.
Amir 19:54
I would also say Star Trek. I missed the Star Wars kind of lore growing up, yeah, my experience with Star Wars, I had a high school teacher who, anytime he would not be able to make class, instead of a substitute teacher, he would just play the beginning of the first Star Wars movie. I think it was episode four, so I’ve seen the first 30 minutes plenty of times. So maybe that left a bad taste in my mouth with Star Wars.
CRob 20:27
I see we’ve had very different life experiences. That’s great. Well, thank you, gentlemen. I really appreciate you putting up with the nonsense. And then finally, as we wrap up, do you have a call to action for the community or developers, as we kind of close out
Derek 20:45
Sure, I would say we really operate on the principles of Spoon Theory. Have you ever heard of that? It’s from psychology. And the principle is that you have so many spoons of energy that you can devote to various things, and the way that we apply this to open source is thinking about the security knowledge and the just general energy available among open source communities. Some of them are very well supported. They have dedicated staff that are paid, and it’s their job to be there and be available. And then you have the complete opposite end of the spectrum, which is a solar solo maintainer invented a thing. That thing somehow became a really important piece of infrastructure. They don’t have any security knowledge, so they do what they can, you know, reading documents and and whatever, but they don’t have the available energy to invest in security so that that’s where I’m coming from. When I say, meet projects, where they are, and the call to action would be, if you are a security researcher and you’re interacting with open source, this is what you need to consider is their position on that spectrum of knowledge and available energy. So…
CRob 22:09
Amir?
Amir 22:10
Yeah, plus one to that, and to add, I would just say that if there’s one thing I’ve learned, you know, from doing this for 10 years, it’s that. It’s it’s important work, and it needs there. There’s almost an unlimited demand for it. You know, I was really shocked when I saw how some of the you know, projects, biggest names and open source projects, household names that we hear every day, really needed almost the same, if not more, security help than maybe the smaller projects, because, for example, some of the really big projects, because they have so much more scrutiny, they have a lot more noise to go through, for example, or they have, they could potentially have huge backlogs of bugs that they just haven’t gotten the time or resources to go through. And so I think my call to action would be, you know, we are one of the one tool in the in the toolkit, but I do think what we do really does help open source projects and we can do more with more. So we always are typically trying to do the most we can with what we have and which we always do, of course, but I think we really could do more with more so we can add more more help for projects, more diligence for projects, more ongoing support for projects. The work that we’ve been doing, doing tooling, augmentations, for example, has been really successful. And, you know, we, and we as a small organization, we are always happy and willing to take on more work. So we’re always open to new collaborations, new collaborate tours and helping how we can to fulfill our mission, which has been to help open source projects improve their security. So yeah, come talk to us. We’re involved in a lot of the open source security foundation working groups and events. As you mentioned, we’ve been strategic partner for Linux Foundation and OpenSSF for some time now. So yeah, we are always happy to collaborate and help how we can in the nature of open source. And so I’d say that’s that’s all I have. All right,
CRob 24:38
Derek and Amir from OSTIF, thank you all for your amazing work and helping collaborate with our developer community, and that’s going to be a wrap. Happy open sourcing, everybody. We’ll talk to you all soon. Goodbye.
Amir
Cheers, everyone. Thanks.
Outro
Like what you’re hearing. Be sure to subscribe to What’s in the SOSS on Spotify, Apple podcasts and Antenna, Pocket Cast, or wherever you get your podcasts. There’s a lot going on with the OpenSSF, and many ways to stay on top of it all. Check out the newsletter for open source news, upcoming events and other happenings. Go to openssf.org/newsletter to subscribe. Connect with us on LinkedIn for the most up to date. OpenSSF, news and insight and be a part of the OpenSSF community. At OpenSSF.org/getinvolved. Thanks for listening, and we’ll talk to you next time on What’s in the SOSS.
By Jeff Diecks
The OpenSSF team will be attending DEF CON 33, where the winners of the AI Cyber Challenge (AIxCC) will be announced. We will also host a panel discussion at the AIxCC village to introduce the concept of MLSecOps.
AIxCC, led by DARPA and ARPA-H, is a two-year competition focused on developing AI-enabled software to automatically identify and patch vulnerabilities in source code, particularly in open source software underpinning critical infrastructure.
OpenSSF is supporting AIxCC as a challenge advisor, guiding the competition to ensure its solutions benefit the open source community. We are actively working with DARPA and ARPA-H to open source the winning systems, infrastructure, and data from the competition, and are designing a program to facilitate their successful adoption and use by open source projects. At least four of the competitors’ Cyber Resilience Systems will be open sourced on Friday, August 8 at DEF CON. The remaining CRSs will also be open sourced soon after the event.
We will be hosting a panel talk at the AIxCC Village, “Applying DevSecOps Lessons to MLSecOps.” This presentation will delve into the evolving landscape of security with the advent of AI/ML applications.
The panelists for this discussion will be:
Just as DevSecOps integrated security practices into the Software Development Life Cycle (SDLC) to address critical software security gaps, Machine Learning Operations (MLOps) now needs to transition into MLSecOps. MLSecOps emphasizes integrating security practices throughout the ML development lifecycle, establishing security as a shared responsibility among ML developers, security practitioners, and operations teams. When thinking about securing MLOps using lessons learned from DevSecOps, the conversation includes open source tools from OpenSSF and other initiatives, such as Supply-Chain Levels for Software Artifacts (SLSA) and Sigstore, that can be extended to MLSecOps. This talk will explore some of those tools, as well as talk about potential tooling gaps the community can partner to close. Embracing this methodology enables early identification and mitigation of security risks, facilitating the development of secure and trustworthy ML models. Embracing MLSecOps methodology enables early identification and mitigation of security risks, facilitating the development of secure and trustworthy ML models.
We invite you to join us on Saturday, August 9, from 10:30-11:15 a.m. at the AIxCC Village Stage to learn more about how the lessons from DevSecOps can be applied to the unique challenges of securing AI/ML systems and to understand the importance of adopting an MLSecOps approach for a more secure future in open source software.
Jeff Diecks is the Technical Program Manager for the AI Cyber Challenge (AIxCC) at the Open Source Security Foundation (OpenSSF). A participant in open source since 1999, he’s delivered digital products and applications for dozens of universities, six professional sports leagues, state governments, global media companies, non-profits, and corporate clients.
By Sarah Evans and Andrey Shorov
The world of technology is constantly evolving, and with the rise of Artificial Intelligence (AI) and Machine Learning (ML), the demand for robust security measures has become more critical than ever. As organizations rush to deploy AI solutions, the gap between ML innovation and security practices has created unprecedented vulnerabilities we are only beginning to understand.
A new whitepaper, “Visualizing Secure MLOps (MLSecOps): A Practical Guide for Building Robust AI/ML Pipeline Security,” addresses this critical gap by providing a comprehensive framework for practitioners focused on building and securing machine learning pipelines.
Why this topic? Why now?
AI/ML systems encompass unique components, such as training datasets, models, and inference pipelines, that introduce novel weaknesses demanding dedicated attention throughout the ML lifecycle.
The evolving responsibilities within organizations have led to an intersection of expertise:
These trends have exposed a gap in security knowledge, leaving AI/ML pipelines susceptible to risks that neither discipline alone is fully equipped to manage. To resolve this, we investigated how we could adapt the principles of secure DevOps to secure MLOps by creating an MLSecOps framework that empowers both software developers and AI-focused professionals with the tools and processes needed for end-to-end ML pipeline security. During our research, we identified a scarcity of practical guidance on securing ML pipelines using open-source tools commonly employed by developers. This white paper aims to bridge that gap and provide a practical starting point.
This whitepaper is the result of a collaboration between Dell and Ericsson, leveraging our shared membership in the OpenSSF with the foundation stemming from a publication on MLSecOps for telecom environments authored by Ericsson researchers [https://www.ericsson.com/en/reports-and-papers/white-papers/mlsecops-protecting-the-ai-ml-lifecycle-in-telecom]. Together, we have expanded upon Ericsson’s original MLSecOps framework to create a comprehensive guide that addresses the needs of diverse industry sectors.
We are proud to share this guide as an industry resource that demonstrates how to apply open-source tools from secure DevOps to secure MLOps. It offers a progressive, visual learning experience where concepts are fundamentally and visually layered upon one another, extending security beyond traditional code-centric approaches. This guide integrates insights from CI/CD, the ML lifecycle, various personas, a sample reference architecture, mapped risks, security controls, and practical tools.
The document introduces a visual, “layer-by-layer” approach to help practitioners securely adopt ML, leveraging open-source tools from OpenSSF initiatives such as Supply-Chain Levels for Software Artifacts (SLSA), Sigstore, and OpenSSF Scorecard. It further explores opportunities to extend these tools to secure the AI/ML lifecycle using MLSecOps practices, while identifying specific gaps in current tooling and offering recommendations for future development.
For practitioners involved in the design, development, deployment, and operations as well as securing of AI/ML systems, this whitepaper provides a practical foundation for building robust and secure AI/ML pipelines and applications.
Ready to help shape the future of secure AI and ML?
Join the AI/ML Security Working Group
Sarah Evans delivers technical innovation for secure business outcomes through her role as the security research program lead in the Office of the CTO at Dell Technologies. She is an industry leader and advocate for extending secure operations and supply chain development principles in AI. Sarah also ensures the security research program explores the overlapping security impacts of emerging technologies in other research programs, such as quantum computing. Sarah leverages her extensive practical experience in security and IT, spanning small businesses, large enterprises (including the highly regulated financial services industry and a 21-year military career), and academia (computer information systems). She earned an MBA, an AIML professional certificate from MIT, and is a certified information security manager. Sarah is also a strategic and technical leader representing Dell in OpenSSF, a foundation for securing open source software.
Andrey Shorov is a Senior Security Technology Specialist at Product Security, Ericsson. He is a cybersecurity expert with more than 16 years of experience across corporate and academic environments. Specializing in AI/ML and network security, Andrey advances AI-driven cybersecurity strategies, leading the development of cutting-edge security architectures and practices at Ericsson and contributing research that shapes industry standards. He holds a Ph.D. in Computer Science and maintains CISSP and Security+ certifications.
August 2025 marks five years since the official formation of the Open Source Security Foundation (OpenSSF). Born out of a critical need to secure the software supply chains and open source ecosystems powering global technology infrastructure, OpenSSF quickly emerged as a community-driven leader in open source security.
“OpenSSF was founded to unify and strengthen global efforts around securing open source software. In five years, we’ve built a collaborative foundation that reaches across industries, governments, and ecosystems. Together, we’re building a world where open source is not only powerful—but trusted.” — Steve Fernandez, General Manager, OpenSSF
OpenSSF was launched on August 3, 2020, consolidating earlier initiatives into a unified, cross-industry effort to protect open source projects. The urgency was clear—high-profile vulnerabilities such as Heartbleed served as stark reminders that collective action was essential to safeguard the digital infrastructure everyone depends on.
“From day one, OpenSSF has been about action—empowering the community to build and adopt real-world security solutions. Five years in, we’ve moved from ideas to impact. The work isn’t done, but the momentum is real, and the future is wide open.” — Christopher “CRob” Robinson, Chief Architect, OpenSSF
Over the past five years, OpenSSF has spearheaded critical initiatives that shaped the landscape of open source security:
2021 – Secure Software Development Fundamentals:
Launching free educational courses on edX, OpenSSF equipped developers globally with foundational security practices.
“When we launched our first free training course in secure software development, we had one goal: make security knowledge available to every software developer. Today, that same mission powers all of OpenSSF—equipping developers, maintainers, and communities with the tools they need to make open source software more secure for everyone.” — David A. Wheeler, Director, Open Source Supply Chain Security, Linux Foundation
2021 – Sigstore: Open Source Signing for Everyone:
Sigstore was launched to make cryptographic signing accessible to all open source developers, providing a free and automated way to verify the integrity and provenance of software artifacts and metadata.
“Being part of the OpenSSF has been crucial for the Sigstore project. It has allowed us to not only foster community growth, neutral governance, and engagement with the broader OSS ecosystem, but also given us the ability to coordinate with a myriad of in-house initiatives — like the securing software repos working group — to further our mission of software signing for everybody. As Sigstore continues to grow and become a core technology for software supply chain security, we believe that the OpenSSF is a great place to provide a stable, reliable, and mature service for the public benefit.”
— Santiago Torres-Arias, Assistant Professor at Purdue University and Sigstore TSC Chair Member
2021-2022 – Security with OpenSSF Scorecard & Criticality Score:
Innovative tools were introduced to automate and simplify assessing open source project security risks.
“The OpenSSF has been instrumental in transforming how the industry approaches open source security, particularly through initiatives like the Security Scorecard and Sigstore, which have improved software supply chain security for millions of developers. As we look ahead, AWS is committed to supporting OpenSSF’s mission of making open source software more secure by default, and we’re excited to help developers all over the world drive security innovation in their applications.” — Mark Ryland, Director, Amazon Security at AWS
2022 – Launch of Alpha-Omega:
Alpha-Omega (AO), an associated project of the OpenSSF launched in February 2022, is funded by Microsoft, Google, Amazon, and Citi. Its mission is to enhance the security of critical open source software by enabling sustainable improvements and ensuring vulnerabilities are identified and resolved quickly. Since its inception, the Alpha-Omega Fund has invested $14 million in open source security, supporting a range of projects including LLVM, Java, PHP, Jenkins, Airflow, OpenSSL, AI libraries, Homebrew, FreeBSD, Node.js, jQuery, RubyGems, and the Linux Kernel. It has also provided funding to key foundations and ecosystems such as the Apache Software Foundation (ASF), Eclipse Foundation, OpenJS Foundation, Python Foundation, and Rust Foundation.
2023 – SLSA v1.0 (Supply-chain Levels for Software Artifacts):
Setting clear and actionable standards for build integrity and provenance, SLSA was a turning point for software supply chain security and became essential in reducing vulnerabilities.
At the same time, community-driven tools like GUAC (Graph for Understanding Artifact Composition) built on SLSA’s principles, unlocking deep visibility into software metadata, making it more usable, actionable and connecting the dots across provenance, SBOMs and in-toto security attestations.
“Projects like GUAC demonstrate how open source innovation can make software security both scalable and practical. Kusari is proud to have played a role in these milestones, helping to strengthen the resiliency of the open source software ecosystem.”
— Michael Lieberman, CTO and Co-founder at Kusari and Governing Board member
2024 – Principles for Package Repository Security:
Offering a voluntary, community-driven security maturity model to strengthen the resilience of software ecosystems.
“Developers around the world rely daily on package repositories for secure distribution of open source software. It’s critical that we listen to the maintainers of these systems and provide support in a way that works for them. We were happy to work with these maintainers to develop the Principles for Package Repository Security, to help them put together security roadmaps and provide a reference in funding requests.” — Zach Steindler, co-chair of Securing Software Repositories Working Group, Principal Engineer, GitHub
2025
OSPS Baseline:
This initiative brought tiered security requirements into the AI space, quickly adopted by groundbreaking projects such as GUAC, OpenTelemetry, and bomctl.
“The Open Source Project Security Baseline was born from real use cases, with projects needing robust standardized guidance around how to best secure their development processes. OpenSSF has not only been the best topical location for contributors from around the world to gather — the foundation has gone above and beyond by providing project support to extend the content, promote the concept, and elevate Baseline from a simple control catalog into a robust community and ecosystem.” — Eddie Knight, OSPO Lead, Sonatype
AI/ML Security Working Group:
The MLSecOps White Paper from the AI/ML Security Working Group marks a major step in securing machine learning pipelines and guiding the future of trustworthy AI.
“The AI/ML working group tackles problems at the confluence of security and AI. While the AI world is moving at a breakneck pace, the security problems that we are tackling in the traditional software world are also relevant. Given that AI can increase the impact of a security vulnerability, we need to handle them with determination. The working group has worked on securing LLM generating code, model signing and a new white paper for MLSecOps, among many other interesting things.” — Mihai Maruseac, co-chair of AI/ML Security Working Group, Staff Software Engineer, Google
OpenSSF’s role rapidly expanded beyond tooling, becoming influential in global policy dialogues, including advising the White House on software security and contributing to critical policy conversations such as the EU’s Cyber Resilience Act (CRA).
OpenSSF also continues to invest in community-building and education initiatives. This year, the Foundation launched its inaugural Summer Mentorship Program, welcoming its first cohort of mentees working directly with technical project leads to gain hands-on experience in open source security.
The Foundation also supported the publication of the Compiler Options Hardening Guide for C and C++, originally contributed by Ericsson, to help developers and toolchains apply secure-by-default compilation practices—especially critical in memory-unsafe languages.
In addition, OpenSSF has contributed to improving vulnerability disclosure practices across the ecosystem, offering guidance and tools that support maintainers in navigating CVEs, responsible disclosure, and downstream communication.
“The OpenSSF is uniquely positioned to advise on considerations, technical elements, and community impact public policy decisions have not only on open source, but also on the complex reality of implementing cybersecurity to a diverse and global technical sector. In the past 5 years, OpenSSF has been building a community of well-informed open source security experts that can advise regulations but also challenge and adapt security frameworks, law, and regulation to support open source projects in raising their security posture through transparency and open collaboration; hallmarks of open source culture.” — Emily Fox, Portfolio Security Architect, Red Hat
Key community members, from long-standing contributors to new voices, have shaped OpenSSF’s journey:
OG Voices:
“Microsoft joined OpenSSF as a founding member, committed to advancing secure open source development. Over the past five years, OpenSSF has driven industry collaboration on security through initiatives like Alpha-Omega, SLSA, Scorecard, Secure Software Development training, and global policy efforts such as the Cyber Resilience Act. Together, we’ve improved memory safety, supply chain integrity, and secure-by-design practices, demonstrating that collaboration is key to security. We look forward to many more security advancements as we continue our partnership.” — Mark Russinovich, CTO, Deputy CISO, and Technical Fellow, Microsoft Azure
OpenSSF Leadership Perspective:
“OpenSSF’s strength comes from the people behind it—builders, advocates, and champions from around the world working toward a safer open source future. This milestone isn’t just a celebration of what we’ve accomplished, but of the community we’ve built together.” — Adrianne Marcum, Chief of Staff, OpenSSF
Community Perspectives:
“After 5 years of hard work, the OpenSSF stands as a global force for securing the critical open-source that we all use. Here’s to five years of uniting communities, hardening the software supply chain, and driving a safer digital future.” Tracy Ragan, CEO, DeployHub
“I found OpenSSF through my own curiosity, not by invitation, and I stayed because of the warmth, support, and shared mission I discovered. From contributing to the BEAR Working Group to receiving real backing for opportunities, the community consistently shows up for its members. It’s more than a project; it’s a space where people are supported, valued, and empowered to grow.” Ijeoma Onwuka, Independent Contributor
As we celebrate our fifth anniversary, OpenSSF is preparing for a future increasingly influenced by AI-driven tools and global collaboration. Community members across the globe envision greater adoption of secure AI practices, expanded policy influence, and deeper, inclusive international partnerships.
“As we celebrate OpenSSF’s 5th Anniversary, I’m energized by how our vision has grown into a thriving global movement of developers, maintainers, security researchers, and organizations all united by our shared mission. Looking ahead we’re hoping to cultivate our community’s knowledge and empower growth through stronger collaboration and more inclusive pathways for contributors.” – Stacey Potter, Community Manager, OpenSSF
We invite you to share your memories, contribute your voice, and become part of the next chapter in securing open source software.
Here’s to many more years ahead! 🎉
Welcome to the July 2025 edition of the OpenSSF Newsletter! Here’s a roundup of the latest developments, key events, and upcoming opportunities in the Open Source Security community.
The Call for Proposals for OpenSSF Community Day Korea is closing Aug 3! If you have insights, tools, research, or community stories to share around open source software security, now is the time to submit your talk. The event takes place on November 4, 2025, in Seoul, South Korea, and brings together developers, researchers, and security professionals from across the open source and security ecosystems.
Whether your focus is on AI and security, vulnerability management, education, or tooling, we welcome submissions in a variety of formats, from quick 5-minute talks to extended 20-minute sessions. Deadline to submit: August 3, 2025, at 23:59 KST / 06:59 PST.
Share your expertise and help shape the future of open source security. We look forward to seeing you in Seoul!
In our recent blog post, David A. Wheeler introduces the Cyber Resilience Act (CRA) Brief Guide for OSS Developers, a practical overview created by the OpenSSF to help open source developers understand and prepare for the EU’s new cybersecurity regulation. Although the CRA officially applies only within the EU, its global impact is significant due to the international nature of software distribution. The blog clarifies when the CRA does or does not apply to OSS, outlines potential risks for non-compliance, and highlights available resources including free training and community support to help developers build secure, compliant software. Read the full blog.
OpenSSF Community Day Japan 2025 brought together developers, researchers, government, and industry leaders in Tokyo to advance open source software security. The event featured keynotes, technical sessions, and a live incident response exercise focused on secure development, tool adoption, and supply chain integrity.
Read the full blog for session videos, slides, and key takeaways.
OpenSSF Community Day NA 2025 brought together a diverse open source security community in Denver for a packed day of insights, tools, and collaboration. From real-world deployments of SBOM, Sigstore, and GUAC to securing AI pipelines and exploring the new AStRA control plane framework, sessions moved beyond awareness into action.
Read the full blog for recordings, slides, key takeaways and ways to get involved.
The on-demand webinar Cybersecurity Skills, Simplified: A Framework That Works brings together experts from IBM, Intel, Linux Foundation Education, and OpenSSF to address a critical challenge: making cybersecurity a shared responsibility across all roles. The panel introduces the Cybersecurity Skills Framework, an open, flexible tool that helps teams identify, map, and improve security skills organization-wide. With insights on setting security OKRs, scaling training, and creating accessible learning pathways, this webinar offers practical guidance for anyone looking to strengthen their team’s security posture. Learn more.
#35 – S2E12 Building India’s Open Source Security Community: From Developer Nation to Security Champions
In this episode of What’s in the SOSS?, host CRob sits down with Ram Iyengar, OpenSSF’s India community representative, to explore the evolving landscape of open source security in India. Ram shares his journey from professor to evangelist, the launch of LF India, and the challenges of inspiring a security-first mindset in one of the world’s largest developer populations. The episode covers everything from building local community momentum to hosting regional events and video series, offering listeners both practical insights and a personal look at the passionate effort behind India’s growing open source security movement.
#34 – S2E11 From Lockpicking to Leadership: Tabatha DiDomenico on Security, Open Source, and Building Community
In this episode of What’s in the SOSS? host Yesenia Yser sits down with Tabatha DiDomenico, open source security engineer, community leader, and president of BSides Orlando for a compelling conversation about her unconventional path into open source, the power of community, and the often-overlooked impact of DevRel. From her first experience with Netscape to shaping security strategy at G-Research and OpenSSF, Tabatha reflects on how curiosity, volunteering, and intentional advocacy have fueled her journey. Whether you are new to open source or a longtime contributor, this episode offers heartfelt insights, practical advice, and a powerful reminder: community is everything.
The Open Source Security Foundation (OpenSSF), together with Linux Foundation Education, provides a selection of free e-learning courses to help the open source community build stronger software security expertise. Learners can earn digital badges by completing offerings such as:
These are just a few of the many courses available for developers, managers, and decision-makers aiming to integrate security throughout the software development lifecycle.
Join us at OpenSSF Community Day Events in India, Japan, Korea and Europe!
OpenSSF Community Days bring together security and open source experts to drive innovation in software security.
Connect with the OpenSSF Community at these key events:
Ways to Participate:
There are a number of ways for individuals and organizations to participate in OpenSSF. Learn more here.
You’re invited to…
We want to get you the information you most want to see in your inbox. Missed our previous newsletters? Read here! Have ideas or suggestions for next month’s newsletter about the OpenSSF? Let us know at marketing@openssf.org, and see you next month!
Regards,
The OpenSSF Team
In this episode of ‘What’s in the SOSS” CRob dives deep into the Erlang ecosystem with Jonatan Männchen (CISO, Erlang Ecosystem Foundation), Ulf Riehm (Product Owner, Herrmann Ultraschall), and Michael Winser (Alpha-Omega). This episode explores the critical importance of security in open source, particularly in light of regulations like the CRA. Hear how the Erlang community is proactively addressing security concerns by bringing in experts, fostering collaboration, and building trust. Discover why manufacturers are investing in upstream projects and how other ecosystems can learn from their approach. This conversation highlights the value of community, transparency, and the essential role of ‘stewards’ in the open source world.
00:00 Welcome
00:57 Meet the Guests
02:56 Jonatan’s Journey into Erlang
06:16 The Alpha-Omega Connection
09:07 Ulf’s Perspective as a Product Manager
13:09 Funding Security in Open Source
18:58 Challenges in Implementing Security
24:54 Becoming a CNA and Normalizing Security
28:18 Jonatan’s role as CISO
32:01 Calls to Action & Advice
36:49 Wrap Up
CRob (00:14)
Welcome, welcome, welcome to What’s in the SOSS, the OpenSSF’s podcast where we meet interesting people that are in and around the upstream open source ecosystem. My name’s CRob. I’m the chief security architect for the foundation, and I also do security stuff upstream to help protect that open source software we all know and love. And today I have an amazing collection of gentlemen here, and we’re talking about a very important topic. It’s about the value of bringing experts in.
So I would like to pass the microphone around. I’ll start off with Jonatan. Let’s introduce ourselves and kind of talk about what brought you here today to talk about this interesting topic.
Jonatan Männchen (00:57)
Yeah. Hi, I’m Jonathan Männchen. I’m the Chief Information Security Officer at the Erlang Ecosystem Foundation. And the reason I’m here today is that we’ve started implementing a lot of functionality in the security and in the compliance sector, mostly focused on the CRA. And based on that, I’ve met CRob and Michael, these lovely gentlemen in the Alpha and Omega call and was invited to come here and talk about it all.
CRob (01:31)
Ulf
Ulf (01:33)
Yeah, I’m a product owner with Herman Ultrasonics. We are a German machine builder, like a small company, 500 people only, not one of the big tech companies. And we have decided, arbitrary for a weird Swedish tech stack, including Erlang, to do our automation, to do our machine controls. And as a product owner, I had to make decisions whether how we would tackle security in the longer run. And that brought me here.
CRob (02:09)
Excellent. And our friend, Mr. Windsor.
Michael Winser (02:12)
Hi everyone. So I’m here for the free cookies. I was promised cookies. I think, you know, working in Alpha Omega, one of the surprising and the continuous benefits is that we end up finding community. find people and people find us and then that creates these connections. And so when Jonathan showed up in one of the public meetings and started chatting, I’m like, who are you? What are you doing? And we started talking more and that sort of led to more conversations and we’re still talking about things. that has spread to other parts of the airline community as well. And so the learnings continue. And for me, that’s just, it’s amazing what happens when you put people in a room and start talking together. So now here’s another room, let’s talk.
CRob (02:56)
Excellent. let’s start off. Jonathan, you’re here representing Erlang. Could you maybe talk to us about how you got into open source and maybe talk a little bit about what Erlang is all about?
Jonatan Männchen (02:56)
Mm-hmm. I think I started out quite the normal route, let’s say, just doing some side stuff from my corporate job, essentially. And as these things normally go, you kind of feel responsible for them and they grow and you get more and more of these kind of side projects going on. Some of them getting successful, others you decide to cut the loss at some point. And…
Yeah, I really started in the PHP ecosystem a long time ago, doing some pull requests on Symfony. And I published a library that does a SIP streaming from the server to the browser and that kind of thing. And around 10 years ago, I actually read a book on Elixir specifically and Phoenix, which a roommate at the time bought and I don’t think he ever read it himself, but I did. And yeah, I had to try it out. We had like the perfect project of like a, it was essentially like a bit, an online game essentially with money involved where we would play the game via web sockets and we had to have the state on the server to make sure people don’t cheat.
CRob (04:30)
Mm-hmm.
Jonatan Männchen (04:31)
And that was kind of like the perfect use case because that’s basically the first thing you read always about Erlang can handle that many millions of sockets at the same time. And yeah, kind of figured out at that point that basically I don’t have to wait for the unicorn project where this is the perfect solution, but rather in the end, it’s a technology
that is complete, you can build things with it. I don’t have to stick with PHP for the normal stuff. And yeah, over the time I got more more involved into Elixir itself, also with other open source projects. And I think around three years ago, I’m not quite sure, could be two, could be four. I got involved in the Erlang Ecosystem Foundation and the Security Working Group as well.
Working together with a lot of people trying to make Erlang secure. And maybe as a side note here, Erlang, Elixir, Gleam, and also a few other languages are all languages based on Erlang. So kind of like what’s Scala to Java, for example. And towards the end of last year,
I was talking a lot to Alistair, which is one of the board members of the foundation. And he raised for a long time that the CRA is a topic that we need to be very careful about. And the stars lined up, my last job was ending and in the end, yeah, everything lined up perfectly. And since the start of the year, I’m at the CISO trying to implement all of that.
CRob (06:16)
Awesome. So let’s talk about this new stage that you’re in. You mentioned that you and Michael and I met together at an Alpha and Omega community meeting. Can you, you and Michael maybe talk a little bit about how you two got introduced and how you discovered this amazing community that AO is nurturing.
Jonatan Männchen (06:40)
Yes. I mean, wait, where do I start? So yes, we haven’t really talked at FOSDEM, but I got to know you just from speaking at FOSDEM. But yeah, let’s start there. So I was at…
Michael Winser (06:40)
I think it starts with you, Jonathan. I don’t know how you came to the meeting.
Was it it FOSDEM? I gave a talk at. OK, yeah.
Michael Winser (07:04)
Yeah, so I’ll go. At FOSDEM, I had a couple of talks, one of which was in a room that was partly organized by the folks from the STA and talking about funding and open source. And as you might imagine, it was a crowded room. A lot of people, a lot of questions, lot, and you know,
Mirko and I Mirko’s from the STA Tried to put together a presentation even to sort of explain what we are and how we do things or whatever And in 15 20 minutes, we obviously compressed a lot of thoughts and time into that But it worked as intended right that we got lots of good questions and people who didn’t even know What we did or why or whatever sort of started coming out of the woodwork and and it’s been really great and John is over to you:
Jonatan Männchen (07:52)
Yeah, it was actually the day before. It was the FOSDEM Fringe event. I was not present at your talk. I knew that it happened. But it was the SBOM Fringe event where you were also speaking. I also didn’t… I mean, I read through a lot of the OpenSSF stuff on a high level of what the OpenSSF is doing. And I saw Alpha and Omega, but I didn’t really go into details there. just knew that it existed. yeah, you talking actually brought it up in my mind. And we, as the foundation, we are in this spot where we now have some financing, which basically just extends to myself. But really to implement all of this, we need more help than we currently have. And so I thought it would be good to reach out. And that’s also why I joined the call.
CRob (08:22)
Mm-hmm.
Michael Winser (08:49)
I remember now, and that of course was completely unplanned. I was at that event as just a participant, and then Philippe asked me to come up and just say a few words, and I babbled some stuff, and here we are. So it’s always the sort serendipity things that really drive interesting outcomes.
CRob (08:49)
Excellent.
Ulf (09:05)
Okay.
CRob (09:07)
This is a really interesting topic and let me pull Ulf in for a moment. As a product manager, kind of selecting components that are going to go into a product that your organization sells. How important is it to know that these upstream projects you’re relying on have support and do take security seriously?
Ulf (09:33)
Well, I’m here as an antidote to a poison, is vendor lock-in. So the bigger part of my life, I’ve been part of industrial automation and we were running factories for automotive supplies or plastics or whatsoever. And as part of this company, we were building machines and we were using open source, but we were using it in a, I wouldn’t call it un-moral, but in a weird way that we were just using it, you know, and didn’t, we didn’t take care about what you say, whether it is maintained or safe, it’s just there and you download it and you make a dependency and that’s it. And the antidote is number one, that at one day we stumbled over Alistair as well on a, on a … That was actually… What was that? It was in Berlin. Yeah, Elixir event in Berlin. And we realized that there’s a huge foundation behind it. And that was the cornerstone. And later when the CRA requirements came down to us and we started to wrap our minds how we would fulfill these requirements and make safe software for our customers, then only we realized how important these foundations may become to us. And we were lucky in a way that previously for other reasons, for reasons of resilience and reasons of resource management and reasons of development speed and whatever, know, we have chosen for Erlang slash Alexia stack. And so we were kind of enthusiastic about it, but we never choose it in the first place for security reasons. Then later, we realized that we are in front of a huge challenge of complying with these requirements, which are from you, but basically the United States are doing very similar stuff under different naming and many of them requirements, they overlap. And then we realized, lucky we are that we have chosen a pond rather than an ocean. And that pond is so concise and kind of personal and kind of streamlined, I would say. That gave us the confidence that if we use it to address these challenges, we would possibly have a very concise community to which we can reach out and meet real people, talking real talks and tackling real problems.
CRob (12:22)
Hmm.
Ulf (12:26)
So that is kind of how we ended up here. And this is also what made us finally, which convinced also my owner, we have a company owner and my CEO and also my development officer that we would fund such a foundation to a degree which is maybe not much in comparison to what probably Intel or Meta is doing, but you have to put it into relation to what our annual turnover is. And in that measure, it is a considerable amount of money and we are willing to continue to do so.
CRob (13:09)
Nice.
Michael Winser (13:10)
I just want jump in. I think you would be surprised comparing yourself to what other corporations are doing. And I just, want to start by celebrating the several things here. One is sort of the pragmatic taking control of your destiny approach, right? And it’s always, you know, it’s open source. There’s a lot of stuff that happens and it’s like free as in beer. It’s like someone shows up and gives you beer. But as I like to say, it’s really more like free as in puppies and they need care and they need love. And Organizations that understand that and make that investment Find out all kinds of interesting things such as you now actually have a lot more like you can train your puppies to go in the right direction and not not You know pee in the kitchen, for example Metaphorically, we’re going to stop with that particular direction But I think it’s also an example of how in a competitive landscape regulation even sometimes ham-fisted regulation, I would certainly not attribute anything to one regulation or the other, but regulation is hard. But any kind of regulation essentially creates better incentives and it rises. Like everybody has to pay a little bit more attention to these things because, you know, in a competitive landscape, every dollar you spend on feeding your supply chain and taking care of your puppies is a dollar you’re not spending on marketing or development or whatever. But, you know,
It’s your code, even though you’re not the ones writing it, it’s in your business, it’s in your product. And so the care of that investing in that has a return. So first of all, kudos to you and your organization. I think it’s amazing. and it’s a pattern I would love to see sustained and repeated as more organizations can find ways to do so. And I think you’ve also shown it’s not that hard. You just show up and say, we’d like to make sure that this gets done properly and things happen.
Ulf (15:04)
Yeah, and I would like to add that it becomes even a rational choice. There’s not, I mean, when we talk about puppies, there’s a lot of love and care and all of that, right? But you can also see the case I have been describing as a very rational choice, because especially if you look into the alternatives.
One alternative would have been we would have developed security by our own. Yeah. Okay. And, and obviously that, that is a monstrous task and we would have needed competences, which clearly we do not have. And it would have taken a lot of time probably and would have been expensive. So that has been ruled out in the first place. And the second option would have been that we would have outsourced it to some contractor.
Ulf (13:19)
I mean, there are specialist companies out there. You can tell them what to do. They have the competencies and they will do it in a proper timing and for a proper cost. But still there is a downside to that, which is trust. Because if we go to our customers and tell them about security and we tell them, the security we are selling to you is actually the one we bought from this other guy. And, and he’s a specialist, I tell you.
Then our customer would say, who’s that? And what is he doing exactly? And how do you know? And all of that good questions from a customer point of view, that’s a proper question. And then no matter whether he was doing wrong or right, to build trust is very difficult. In turn, if we kind of outsource that, it’s not a real outsourcing because we don’t have a mandate here, right? We are just funding it.
Ulf (14:09)
But if this is done by somebody else which we do not influence directly, there’s two benefits. There’s never a smell of influencing in turn. So we can tell them what they’re doing is trustworthy because we are not influencing them. There’s no conflict of interests. And also if they are doing it and we are not mandating them directly, they would look for a bigger community, which was foster a more resilient solution landscape. I’m very convinced that this would happen. And both of them mechanisms, I can go back to my customer and tell them, look, and because of these two mechanisms, you can trust them guys a lot more than you can trust either us or a contract that we have bought. So if you look at down that road, it’s probably a very rational choice to kind of outsource things to people you’re not influencing. It sounds contradictious in the first place, but it’s not that much contradictions if you think it to the end.
CRob (15:10)
And the behavior you’re describing – how a manufacturer gets value out of these upstream projects and you have taken the very conscious decision that we’re going to try to support them. That is exactly the behavior that the CRA has explicitly written in is they’ve asked manufacturers like if you’re using upstream components, you should give back and participate. And I really applaud you all for making that choice very early on.
Ulf (18:33)
Yeah and also look into CRA. You have three choices. You’re a consumer, a manufacturer or a steward.
Michael Winser (18:40)
Yeah.
Ulf (18:41)
I don’t want to be a manufacturer in key matters. I would love to be a steward, but I can’t. It’s not in our competencies. So to say, I love to be a steward, I can’t, so I’m going to fund one.
CRob (18:58)
Let me turn the next question to Mr. Windsor. Why is it so hard for a lot of projects to implement good security practices and how does funding help that?
Michael Winser (19:12)
I love this question. So somewhat Ulf talked about starts with competency. know, not everybody is a, you know, well, let’s start with the problem of software supply chain security, right? As I love to say, it’s like the Y2K problem without the same clarity of problem solution or timeline. Right. Everyone is still learning a lot about this and we have decades of technical debt. So expecting, you know,
Mary and Joe, software developers working on a cool open source project to have competency in all the risks that they are essentially carrying forward is unreasonable. It’s just not practical. And any solutions we do are not going to be magically by teaching everybody to become security engineers at the same time, any more than everybody knows how to do front end, back end, or use airline as a language or rust or whatever. There are competencies that take real time and energy to acquire.
And that’s a big deal. The other aspect is it actually goes back to the same competitive pressures that corporations are feeling at the of deepest end of the supply chain or the furthest out to the right end of the supply chain. Open source projects are, you know, like have different reward mechanism. At the end of the day, being used, being valuable is something people care about.
And a lot of the signal that they receive from their downstream dependencies, right, is somewhat abstract, but it’s about usage. How many people are using me? How many, you know, GitHub stars, which please do not use GitHub stars as an indicator of popularity. but, know, and so they’ll do things that people are asking them to do. And invariably, what do people want to do? Like I’m building some software and somebody has built a module that does something for me.
CRob (20:46)
Stars and likes.
Michael Winser (21:00)
If I can shift the work onto them, so could you add a feature that does X, right? Says every enterprise customer ever, and says every open source project. Software developers want somebody else to do the things that they’re not good at, right? So I’m using some HTTP client library. It does some really cool. There’s now an edge case on dealing with streaming over HTTP 3, blah, blah, blah, blah. Could someone do that for me, rather than me having to add that to my application code, which is trying to plug tab A into slot B and make an NCP talk to Zapier, for example.
Michael Winser (21:30)
And so that’s a big part, right? There’s a lot of pressure and signal towards adding new features. There’s a competency they already have, which creates a fluency and ease of work around the feature set they’ve developed. So you have this hard hill to climb of security of things I don’t really know about, an easy and rewarding hill to climb, which is things I do know about and people are asking for, right? Those choices are too easy, right? It’s too easy to go down the path of doing more of that.
And unfortunately, that problem is bigger than that because the people who are downstream who would benefit from the security and might benefit from the feature sets, they don’t know more about the security. They don’t know more about the code. So who is going to do that work? How’s it going to happen? And, you know, this is where I think what’s awesome about what Ulf and company have done, right, is saying, look, we need to bring some experts here. And what I love about it too is the point of leverage, right?
So you could go and look at all the supply chain things and fix all the individual pieces, or you can make it someone’s job in an entire ecosystem to reason and think about that ecosystem and to make changes that are going to benefit all of them. And that’s the alpha of Alpha Omega is all about that scale.
Ulf (22:45)
And we would not have done it if we would not have faith in the fact that it can be done in that ecosystem. And we have faith it can be done in that specific ecosystem. Yeah. Because it’s so streamlined and so concise and so complete in it’s so feature complete that it helps us a lot. Yeah.
Michael Winser (23:06)
I think that’s really key. And I think that the other thing that comes out of this, I think we’re starting to see these in other ecosystems and I fully expect them to become like significant factors in the airline ecosystem as well, which is you’re normalizing security. So when you think about software engineers and the set of skills that they all think are common, right? There’s a certain subset of things.
CRob (23:23)
Mm-mm.
Ulf (23:23)
Yes.
Michael Winser (23:31)
what we’re starting to do is to normalize a broader set of things around security concerns. So not everybody’s going to become a security expert, but if everybody’s aware of security and like, I should do this. it, mean, some of these things aren’t even about implementing more secure code, right you could probably talk for days on how maybe you should handle reports around vulnerability and just having process around vulnerabilities in your projects. And when somebody does tell you, whoopsie, you actually even have a process to handle that.
CRob (23:54)
Exactly.
Michael Winser (24:01)
That is a significant gap for an awful lot of open source projects.
CRob (24:04)
Mm-hmm.
Jonatan Männchen (24:05)
Which is, the way, also a gap we’re very specifically addressing. We’re in the process of becoming a CNA [CVE Numbering Authority]. We’re currently in the onboarding workflow, not done yet. But we’re actually becoming a CNA for every package that is in the package manager, if they’re not covered somewhere else. Just because we think that we have more tools available to do the correct decisions in the whole thing and also reach the
Michael Winser (24:13)
Yes.
CRob (24:26)
Nice.
Jonatan Männchen (24:34)
Correct people than MITRE ever could just because they’re not part of that ecosystem specifically. yeah, so we really want to cover this as a CNA and also build in all the vulnerability reporting into the default tooling so everybody gets the benefits of that.
CRob (24:41)
Exactly.
That’s awesome.
Michael Winser (24:54)
This is, this is, mean, this is a pattern we’re seeing more and more, right? And, know, there’s now documentation well written by other parts of the Alpha Omega family on how to be a CNA. This is what we did, how it worked out or whatever. It’s worth stating to the perhaps, you know, less CNA obsessed listener, right? That one of the things that happens here is that the community can have a more curated control over what is being reported as a vulnerability and the process gets centralized. And this is not to impugn our
CRob (25:20)
Mm-hmm.
Michael Winser (25:24)
Esteemed colleagues in the security research industry, right? But they have incentives to find vulnerabilities and want to push them out and like that and when you push them either straight up to MITRE or directly to the individual project there is none of that curation happening and this allows an Esteemed set of experienced people in the airline community to make sensible decisions about is this really a vulnerability? What severity it has and so forth and there’s still a dialogue and should be a dialogue with the researcher, but it’s not
Sort of like the problem is that there’s no dialogue with MITRE or it just happens. There you go. And then it’s very hard to undo that later on. And it drags around creating, you know, imperfect signal for people consuming things.
CRob (26:03)
Right. So, I see you as representing kind of a really exciting new trend that we’ve witnessed over the last few years, where communities are reaching out and bringing in subject matter experts to become this developer, security developer in residence, kind of having this role. From your perspective, and your role as CISO for Erlang, what do you see your role is in helping your community?
Jonatan Männchen (26:34)
I think the biggest part is to figure out what should we actually be doing. Because there’s lots of regulation from lots of different countries. Nothing is harmonized. And then even, for example, the open SSF, there is so many things in there just sifting through what does actually apply to us. And there’s other organizations than the open SSF as well. So just figuring out what should we be doing, I think is the biggest part.
CRob (26:39)
Mm-hmm.
Right.
Jonatan Männchen (27:04)
And yeah, I’ve started putting together essentially a roadmap of things that we want to implement. Also, there’s some stuff that I can directly tackle myself just because they’re in a size that makes sense for me to invest that in my time. For example, we just did the open chain certification for Elixir or the CV numbering authority, which is talked about.
CRob (27:22)
Very nice.
Jonatan Männchen (27:34)
And we also just implemented the best practices batch for Elixir as well. So there’s lots of different things going on and there’s lots of them, yeah, where I can just look at them, do them, get it done. But there’s also bigger ones like for example, implementing SLSA throughout the whole package manager, where we’re more at the point where we need additional help just because it doesn’t make sense for me to focus on that for that long time right now. And so.
CRob (27:53)
Mm-hmm.
Jonatan Männchen (28:04)
I’m trying to figure out a way of organizing all of that and getting the funding and figuring out what is exactly we’re trying to do. And yet just put together a plan that actually could work essentially.
CRob (28:18)
Michael?
Michael Winser (28:20)
I’m glad you mentioned SLSA and You and I should chat offline for some specifics but I’ve been working within the SLSA working group for a while and one of the members out Tom Hennan has created there’s one of the tracks we’re working on this the build track there’s a less developed thing called the build environment track which manages the sort of Security of the environment which run the Maturing nicely is something called the source track around dealing with the provenance of the source code and the environment in which the source was created, right? And so being able to say you have branch protection on and things like that, and there’s a set of requirements. Well, Tom has produced a very simple little workflow. There’s still in sort of prototype phase that makes getting to SLSA level three of source level three provenance, where you have this continuous from a date, point in time forward chain of trust for all the commits to your repo incredibly easy to achieve.
And so would love to work with you and the Erlang and the Elixir space and the package manager space to do that and then Connected back to trusted publishing depending upon the workflow from there to publishing into the package manager You can start to see an end-to-end provenance story. That is very interesting and You know last week I had a chat with some of your colleagues from Erickson who work on the OTP stuff and I was asking them about what what’s their interest to the package manager versus the other parts of the ecosystem and
They build from source, use the force, build the source. And so that eliminates a lot of tampering threats in the build space, but they still care about the provenance and authenticity of the source. And by the way, they also say they very much care about the health of the ecosystem as well. And so they’re to help out in various ways. So there are dots to connect there that I hope are, and this is part of what we’re funding at Alpha Omega, that reduce the toil for someone like you and your ecosystem to kind of take those next steps.
CRob (30:16)
And I bet as a product manager, Ulf, this would be a really compelling story if you knew that the components that you were putting integrating into your products had this pedigree and provenance that had that chain of custody and they were untampered with.
Jonatan Männchen (30:16)
Mm-hmm.
Ulf (30:31)
Absolutely, and that even if I knew that would be the case then still there’s tons of work to do for security so I’m offloading a part of the problems we are facing and still Previously we mentioned that or I mentioned that probably we do not have the competencies in security and Probably under rating our company. Of course, we have experts in that matter but not to that extent what Jonatan can do for us number one or the community can do for us, number two, or foundation can do for us, or CNA can do for us. And the processes you’re mentioning about making the correct ratings and making the correct proceedings in how to handle these vulnerabilities, all of that we can definitely not do. And still there’s tons of work to do to provide safe software or secure software to our customers from operating systems and good habits and proceedings in the pipelines and management of quality. All of that’s still down to us. And even there, we benefit from Jonatan providing best practices. Simply as that. It’s undisputed, right? Somebody calls out a best practice, it goes into our development rules, and here we go. So it’s simple. You don’t need to spend or wrap your brain around how to do that the best way. It’s a matter of trust.
At the end of the day, for us, it’s a matter of trust.
CRob (32:00)
Awesome. So as we wind down, I would like to talk about, you know, what is all your individual calls to action? You know, what if there are other communities, whether it’s a project or another language ecosystem, and they hear about this amazing story that the three of you are weaving together, you know, what advice would you give these communities and how they can enter in and become these, good stewards and good participants in these types of situations.
Jonatan Männchen (32:36)
Yeah, thinking a second what to say.
Michael Winser (32:39)
Why don’t I start? Because I’ve got the easiest thing to offer right up front. Whether you are an expert in coding, an expert in the problem space, an expert in the language or the package that you’re using in your business, the first and simplest thing to do is to engage, to contact the organizations upstream of yours and say, hello, my name is Michael, and I am benefiting from your work. I would like to make hello and say, how’s it going? Introduce myself so that when you have a problem later on, whether it is an audit finding out that your CRA compliance is at risk because of some practice or whether it’s a silly little bug or whether it’s a vulnerability has surfaced and you’re not sure whose fault it is or what to do or how to do something or what the importance of it is. If you already have a working relationship, even if it’s just purely social, if it’s just literally love in the human sense of like love is a verb, hello, how are you today?
I care about your work, right? You’re already so much better off than you would be otherwise. And so the first thing to do is to engage and to listen, and then you will have a very clear path of opportunities forward, or at least the connection when you need them.
Jonatan Männchen (33:53)
What I could add, a lot of people in an ecosystem don’t really look outside of that ecosystem. So it’s really important that you’re not trying to do everything by yourself. There’s lots of smart people from lots of different places that already thought about these things, but they haven’t thought about it in your specific programming language probably. But yeah, looking around what others are doing and actually connecting beyond the borders of your own ecosystem is probably one of the most important things to do.
Ulf (34:39)
And from a user perspective, of the other end of the food chain, whatever, I wish that more people would be honest about their usage of open source and their contribution and, know, distinguish clearly what is their added value with what they have developed and they willing to sell to their customers and what they have just, you know, grabbed as a base for what they want to offer as a customer value. And if that would be a more honest and a more transparent way of doing business, then automatically more people would join an initiative like we have been doing and that base would become a lot more resilient and even a lot.
And it will be worth the living, you know, for the people who are doing it. mean, currently, most of or many of them projects are maintained by enthusiasts and not for living. And sounds sounds wrong, kind of wrong. Yeah, I would like I can’t see why we should not distinguish between our added value and somebody else’s added value and make that very transparent. Transparency.
CRob (35:37)
Excellent. Well, gentlemen, I really appreciate your actions, both in your businesses and upstream and in your communities. And I thought this was a really insightful conversation. And I know we’ll be having more like this as items like the Cyber Resilience Act in Europe or legislation around the globe continues. This is going to be a matter of great importance that downstream has generated an unimaginable amount of value from the work of upstream. And there needs to be a way to be more participatory and to give back and to show that love that Mr. Windsor noted back to those developers that have given you so much. So gentlemen, thank you. I appreciate your time. And with that, happy open sourcing. That’s a wrap for us.
As machine learning (ML) evolves at lightning speed, so do the threats. The rise of large models like LLMs has accelerated innovation—but also introduced serious vulnerabilities. Data poisoning, model tampering, and unverifiable origins are not theoretical—they’re real risks that impact the entire ML supply chain.
Model hubs, platforms for data scientists to share models and datasets, recognized the challenge: How could they ensure the models hosted on their platform were authentic and safe?
That’s where Google’s Open Source Security Team (GOSST), sigstore, and the Open Source Security Foundation (OpenSSF) stepped in. Together, we created the OpenSSF Model Signing (OMS) specification, an industry standard for signing AI models. We then integrated OMS into major model hubs such as NVIDIA’s NGC and Google’s Kaggle.
We partnered with Kaggle to experiment with how to make the model signing easier without disrupting publishing UX.
“The simplest solution to securing models is: sign the model when you train it and verify it every time you use it.”
— Mihai Maruseac, Staff Software Engineer, Google
Key features of the prototyped implementation:
The process dramatically improves trust and provenance while remaining invisible to most users.
With sigstore integrated, the experiment with Kaggle proved that model hubs can offer a verified ML ecosystem. Users know that what they download hasn’t been tampered with or misattributed. Each model is cryptographically signed and tied to the author’s identity—no more guessing whether a model came from “Meta” or a spoofed account.
“If we reach a state where all claims about ML systems and metadata are tamperproof, tied to identity, and verifiable by the tools ML developers already use—we can inspect the ML supply chain immediately in case of incidents.”
— Mihai Maruseac, Staff Software Engineer, Google
This solution serves as a model for the broader ecosystem. Platforms hosting datasets and models can adopt similar practices using open tools like sigstore, backed by community-driven standards through OpenSSF.
Join the OpenSSF Community
Be part of the movement to secure open source software, including AI/ML systems. → Join the AI/ML Security WG
Explore sigstore
See how sigstore enables secure, transparent signing for software and models. → Visit sigstore
Learn About Google’s Open Source Security Efforts
Discover how Google is advancing supply chain security in open source and machine learning. → Google Open Source Security Team
Learn More about Kaggle
Explore how Kaggle is evolving into a secure hub for trustworthy ML models. → Visit Kaggle
Watch the Talk
Title: Taming the Wild West of ML: Practical Model Signing With sigstore on Kaggle
Speaker: Mihai Maruseac, Google
Event: OpenSSF Community Day North America – June 26, 2025
Watch the talk → YouTube