🤖 Download the Free eBook: Securing Open Source in the Age of AI

What’s in the SOSS? Podcast #65 – S3E17 Signing the Future: Securing AI and ML Artifacts with Mihai Maruseac

By July 14, 2026Podcast

Summary

In this episode of What’s in the SOSS?, host Yesenia Yser sits down with Mihai Maruseac, the lead of the OpenSSF AI/ML Working Group and Security and Privacy expert at OpenAI, to dive deep into the unique security challenges facing artificial intelligence. Unlike traditional software packages, AI models cannot simply be inspected for malware by looking at their weights – malicious code only exposes itself upon execution. Mihai outlines how the community is answering this threat through the evolution of the OpenSSF Model Signing (OMS) specification. Discover how OMS creates an unshakeable chain of custody for models, data sets, and agent workflows, the structural shift toward implementation-agnostic toolchains, and what the future looks like for a fully realized, end-to-end secure AI supply chain.

Conversation Highlights

00:22 – Welcome: Yesenia introduces AI/ML Working Group lead Mihai Maruseac.
00:51 – From TensorFlow to OpenAI: Mihai’s journey navigating open source security and AI.
01:47 – Core Risks of Model Tampering: A look at hidden risks inside uninspectable model weights.
03:27 – Establishing Chain of Custody: How cryptographic signatures verify file integrity from training to deployment.
05:04 – Evolution of the OMS Spec: Why the community standardized on forward-compatible, framework-agnostic formats.
07:17 – Tracking Iteration (v1.1 & v1.2): An overview of newly introduced security keys and community features.
08:26 – Choosing Your PKI Tooling: Why the OMS specification remains highly flexible for users.
10:22 – Real-World Integration: Early success stories with Kaggle, NVIDIA, and the path to PyTorch.
12:42 – Looking Ahead to Version 2: Overcoming “attestation sprawl” by unifying multiple security claims.
15:29 – The Ideal AI Supply Chain: Using signed artifacts with GUAC to automatically map vulnerabilities.
17:09 – How to Get Involved: Immediate opportunities to contribute to signature format convergence.
18:11 – Rapid Fire Segment: Mihai shares his favorite retro games, hiking, and love for Vim.
19:37 – Final Words of Advice: Why contributors of all skill levels are welcome to join.

Transcript

Intro Music & Promo Clip (00:00)
“We have the same problem that exists with traditional software. The difference with AI is that you cannot inspect the models, looking at the weights, you cannot determine if the model is malicious or not. You will discover that only when you execute the model. We have to make sure that we can create a chain of custody between model being released, me being trained and the model being used.”

Yesenia (00:22)
Hello and welcome to What’s in the SOSS? An OpenSSF podcast where we talk to interesting people throughout the open source ecosystem, sharing their journey, experiences, and wisdom. Soy Yesenia, one of your hosts, and today I have the utmost pleasure of having Mihai here who is a fabulous contributor to the open source space among one of the many groups that I’m not going to spoil them, but you gotta listen to share that which one.

Welcome, Mihai. I’d love for you to introduce yourself to the audience.

Mihai Maruseac (00:51)
Hello, Hello, thank you for having me. So I am Mihai Maruseac and I’ve been working a lot on open source. I am now leading the AI/ML Working Group under OpenSSF. I worked on TensorFlow Security, then Supply Chain Security under Google Open Source Security Team. And now I’m going to work on security and privacy at OpenAI, so everywhere AI and security.

Yesenia (01:14)
You’re all over with the AI. Love it. Such a good asset to OpenAI. So let’s, let’s set the stage. You mentioned something very important that is needed in the industry, model signing. Let’s kind of talk about why it matters. So for listeners who may be new or spent ML, supply chain space. Can you walk us through the core problem that model signing solves? Like what are the real world risks if a model is tampered with between training and deployment?

Especially with so many teams that are pulling from open hubs like Hugging Face and Kaggel.

Mihai Maruseac (01:47)
Yeah, so you already mentioned that people are downloading models from model repositories or model hubs. And we have the same problem that exists with traditional software where people download packages from package registries like PyPI and so on. And those packages might contain malware. The difference with AI is that you cannot inspect the model. So, looking at the weights, cannot determine if the model is malicious or not. You will discover that only when you execute the model.

And because the models are huge, nobody is going to inspect the models anyway. Nobody is going to bother with checking. So it is very likely that if there is an insider compromise, either on the training side or on the hub side, on the model hub side, or somebody just downloads a model and uploads it again in their name, users might download the malicious model. There are examples of all of these scenarios.

For example, there are multiple producers for Llama models on Hugging Face. One of them is the real meta producer and the other ones are security researchers trying to prove to you that this model, if you look just at the name, that’s not enough. The model is malicious. And similarly, there are examples of interns sabotaging the training job of other interns, compromising a checkpoint and then the training job would restart from a compromised checkpoint and then the model would have bad accuracy downstream and so on.

Yesenia (03:15)
Oh, so it’s like a new level of competition within the tech space is like, we’re going to compromise your model, not for malicious intent. Well, for malicious intent, but like more for that competition of like, my model is better than yours.

Mihai Maruseac (03:27)
Yeah, that’s exactly true. And because people cannot inspect the models, we have to make sure that we can create a chain of custody between the model being released by me being trained and the model being used. And this chain of custody, we can do it via model signing. Basically, we compute the integrity hash of the model during training or immediately after training. And then the users can verify that when they use the model.

And at the same time, we also offer the ability for the hub to verify the integrity of the model during upload and display a verified badge in there. And users that trust the hub and see the verified badge can just download the model and use it. If they don’t trust the hub, they still have the option to actually run the verification themselves. So we tried to make both signing and verification as simple as possible such that any type of users can use them.

Yesenia (04:20)
Yeah, that’s awesome. I remember, you know, back in the day, back in my day when signing became like a bigger thing when the industry, like it was, it’s nice to see that AI has picked up a lot quicker on how do we check the integrity of these models. And with that, I know last year about a year ago, actually, the group had launched version one in April, 2025.

And essentially formalized the OpenSSF model signing, which we’ll call OMS just a couple of months later. What helped drive this evolution? What was missing from V1 that OMS spec addresses? And how does this being implementation-agnostic change who can adopt it?

Mihai Maruseac (05:04)
So for the model signing, in order to have the signature in a format that is easy to use and both inspectable by machines and by users, we are using In-toto predicates. And during the development of model signing, we are developing several test predicates in order to see what is best for different model sizes, different performance criteria, and so on.

And…for the release job for April, we actually standardized on just one of these formats. It turned out that some of the early adopters were already starting to use one of the test formats. So when we did the V1 release, we actually caused some compatibility issues.

So we are thinking of standardizing the formats to be both forwards and backwards compatible to not have this issue into the future when we do more releases. Because already at the time, we are thinking of extending further than just signing models. We are thinking of signing data sets, signing agent cards, model cards, and all of these other ML artifacts.

The other reason for the OMS specification is that all of the tooling that we now have is based on Python, but people that use Docker images and put the model in Docker images, they might prefer to use systems and tool chains based on Go. And people that are interested in high-performance training or models, they might use C++. They might prefer to actually target C++ or Rust. Having the specification separated allows people to actually target the same specification, the same conformance testing from different languages, from different libraries.

Yesenia (06:47)
I like how much thought has been put into that. You know, it’s V1 starts with, I understand it’s just model artifacts, but there’s so many different types of AI artifacts that need to be considered. And then as you are having those conversations with other groups, you’ve realized the extent of the languages that are being used and the different types of use cases. So I don’t want to ruin the future, but I feel like this is maybe part of V1.1 or something along that line.

Mihai Maruseac (07:17)
Yeah, so we launched 1.1 around October of last year. We already added support for more signing options. Like now you can sign with PKCS 11, like when your USB key security keys. We also optimized the several bugs and also changed some of the parameters in the CLI. So that’s why we did the 1.1 release late last year.

So we are going to launch 1.2 soon because we already got nice features contributed by people from the open source community and different participants in the OpenSSF.

Yesenia (07:57)
That’s awesome. And I know you mentioned about OMS is supporting this wide range of key infrastructure. So I’m assuming Sigstore, you know, keyless signing, your self-signing certs, your bare keys, your enterprise PKI. How did you arrive at the PKI, at this PKI design and like teams that are already using sigstore for their supply chain? Like how natural or simple is it for them to adopt and transition to use it for their models?

Mihai Maruseac (08:26)
So, sigstore is the recommended approach that we are suggesting people to adopt because it is keyless signing. Signers no longer need to maintain their keys and care about what happens if the key gets leaked to revocations and so on. However, the sigstore adoption in the industry is still not everywhere. It’s still not 100%. So we also need to cover cases where model trainers and model users don’t yet have sigstore in their systems or they might already have a solution for traditional signing and they want to add ML on that, but they don’t want to at the same time also migrate to sigstore. So in order to enable this stopgap solution, we also decided to support traditional approaches.

Yesenia (09:17)
Yeah, that’s awesome because user adoption is huge, right? Especially with the open source, like you have the awareness of sigstore as a key management system for both your software supply chain and your AI. And bringing it into OMS, I think is like a very valid way to start having that user adoption because it is supported. But you’re also thinking about the other developers, right? The ones that still haven’t migrated. Like, all right, if you haven’t migrated, even those are recommended. As you know, we love sigstore here. I love that you have that option for folks.

I really like how this has been designed, the conversations we’ve had about it. And I know looking at the documentations, the group provides both a CLI and a Python library as reference of implementations. So for adoption…what does that actually look like for our MLOps teams today? What is that minimal viable integration and where do you typically see that most friction from our open source developers or just developers in general? Have you had any early adopters that have shared feedback that have changed your thoughts about the tooling?

Mihai Maruseac (10:22)
Yeah, so we already have some model hubs that adopted the model signing solutions even as we’re doing the first release. So for example, right now any model on the NVIDIA model hub released since April is already signed. We have been working with Kaggle to add the model signatures. And with Kaggle, as soon as you do the upload on Kaggle, the Kaggle library is actually calling into the model signing library and generating the signature.

And at the same time on the verification side on Kaggle infrastructure, they are calling the model signing library and doing the verification. But from the user point of view, we still offer both the CLI and the library support because some user might just download the model and then test them immediately after download and put the model into some immutable storage. And then they trust that storage and they don’t need to perform any more verification.

Or we might go into a future where actually the ML frameworks like PyTorch, Jaxx and so on, they will verify the model before loading. And if the model signature fails, they will stop the process at that point. So even users that don’t run the verification themselves as they download the model from the hub, they will still get this additional layer of protection from the framework. And this is why we want to have the library such that it is easy to integrate in all of the frameworks.

And the CLI to make it easy for users to run one-off command or to run batch jobs across all of the models that they already have built. In general, the CLI is designed around the library, it’s just a thin wrapper around it, so every option, every flag for the CLI, it’s actually a parameter in the library.

Yesenia (12:12)
Oh very nice, It seems like a lot of thought with the team has been put into this for not just our hubs, but our everyday open source developers and just general developers.

So we’ve talked about the past, the present. I’d love to know what’s next. You did say there’s a V2. Is there any surprise Easter eggs that we should know about when it comes to what’s being released for V2 of OMS?

Mihai Maruseac (12:42)
So we already have under OpenSSF, we have another SIG that is starting to look at end-to-end provenance and something that will be discussed in another podcast episode maybe. And as part of the working group in there for the end-to-end provenance and also with collaboration with Coalition for Secure AI on the Supply Chain Integrity, we realized that we kind of need to change the model signature to take into account all of the other attestations that can be said about a model.

Like if we evaluate a model on a data set and this was the performance score on that data set, you might want to get an attestation for that. Or you might want to get an attestation that model B is produced from quantization of a model A. And right now with the current model signature format, you can only have one single predicate in one file. So you could imagine on a long chain of model transformations to build a model that gets released to the public. You will have a few files for the weights of the model and then tens of files with signatures and attestations. And this doesn’t really scale. So we are currently working on actually incorporating everything into one single file format that will contain all of these attestations together. And this will be a blocker for the next release. Once we have this implemented, then we can proceed to the V2 release.

And again, we have to make sure that the release is both backwards compatible, so it still supports the model signature format that we currently use, but also feature proof in case we add more attestations and other claims that we want to do. So this is one of the things that we want to do in the future. Another one is we actually want to extend the signatures to not just sign models, to sign data sets and to sign agent cards to sign all of the other, to sign like SKILLS.md, AGENTS.md, all of these files that are used in agentic workflows.

And fortunately, because model signing treats a model as just a collection of files from the directory, we can adopt the exact same library to all of these other things. We don’t need to change almost anything in the library. We just need to change the predicate to say that this is not a model. This is actually an AGENTS.md and then the library will still work.

Yesenia (15:03)
So it seems like you’ve taken a lot of time, you and the group have taken a lot of time to think about this and are working through that, that you have what sounds like a fairly good roadmap of work to do for the next couple of years or maybe months. If you were to think what would be a fully realized pure AI supply chain, what would that look like in your vision?

Mihai Maruseac (15:29)
Yeah, so for the future, an ideal future, maybe in a few years or maybe earlier, depends on how many contributors we get. We would want to have any artifact that gets produced as part of an ML training pipeline be signed and also attach a provenance to that so you will know that this artifact, like this model or this data set comes from this inputs, like this model has been trained on this data set or this data set is a version of a previous data set, but curated via this automated process and so on.

Once you have all of these provenance statements and all of these signatures for all of the artifacts, we can actually ingest everything into GUAC, another OpenSSF project. And then GUAC can be used to do incident response. Like you can imagine, for example, that this data becomes stale. And we want to determine which of the models that are in productions are trained on data that is too old.

So we could use GUAC, for example, we can mark the data set as this data set needs to go out of production and GUAC will tell us the blast radius. These are all of the models that will need to be retrained because they use very old data and so on. And similarly, we can use GUAC to generate the AI bill of materials (BOM), the AIBOM, in an automatic way, rather than actually scanning or looking through spreadsheets of how the training process has been around before.

Yesenia (16:53)
Very nice. So it sounds like there’s, there’s a lot to get into work and you you hit the, my favorite statement is like, there’s a lot of work with the contributors. What’s like one thing you’d want the open source community to contribute to right now to help that vision become a reality.

Mihai Maruseac (17:09)
So right now we are still discussing exactly what should be the format for one single signature to cover everything. Initially, we are proposing a JSONL document where every signature is one line in the document. But this has some issues that somebody could just delete a line or some lines are not, some predicates will not be understood by some of the tooling that people might use.

So we’re still needing to get some convergence in there. And then we will still need to get adoption in model hubs, in model frameworks, in model tool chains and so on for model signatures. There are also tools like Ollama and similar that allow you to write the script that uses the model. And the first time you run the script, the tool will actually go and download the model behind the scenes for you. So you’ll have the model in your desk. So, incorporating model signing into those tools is also useful. It’s also something that the community can contribute to.

Yesenia (18:11)
That’s awesome. There’s a lot of work for the community. You’ve heard it here on the podcast. Join the AI / ML working group to learn more. And thank you, Mihai, for your work.

Let’s shift over gears to the rapid fire part of the interview. This is probably one of my favorites. We have fun with these. So I’m just going to ask some random questions. First thing that pops into your head – sweet or sour?

Mihai Maruseac (18:39)
Sweets.

Yesenia (18:40)
Dungeons and Dragons or Magic the Gathering.

Mihai Maruseac (18:42)
Dungeons & Dragons.

Yesenia (18:44)
Vim or you Emac

Mihai Maruseac (18:45)
Vim everyday.

Yesenia (18:49)
GIF or GIF?

Mihai Maruseac (18:51)
GIF.

Yesenia (18:53)
Your favorite activity off of the computer.

Mihai Maruseac (18:56)
I go hiking almost every weekend.

Yesenia (18:59)
Nice. Get lost in nature. I love it. And last question. Retro. Your favorite retro video game.

Mihai Maruseac (19:06)
I still like to play Heroes 3, Heroes of Might and Magic 3, which is I think from 1999 or something like that. And I still get to play it from time to time. So it’s not very retro, but yeah.

Yesenia (19:20)
Yeah, you know, as a 90s child, that’s not retro, but we’ll take it from here. There you have it, folks. Another wild rapid fire interview. Mihai, thank you so much for your time.

I would like to know, do you have any last minute thoughts or advice for our audience?

Mihai Maruseac (19:37)
The field of AI is moving very, very fast, but the fundamentals are still the same. And people can get involved even if they think that they don’t know much or they don’t have how to contribute. Actually, we have a lot of items to do, and we welcome everyone to join. As long as you are interested, you are passionate about the work, you are welcome to join the AI/ML Working Group or any of the SIGs under it and contribute. We welcome all of you.

Yesenia (22:05)
I love it. So to our listeners join us for the AI/ML Working Group. can find out openssf.org/getinvolved. Check out the calendar. They have different groups that you can join. Join us on Slack and just ask questions of how you can get started to get involved. Mihai thank you so much for everything that you do in this open source community. Your voice, your contributions, your community and your impact that you’ve put to make these projects happen. So many thanks to you and the folks that you work with on getting us to that V2. believe in you. And with that, thank you everyone and we’ll catch you on the next episode.

Mihai Maruseac (20:46)
Thank you everyone.