Summary
In this episode of What’s in the SOSS, host Sally Cooper sits down with technology executive and ActiveState CEO Abby Kearns to break down the rapidly evolving open source security landscape. Together, they dissect why reactive post-build scanning fails to prevent dependency debt, how machine-speed AI ingestion is overwhelming human maintainers, and what the impending EU Cyber Resilience Act (CRA) mandates mean for enterprise software supply chains. Abby offers actionable insights into why building a “start secure, stay secure” paradigm is essential for modern software pipelines and why open source communities must unite to redefine repository economics in an AI-dominated world.
Conversation Highlights
00:00 – Introduction: Sally Cooper welcomes ActiveState CEO Abby Kearns to discuss AI, vulnerability management, and open source security.
01:50 – The Limits of Reactive Scanning: Why controlling components at the build source beats post-build scanners.
04:39 – AI Agents and Ingestion Risk: Managing governance and dependency debt when code moves at automated machine speed.
07:55 – Regulatory Pressures & The CRA: Preparing for 24-hour vulnerability reporting deadlines and mandatory SBOM provenance.
11:17 – Upstream Package Repository Economics: Addressing maintainer burnout and the influx of AI-generated PRs.
14:03 – The True Cost of Exposure: Mitigating enterprise risk across foundational open source language libraries.
16:45 – Rapid Fire Round: Tux the Penguin, favorite emojis, time travel, and key takeaways for the community.
Transcript
Intro Music & Soundbyte / promo clip (00:00)
“Vulnerabilities are being identified at a much faster rate. And now the pace is only getting faster as more and more organizations are using AI to identify those vulnerabilities. And the pressure is on those contributors and maintainers to identify fixes, get those fixes released back into the upstream and allow those fixes to be applied to all the downstream. Our belief is that start secure, stay secure is the only pattern.”
Sally (00:24)
Hello and welcome to What’s in the SOSS, the OpenSSF podcast focused on ingredients, challenges, and solutions for making OS more secure. I’m your host today, Sally Cooper, and I have an incredible guest with me, Abby Kearns, an executive leader, Board Director with years of experience building and growing technology businesses. Abby, your career is extremely impressive. I know you do incredible work as the CEO of ActiveState. Also, some of us are familiar and love you from your time at the Linux Foundation as the Executive Director and CEO of Cloud Foundry, which of course is a fantastic Linux Foundation project. But I’m just really excited to have you on the show today. Abby, welcome.
Abby Kearns (01:09)
Thank you for having me. I’m super excited to be on here as well. Longtime fan of the work you’re doing here.
Sally (01:17)
That’s wonderful to hear. Well, I’m also a big time fan of your work. and yeah, we have some pressing topics to cover. So let’s just jump right in. I know we’re gonna talk about AI and security, a very hot topic right now. It’s very timely. Vulnerability management, which you have some incredible insights of, and I’m just looking forward to hearing your perspective on, especially securing critical project pipelines.
And the package repository economics, which is we could spend multiple podcast episodes discussing. And then security baselines. So I guess my first question for you is on enterprise security. I know that security teams are overwhelmed by the vulnerability noise, yet most are still relying on post-build scanning. Why does reactive scanning fail to solve dependency debt? And why is controlling components at the build source the only scalable fix?
Abby Kearns (02:12)
I think a lot of it comes down to the pace of change. Like I don’t know if anyone’s been paying attention to the news lately, but vulnerabilities are being identified at a much faster rate. I think even looking at the rates last year, we thought, wow, this is a lot of identifications of not just CVEs, but critical CVEs.
And now the pace is only getting faster and faster as more and more organizations are using AI to identify those vulnerabilities. And you have with that, you know, as we said, I’m a longtime lover of open source and an active participant in many open source projects over the last 15 years. And every open source project has a rich and lovely group of contributors and maintainers who are doing their best to maintain that open source project.
And with the onslaught of AI identified CVEs, the pressure is on those contributors and maintainers to identify fixes, get those fixes released back into the upstream and allow those fixes to be applied to all the downstream products and projects that customers are using or users are using. And so at the end of the day, we’ve got more and more CVEs being identified at a much faster clip.
Faster than scanners can even detect them, some of which the recent exploits are actually not even detected by scanners whatsoever. And so my view is that the only way to start secure, particularly with things that are critical to all the work you do, i.e., languages and language libraries, is to have a secure start to whatever you’re building, because identifying those things, malware, CVEs, after the fact is very costly to teams and organizations, but it’s also very complicated if you have to go back to the beginning and rewrite whatever it is you wrote. So our belief is that start secure, stay secure is the only pattern. But you should still continue to do scanning, but you should definitely not rely 100% on scanning to solve all of your issues.
Sally (04:26)
I love that. Great perspective on scaling security. Just shifting gears slightly on the impact of AI. Beyond just the simple code generation, AI agents are now autonomously importing, updating, and introducing dependencies into code bases. How can enterprise security architects evolve when dependency ingestion shifts from human decision-making to automated machine speed ingestion?
Abby Kearns (04:56)
I think that we have to rethink how we do the entirety of the software lifecycle at this point, right? If you’re using AI more to write code, you’re using agentic workflows to write, deploy, and manage code, you’re using AI now to validate that code, all of a sudden this becomes a very complicated machinery.
When you think about open source, and we’re talking to people that are subscribing to this podcast, care deeply about open source, and specifically open source security. And I think that is really where the power lies. 98% of all applications created today have open source in them. 85% of organizations are already using AI code generators as part of their software development lifecycle in some form or fashion.
But a much smaller number are using AI to do code reviews, validation. So a lot of code is going into production that has had limited review. And add to that that it’s happening at a much faster pace. ~ The thing that AI code generators can do for us is it allows us to write code much faster. It’s amazing. We can all go home over the weekend and write something. We can all write an app. We’re all capable.
However, for many people writing software that quickly, we don’t necessarily have the guardrails in place to ensure that we’re doing so securely. And AI is helpful. It is a helpful assistant. Everyone knows that is using an LLM knows how helpful it really wants to be. And so it’s going to go and grab the packages, the dependencies, the transitive dependencies you need to be successful to create the app or the thing or whatever you’re trying to do. It isn’t necessarily taking into consideration that there are risks with whatever it’s pulling in.
A lot of the conversation that’s happening today, which is to say, okay, how do we start applying guardrails and policies to the work we’re doing? But that governance isn’t in place yet. And that is something that I think is going to inject a lot more risk into the system until we figure out how to balance both the speed and efficiency and velocity that we all want with the governance and the security and the compliance controls that we all need in order to show that we’re doing so quickly but also securely.
Sally (07:20)
Yeah, perfect segway into what we’re just thinking about this month at OpenSSF and in this quarter. Our roadmap plan is to talk about the EU Cyber Resilience Act, the CRA. Many of these laws are now coming into play in September and December. There’s timelines. And just thinking about how you spoke on the landscape and it’s shifting under our feet with AI. On the regulatory side, with the EU Cyber Resilience Act. There’s this mandatory 24-hour vulnerability reporting requirement. I’m looking at it here on my desk. Many enterprises are unprepared for the reality of real-time disclosure. From your perspective as a leader, how can other leaders establish verified component provenance without halting active engineering pipelines?
Abby Kearns (08:11)
It’s a tough, it’s a tough, tough, tough challenge. And like I do think that we’re probably as a collective industry ill prepared for what the CRA is going to introduce. The CRA, if you’re not following along, goes into effect, phase one goes into effect September 11th, we’re going to have to adhere to vulnerability notification around as part of the CRA in December of 2027, the full SBOM, so the full provenance requirements go into effect as part of phase two.
And so there’s twofold level of the complexity there. First is in September, when the first phase goes into effect, you’re gonna have 24 hours to notify if you’ve had a breach. That means you have to understand where the breach happened, what happened, what package throughout the entirety of your supply software supply chain was impacted. You’re gonna have to have that both awareness, the knowledge, as well as the path for a fix, because you’re not gonna want to notify anyone if you don’t have a path to a resolution. And so it really truncates that timeline. Giving 24 hours to respond is a pretty short fuse for many organizations that may not have full visibility.
~ SBOM management has been something we’ve been talking about for several years, ever since the executive order came out, what was that, 23, 22, when Biden did the executive order around software companies being able to show, distribute, or document their full software supply chain and their full SBOM. And as part of that, you know, I thought that organizations would start to take SBOM, SBOM management a little more seriously, but sort of did, but we sort of didn’t. And obviously that executive order has been since rolled back. But new guidelines, particularly with CRA kind of being that forcing function, is going to push SBOM provenance, full provenance and attestation requirements back into the conversation again. And I don’t think organizations are prepared to track, manage, and be able to articulate the full breadth of what their software supply chain is.
And I think adding into that AI, AI just adds more complexity to that because it’s pulling in packages, dependencies, transitive dependencies that not everyone that is writing code is aware of at all times. And I think that that just adds a layer of complexity that I don’t think organizations are poised to address at this time.
Sally (11:00)
Yeah, the complexity, the speed, the compliance, they all play a role in defining how leaders can move forward. And just thinking through the upstream, critical open source package repositories are increasingly targeted through maintainer takeover and credential leaks.
What structural or economic model needs to replace current repository maintenance so that these enterprise supply chains aren’t left vulnerable to upstream compromises?
Abby Kearns (11:31)
That’s the billion-dollar question, isn’t it, Sally?
I think there’s a lot of people trying to figure that out as we speak. I mean, like, as I pointed out, we have a growing identified number of CVEs. We have no alignment across open source projects on how each project in each community want to deal with AI-generated code, AI-generated PRs, AI-generated reviews.
In fact, I’ve been writing about this a lot over the last few weeks personally because I think it is a very complicated topic. what do or what do communities want to do about AI-generated PRs and AI-generated code? Well, every community right now is treating them all completely different. What Rust is doing, which is a library-by-library assessment, to what Curl is doing, to what Linux is doing, they’re all different.
And I think that adds a layer of complexity to the fact that these going back to the small number of community maintainers and contributors that are responsible for maintaining these upstream open source projects are being overwhelmed by both the identification of CVEs, but also helpful PRs that are AI generated. And I think that there is a growing deluge of identified vulnerabilities and fixes on a very limited number of community maintainers.
Who are struggling with should they even allow an AI-generated PR? And if so, how do they review it? How do they validate it? How do they apply their trusted system to what is submitted? And I think that we’re watching that play out in real time. And I think open source is at a point where we’re collectively trying to navigate what the future looks like if everyone is using AI to write code now and distribute code and submit PRs and manage their projects, like what does that mean? And I think that we’re in the midst of probably a little bit of an existential crisis to say, how do we think about this going forward? What I think the process we have now is probably not going to work. If we’ve got a growing number of identified CVEs, we have to figure out a way to address those faster and faster and faster. And I think relying on pure humans alone, I don’t think is gonna help us navigate that effectively.
Sally (14:02)
Right. So the balance and the learning is happening all at once. And you just broke it down so well. Thinking about businesses, what is the cost to the business right now?
Abby Kearns (14:15)
The cost of the business is all of these open source projects, which going back to 98% of all of our software is open source, has more CVEs identified and exploitable than ever before. And the gap between a notification and identification and resolution is growing. So that means that every foundation and the fundamentals of everything that we’re writing is exposed.
So how do we close that gap? And do we invest more in these upstream projects to give them more contributors, more maintainers, more money, more dollars to help build out more automation? Do we go back to where everyone forks a version of each of these libraries, these projects, and is responsible for maintaining it themselves? Like, where do we fit in that? And I think everyone is choosing a different path right now.
My belief is that understanding at least what you have and or pulling from is a known good is a great way to start. That’s our bet here at ActiveState is that giving you a secure place to start and identifying when there are vulnerabilities, so at least you’re going into it aware is a great place to start. But I think that LLMs are introducing a ton of visibility and exposure risk.
And so we have to figure out how to navigate that with the tools that we have, which is becoming, I think, an active conversation. At ActiveState, it’s something we think about all the time because we’re focused just on language libraries, and that’s at the heart of everything that’s developed. So, how do we make sure that our customers, at least when they’re starting with the software they’re developing, have a secure foothold to start from?
And I think that from there, we’re gonna have to build out the collective community engagement to say, how do we maintain and mitigate the risk with more more identified CVEs?
Sally (16:13)
I love that, Abby. And you and the team at ActiveState are giving people a great place to start. I appreciate you walking me through that. I feel like I’m learning so much and this is so helpful for the community. We are now going to transition to the rapid fire round. So this is just fun. We do this on the podcast. I’m going to ask you a question, keep your answers to one sentence or less, and just say the first thing that comes to mind. Okay. Are you ready for the rapid fire round?
Abby Kearns (16:43)
I’m nervous but ready. Yes, let’s do it.
Sally (16:45)
Okay, nothing to be nervous about. No trick questions here. Okay, Abby, favorite open source mascot?
Abby Kearns (16:53)
Oh! That’s a tough one. Um…I don’t know. I think I like them all. Maybe the penguin?
Sally (17:03)
That’s a good answer. The penguin is so cute Tux. Especially because it’s the 35th birthday for Linux. So I think that’s strong. okay.
Abby Kearns (17:12)
My God, that makes me feel so old when you say that though. I’m like, Really? Really?
Sally (17:18)
Oh! Me too.
Abby Kearns (17:19)
Surely not. Surely that was like just fifteen years ago.
Sally (17:23)
Right? I know. okay. Switching it up to food. Mild or spicy?
Abby Kearns (17:29)
Spicy.
Sally (17:31)
Yeah. Favorite emoji.
Abby Kearns (17:34)
Is it my favorite or the one I use the most often? I’d say my favorite is probably the side eye, because I’m, you know, I think that’s that’s my but I I’d say my most use is probably like thumbs up.
Sally (17:49)
Totally. Checks out. Do you like podcasts or audiobooks better?
Abby Kearns (17:54)
both. I listen to both interchangeably. I think it just depends on my mood, but I do both. I’m a pretty aggressive user of both.
Sally (18:03)
Mm. Okay, this is random, but if you could time travel, would you go to the past or the future?
Abby Kearns (18:10)
I don’t know, probably definitely the past. I feel like the future is so unknown that I wouldn’t even know where to start.
Sally (18:17)
Good answer. All right. If listeners can take away just one thing from our conversation today, Abby, what would you want it to be?
Abby Kearns (18:26)
I would want it to be particularly given to the listeners of this podcast that there’s a huge opportunity for us to come together as a community. And I think open source is having a moment now that I think should really engage more open source participants and communities and contributors and maintainers in a much more meaningful way. I think there’s an opportunity for us to come together and figure out how to address these concerns. But I think it has to be open source driven, honestly.
Sally (18:57)
I agree. Thank you, Abby. And with that, I want to wish everyone a great day. Happy open sourcing. Stay safe and sound. And that’s a wrap.