Navigating Software Supply Chain Security Challenges with Christopher (CRob) Robinson | Open Source Summit NA 2025

Hey everybody. We're back at the Open Source Summit in Denver, and we're talking with Christopher Robinson, who's chief architect for open SSF, otherwise known as C Rob. And we're gonna be talking about, well, first of all, the current state of the software, supply chain security.

We've been at this for a little while, and there's a lot of new regulations to sort through. See Rob, welcome to show. Thank you very much.

Glad to be back. This is great. Um, we've been talking about this issue for a while now, and, but it's not clear to me if we're making progress or what's your sense of, are, are people actually doing a better job of securing open source software these days?

Or is it still in the realm of, you know, we want to, but we still don't have the will to make it happen? I'll give you a hesitant Yes, we're doing better. There have been some pretty substantial movements forward in helping secure things, uh, things like our SIG store project that allows, uh, any developer to, to have free code signing and have a publicly available transparency log.

So there's things like that, like our SALSA project that focuses in on the how, um, the CICD systems are configured and the artifacts that move through those. So we've seen a lot better, bigger adoption of those types of things. But we still have a lot of challenges where, uh, developers don't have the right training yet.

They don't understand, you know, the, uh, you touched on compliance and compliance has been, there's been a whole new set of legal regimes that have come up since we've last talked that complicate things. And most upstream maintainers, it's not a world they live in. Our members are, you know, large companies.

You know, things like, uh, hyperscalers or banks or retailers. They live in that compliance space, so they get it. But the people that create a lot of the software for the world have no idea.

Like just new regulations that come up. And they, and that's where they will complicate the supply chain as we're adding new requirements that the developers might not be aware of. And at least, like in the case of the eu CRA, the developers aren't necessarily required to follow the law.

It's the vendor that's selling the product is, And then there's a lot of nuance in that. And let's just throw in the Trump administration change the wording a little bit in an executive order on making, um, SBOs more of a suggestion for federal agencies rather than a requirement. Yes.

And I think a lot of people are confused about, you know, well, what should I do? What do I have to do? Mm-hmm.

And even in the CRA, there are people who are, you know, saying it's overly prescriptive, so there's just a lot of back and forth. So help us sort that. Yeah.

The, the s om the, the recent executive order was disappointing, uh, in some ways because they rolled, rolled back the, uh, NIST SSDF, the Secure Software Development Framework, attestation requirement, and they also kind of weakened the sbo, uh, asks. And that's something that when we just had an event in Japan, and, um, Medi is the regulatory body over there, and they're really big into SBOs. So the, you know, the Japanese and in different parts of the world, uh, everyone's kind of looking at, you know, SBOs been around for eight years or so, and we were just at the precipice of actually starting to get good SBOs and starting to refine them and understand like, somebody hands me an sbo MI can actually do something with it.

And when, uh, you know, with the US being, you know, the, the largest economy around, uh, when you kind of remove that restriction, if a manufacturer is selling products in the States, they're selling it in the eu, they're selling it in Japan, it makes it hard. You know, they have potentially different requirements in these different geo geographies, and that may, that adds additional burden for the manufacturer, as opposed to having, here's an sbo, here's eight things that need be in the sbo. Here are formats.

We wanna see the SBO M in, and if we had more of a unified front, we're gonna be able to drive the quality forward and get those changes so that consumers can actually get the protections from the supply chain we're trying to get put in there. Not every open source project is Linux with, you know, thousands of people in peer reviews. A lot of it is smaller teams of people, maybe even onesies, twosies.

Mm-hmm. Um, they didn't get signed up to be, you know, the maintenance team for enterprises. Mm-hmm.

So when they get a, when there's a zero day or a new vulnerability, they don't get outta bed in the morning and say, let me go rush to fix that. Right. Because they're like, I have a life and this is my hobby and not my vocation.

Mm-hmm. So how do we kind of bridge that divide a little bit and get those people the help they need or mm-hmm. Ideally even the skills to prevent the vulnerability in the first place, but even if it does exist, who's gonna help them fix that in a timely way?

Because everybody else is like banging on the door and they're like, sorry, nobody's home. Well, And, and that's honestly ours and other foundations biggest concern about like the EU Cyber Resilience Act. There's a lot of really strict, really harsh requirements that an enterprise probably is already doing or they should be doing.

Um, but it's the, it's all like the last 30 years of application security kind of codified into the law, but because the onus is on the manufacturers and not the developers, which is good, but we fear that all these manufacturers exactly as you said, are gonna start harassing the developers saying, Hey, you know, knocking on the door, getting them up out of bed at three in the morning saying, I need this fixed today. And the developer is like, I, that's not my problem. You know, I didn't sign up for this.

I'm not your employee. I'm writing software because I love to, I'm solving my own problems. I like the community, or whatever the reason is.

And it's not because large bank or you know, large hyperscalers on me about harassing me to get, get this fixed for a, a problem. And that's where, uh, we hope the CRA, there's a clause in there where the manufacturers are unfortunately encouraged to contribute back to the projects that they consume. I, I wish that wording had been a little stronger, more of a, a must instead of a should.

Uh, but ideally, and, and some of the bigger organ, some of our members especially, are really taking this to heart where they're analyzing what components they use, and they are reaching out to those projects and saying, you know, what can I, I use you, thank you for your work. What can I do to help support you? What is it code contributions?

Is it infrastructure? Is it helping out with testing? You know, what, whatever the, the project might need?

So ideally, the CRA helps influence the manufacturers to start contributing back and lessening that burden. And then on the flip side, we're also working with our friends in LF education where we just released a global cybersecurity, uh, skills matrix. So we have 14 job families, and we divide that up over kind of three levels of maturity, beginner and intermediate, and an expert.

And we list core cybersecurity skills these job types should have. So if you're a developer, if you're a project manager, if you're a DBA, if you're an AI data scientist, we like talk about these are the core skills you should have to be able to cyber correctly in your space. And then we're right now, uh, taking that, the matrix is done, it's published, uh, a couple weeks ago, and now we're in the process of trying to identify training so that if we say, uh, architect needs threat modeling or attack surface analysis skills, we're trying to identify whether it's an LF course or maybe it's something over its sands or oasp that, you know, they have a really good class and kind of routing people to those so that we can upskill people, uh, from large organizations or small.

Mm-hmm. And part of that, at least my understanding of it too, is that it just helps enterprises to find the roles they need. Exactly.

'cause a lot of times they don't even know, like there's a security team Yep. But they don't have any, you know, particular mission or job assigned to them. So do we just need a little more clarity on the expertise and skills we require?

And That's absolutely being a failing of my vocation. I'm a trained cybersecurity professional for, you know, three decades. Uh, and you know, we have done a really good job of training, making more crow clones, but we haven't done a really good job of teaching developers Here's how to do, how to avoid you doing input validation or not coding cross-site scripting errors or a DBA.

Here are things you need to think about, like, here's how to correctly configure your infrastructure and how to use access control. So Absolutely. And now we're finally to the point where we're trying to actually teach people how to do their jobs better within kind of their understanding.

And so it leads into the larger security program. One of the things I noticed here is that there seems to be a significant cottage industry of vendors who are emerging to kind of be the intermediaries between the maintainers and the consumers of those software packages. Mm-hmm.

And they're promising to harden them and deliver updates and vulnerabilities. Is that kind of part of the new ecosystem that companies should have? Or is that, um, a temporary aberration given, uh, the challenges at hand?

It, It's definitely not temporary, uh, because, uh, with the CRA especially, and Europe is the first place to enact this law, uh, we are aware that China and India and Australia and Britain are all considering similar legislation. And here in the states, um, we generally go through executive orders or procurement rules, but basically everyone's kind of putting these rules into place. So the requirement to have fixed software is not going away.

And the CCRA is kind of accelerating it because if, for example, if your product is found to have an exploited vulnerability, you have 24 hours to notify the European Commission that you're aware of this and get that notice out to your consumers. And then you've got really tight timelines to have a fix or a workaround. Um, that's about, I think it's, uh, maybe, uh, two, three days.

I don't remember the specifics. It's in Article 14. And then you have to have a final fix with, uh, under a month.

And that's, that's tough. And that's where these, the vendors you talk about kind of potentially can fill that. And, you know, I'm, I'm of two minds.

If a maintainer is not interested in doing security, and they're okay with a third party kind of acting on their behalf, and they get some kind of benefit from that, great. But if this company's kind of like potentially aggressively forking something and not contributing those fixes back to the main project, I, I think that kind of leads us to the, uh, state where we're gonna have so many forks you're not gonna know, uh, which is the right code branch. And you know, when the authoritative source the project is updating the code, how do we know that this kind of smaller, this subcontractor, are they getting all those fixes?

Are they in sync or are they still, are they missing features or vulner other vulnerabilities? Are We here? 'cause they're not participating in the project.

Yeah. To your point about overseas, at least you see countries are leading this at a national level. We have made some attempts to require federal agencies to behave in a certain way and then walk that back.

Will individual states then take up the mantle and have different regs and rules and uh, you know, we could have as many as 50 different requirements. I, yes. We've already seen that with like data privacy laws.

Mm-hmm. But the current administration is making moves to, uh, disallow states from doing some of that, especially like in the AI space. So I, I think California was also thinking about a new AI security, right.

Role a law. And I believe that on a federal level, they're trying to block states from doing that. So yes, that is a potential, but I think it's gonna get stopped, but I, I'm not involved with it, so I don't know specifics.

Can we close this loop? I feel like most of our focus historically has been on helping people identify vulnerabilities, and that's a good thing. Mm-hmm.

But can we automate the remediation of that? And there's tension, right? Because the security people would be like, yes, let's automate the remediation.

And the developers are like, no, you're gonna break my app. So can we get, is there a middle ground there somewhere? Absolutely.

Well, and that's where if you, if there's software that you care about, the one of the best ways you could help a project is right, test harness for it. If there's use cases that you need to have tests for, contribute those back to the project. And that's where the, the big problem is anytime you make a change to software, there's the potential for regressions.

It's, that's just a fact of how things work. How complex this, this, uh, community developed kind of a composite applications work is it's, you can't understand all the variables of all the different parts. And so if there's things you care about as a user, you can contribute that code back to the project, and hopefully it gets adopted into their CI systems that will help speed that automation so that eventually that could get there.

But there's always a potential anytime you change a line of code that there's an unintended consequence. And that's where, that's where the, the developers especially get fidgety about. If you're automating too much, uh, There are folks out there that are deeply concerned about application security at all levels.

Mm-hmm. How do they engage with the open SSF and how do they, because a lot of times they're like, well, I care, but I don't know who to call. I don't know where to begin.

And so where, what is the point of entry into that ecosystem and how do they get involved? And, and that's the, I personally feel is the beauty of foundations like the open SSF for organizations like O OSP or Eclipse, generally all of us are focused on different aspects of security or different pieces of software, but all of us hold 100% open meetings. And we also take open meeting notes so that if you can't make a call, it's eight o'clock at your time.

Well, generally that call's recorded. So you could watch a video or you could read the notes. They'll have a public, uh, source code repository.

We use GitHub. Other people use other systems, but everything's tracked. It's issues and pull requests so that there's a way that you can observe and kind of learn what's going on, and if there's something that's you're interested in.

So if you care about AI security or you care about NPM package repository type stuff, there's ways that you can onboard very easily, very minimally. And then if you wanna step in, you could start participating in the meeting, raise your hand, ask a question or propose an idea, propose a patch or a project like, Hey, have we thought about scanning this? Or we thought about this feature and the communities, all, all these.

And what I love about open source is that we, not everybody, but generally, everybody is very open and welcoming to newcomers. And we love, we thrive and grow on new ideas and contributions and contribution could just be feedback. Uh, I think that's a bad idea.

Uh, you should make the button blue, not red, uh, or it's actually, I'm gonna contribute some code. Maybe I'm gonna contribute a test harness. Maybe I'm gonna put some engineers on the project to help develop it.

Because strategic, this is important to me, and I wanna make sure that, you know, my use case, my user stories are considered as the strategy of the project goes forward. Last question. We talk a lot about AI security, and there's a lot of concerns about that and legitimately so, but I can't help but wonder if maybe we're finally paying enough attention to software development and security in the context of ai, and that may benefit the quality of the software we're building down the pike all the way down to the bottom of the stack.

I Hope my, my biggest complaint about just the AI space in general is that they have been, uh, they feel that they're a delicate, unique snowflake. What they're doing is so amazing and different than everything else that no one could possibly understand it. And there's not no standard or tool that would work for them, uh, except AI development is development.

And we have over 30 years of documented methodology and best practices that that space could benefit from. Yes, some of the nuances are different that you're using accelerators and GPUs and just kind of, the system architecture's different, but it's not that much different than like a telecommunications network or other things. It's a, it's complex, but there's a way that you can kind of break that complexity down into digestible problems and, uh, solve it with existing tools or improving those existing standards, and you're kind of participating in a bigger community instead of kind of spin off on your own.

All right, folks, you're heard here, so the software supply chain is getting more secure, and it may even get better in the age of ai, but we all gotta participate. Hey brother, thanks for being on the show. Thank you For having me.

All right. And we'll be back in a minute.