Tag

OpenSSF

What’s in the SOSS? Podcast #59 – S3E11 Building a Connected Africa: The Origin Story of OSSAfrica with Prince Asiedu

By Podcast

Summary

This episode features Prince Oforh Asiedu, discussing his inspiring journey into tech and open source, starting from a childhood fascination with computers in Ghana, self-learning to code despite financial and economic challenges, and making his first contributions through documentation. Prince shares the origin story of Open Source & Security Africa (OSSAfrica), revealing how the frustration of repeatedly being denied access to global conferences due to visa issues sparked the idea to build a local, Africa-rooted community to connect and empower African contributors globally. He outlines the vision for OSSAfrica to become a serious contributor to software supply chain security, aiming for African voices to be recognized as trusted collaborators and leaders in the ecosystem.

Conversation Highlights

00:01 Introduction and Welcome to Prince
01:33 From Ghana’s Internet Cafes to Learning Python: Prince’s Early Journey
05:36 The Moment That Changed Everything: Starting with Open Source Documentation
10:46 The Frustration that Founded OSSAfrica: Structural Barriers and Visa Issues
16:42 OSSAfrica’s Growth and Community of Communities
19:01 The Vision for 2026: Success for African Contributors
23:32 How to Get Involved with OSSAfrica
28:32 Advice for the Next Wave: Growth Compounds When You Are Not Alone

Transcript

Yesenia (00:01.56)
Hello and welcome to What’s in the SOSS? OpenSSF’s podcast where we talk to interesting people throughout the open source ecosystem, sharing their journey, experiences and wisdom. So Yessenia, one of your hosts, and today I have an amazing guest for us today. A guest who has started early on in his career at OpenSSF in the BEAR Working Group and today is leading his very own SIG. Welcome Prince.

Let’s start off with introducing yourself to the audience. Can you share your background and journey into tech and open source?

Prince (01:33.339)
All right, so thanks very much, Yersinia, for inviting me and having me on this podcast. I’m really excited to be here. Thank you to the OpenSSF for this wonderful opportunity. I really enjoyed this podcast a lot, it’s a dream come true to be here. Yeah, so I’ve…

I’ve honestly been fascinated with computers for as long as I can remember. And my first real encounter with a computer was back in primary school, class one in Ghana. And I immediately fell in love with it. I didn’t have access to my own computer growing up.

Prince (00:00)
But whenever I could, I’d use my friend’s laptop, go to internet cafes, play games at game centers, basically anything that kept me close to technology. And that early curiosity never really left. After senior high school, I wasn’t able to continue to the university for financial and economic reasons. And that was a really hard moment for me.

So the question I asked myself was, what can I do regardless of my current situation? So to still get into tech or to get to use or be a part of this technology that I’ve been very much interested in. So I started searching on my own and go to cafes, look up resources and basically try anything that I could find.

So that’s when I discovered edX in 2017. And I took my first real course there on the edX platform.

Prince (05:36.131)
I took this introduction to computing with Python from the Georgia Institute of Technology, which had a free version of the course. And around that same time, I had a friend who was a software engineer, though I didn’t know what that term meant back then. I saw some of his books, asked about them, and he shared them with me.

Between those books and online courses, I would say that’s where I truly began learning to code. So the journey hasn’t been or wasn’t smooth, I should say. Constant challenges made consistency hard and there were long stretches where I couldn’t practice as much as I wanted,

But, I kept going, obviously. And then in 2022, when I was actively looking for ways to gain real-world experience, I came across Open Source. I first encountered or I started with Data Umbrella from a search on Google. And that led me to the Data Umbrella PyMC project. And that was my first real exposure to what open source meant. I didn’t really feel skilled enough to contribute code at the time, but the people in Data Umbrella on the PyMC project encouraged me to start with documentation. I had, I made a small documentation change, which got merged. And honestly, that moment changed everything for me.

So, it showed me that I could contribute in a community of diverse people without having to be perfect. And I learned that what open source meant was basically showing up with and willing to do what was available or work on whatever was available to work on.

From there, I explored other projects like GreenStand and worked on features, learned through community, just kept growing. Then in 2024, this part is very interesting to me, in 2024 I found the OpenSSF while trying to reconcile my interest in both software engineering and security.

And that’s truly got me into the security open source ecosystem. Through OpenSSF, I’ve met people like Christopher Robinson, who was really my first point of, I would say first contact in the OpenSSF community. And he pointed me to Jean Robert – a member of AfricaCERT in Africa obviously. And yourself, Yesenia and Marcella and Stacey Potter, David Wheeler and a number of people who have mentored me and challenged me up until this point. And I’ve also opened doors that I didn’t know existed, especially when it comes to open source. Yeah.

Yesenia (09:50.487)
So that was a beautiful journey that you shared with us, you know, through tech and as someone who’s come from immigrant parents, I can resonate a lot with paraphrasing the question you asked yourself, but what can I do given my circumstances? You know, not everybody has the opportunity or the finances to move through going towards their goals. And I really appreciate the resilience that you have in your story.

Like, alright, I can’t do this now, but how do I keep going? And I think what you shared are a lot of defining moments that you’ve had to lead to where you are today. And I can speak from OpenSSF. We’re very grateful to have you on our team on this journey. And you know, within the last couple of years from us chatting through the BEAR working group, you brought up a lot of challenges that yourself and other members have been facing when it comes to Africa and being able to do external speaking and finding those opportunities locally.

So I’d love to hear and share with the audience your origin story. Like how did open source security Africa get started? Like what were the problems that you were seeing in your ecosystem that made you say, you know, we should probably build something.

Prince (11:10.554)
Thank you very much for asking that. I will be meaning to talk about that a lot. So OSSAfrica really started from frustration, I should say, but also from hope. In 2025, that was last year, I had several opportunities, just like you mentioned, to attend major open source and security conferences.

So I submitted my first ever conference paper to VulnCon and it got accepted with support from Christopher Robinson, who’s been really incredible. Like I mentioned earlier, instrumental in my growth. The openness itself even explored or mentioned sponsoring. They actually did sponsor my travel, which felt like a defining moment for me.

But then I couldn’t attend and it was basically because of visa issues. Then the same thing happened with OpenSSF Community Day and again with Open Source Summit in the Netherlands. And every time there was opportunity, was this opportunity that I had, but access wasn’t available. I didn’t have access. And…

That experience really forced me to confront a reality many people acrOSSAfrica face. There’s talent and readiness. Talent and readiness exist, but structural barriers keep people locked out. So I started asking this question, why don’t we build something locally?

Not, instead of global spaces, alongside global spaces or alongside them. Something rooted in Africa that connects people into global open source and security ecosystems without requiring borders to cooperate first. So around the same time, I was working with a colleague, Seth Mensah, who had a similar vision around building Linux communities in Ghana and beyond.

So we brought in another friend, our colleague, Aaron Will Djaba, and started shaping what would eventually become OSSAfrica. Of course, when we started talking about this, we had a lot of names in mind and all that.

But, then we eventually settled for OSSAfrica. And this was not as a single organization, but as a community of communities. So I shared the idea with the OpenSSF BEAR Working Group on the OpenSSF BEAR Working Group chats on Slack and Marcella, who is a co-lead with yourself and Jay White suggested that we formalize it as a special interest group. We did all of this in October of 2025. By December, after community voting, OSSAfrica became an official OpenSSF Special Interest Group (SIG). That moment marked the real beginning of OSSAfrica.

So today, OSSAfrica exists to connect..our goal is to try to connect, empower, and amplify African contributors in open source and security. Whether through existing communities or new ones where none exist yet. Our goal is to build a connected Africa where contributors are visible globally, African voices are heard, and local innovation meaningfully shapes the open source ecosystem.

And honestly, none of this would exist without the early belief and support that people like yourself, Yesenia and Stacey, Marcella and Sally Cooper, four incredibly powerful advocates in open source, who helped guide and legitimize this work from the beginning. So yes, that’s basically how we started.

Yesenia (15:58.051)
I really like this because it’s a story of community, right? So it’s, we see one member in our community struggling or we saw, we actually saw multiple members of our community struggling to get their voices on the stage and the community came together, you know, brought together ideas and possibilities on how to solve this problem. And you and your team just went off and executed. I know that. you started in October, but from what I’ve seen, you know, I’ve been having from front row seats to Open Source & Security Africa since its inception.

It looks like you have a good growth of numbers. Like I think we’re looking at like what 10, 15 people so far.

Prince (16:42.618)
So we currently have about 90 plus people in our community on Discord. Yes, and we’ve had a number of people reach out organizations and just recently there’s this community founder who reached out, Kiala. I think there’s a lot that will have to we just started out in our conversations. So we see how that that goes. But growth on that front looks really, good. And we had a community lead for a community in Mauritius also reach out to try to partner with us. And yeah, we’ve had a number of people show interest, so we can really gauge our numbers by the number of people on our Discord channel. We’ve really seen people show interest in us.

Yesenia (17:53.039)
Yeah, but I think it really shows the necessity for this type of organization. mean, you’re four months in and you’re, you know, you’re already getting reached by, you already have about 19 active members. You know, you’re being reached by different organizations and partnerships. And I know I connected you with the Afro Adventures with Quiana that is running it, which I think that’s fabulous, you know, to see what comes out of that.

So, big kudos to you with that. This is what the open source world is, right? It’s a group of folks coming together, trying to solve a problem and getting a vision and executing. You guys are doing that.

Prince (18:38.287)
Yeah, yeah. I’m really excited about what our trajectory looks like, where we are going.

Yesenia (19:01.71)
Yeah, so start looking forward. What are you seeing? How are you seeing OSSAfrica impacting? Like what kind of impact do you want this community have locally, globally this year and the next few years? Like what does the success look like for you?

Prince (19:29.178)
So, mean, by the end of 2026, success for me looks like African contributors being visible and trusted and embedded across critical open source projects, not as exceptions, as maintainers, as trusted collaborators and leaders and open source community and space. Locally, I want OSSAfrica to be like a launch pad where people enter with curiosity and leave with skills, confidence, mentorship and real world impact.

And globally, I want OSSAfrica to be recognized as a serious contributor to software supply chain security, open source system sustainability, and community governance and security discussions. And in the long term, the goal is to build something institutional. Something not personality driven, but durable systems and leadership pipelines and partnerships that continue to continue creating opportunity long after any individual like myself steps away from the organisation. I’m never hoping, I’m not hoping to step away from the organisation, but I’m hoping that we become a strong and trusted institution globally.

So in the short term, we are focused on building strong foundations locally, especially in Ghana and West Africa. We want to do this through events and community programs and partnerships that help spark curiosity and bring people into the open source ecosystem. From there, we plan to expand across the continent, over the next few years. Yeah.

Yesenia (22:00.643)
This is amazing. I’m going to quote my mom and then I’ll translate it, “Mándame fotos, por favor.” So “send me pictures, please.” Because I would love to see the growth of this community. I’m every time my mom’s like, send me photos. So I’m getting a little emotional on this side because this really…Your story, the growth of source, open source security Africa is really representing what open source can do. So for the folks listening right now who want to contribute, they could be developers, security engineers, student, just anyone curious that wants to support, how can they get involved and meaningfully contribute to the cause?

Prince (23:32.154)
The easiest way is to just show up. We currently have, like we mentioned earlier, we currently have a public Discord community. We have a GitHub organization. We have open meetings and really essentially these are beginner friendly contribution pathways.

You don’t need to be a senior in any field in the tech space to show up or to join. If you are a student, if you are a career switcher, if you are a designer, a writer, a security practitioner, a community builder, or just about anyone trying to find your place in our world, you are welcome to join. So everyone has a place in OSSAfrica.

We want to help people find a place where they can work and connect with the community at large, which is aligned with their interests and pair them with people who can guide them into meaningful contributions. I mean, what you contribute to OSSAfrica depends, it doesn’t depend on any seniority skill level…whether it’s documentation, tooling, or education or research or community operations, there’s a space for you in OSSAfrica.

Yesenia (25:34.092)
This is awesome. Yeah, so you can always check out the OpenSSF calendar and join the calls. I believe they’re on Wednesday. And then there’s also the Slack channel on OpenSSF where a lot of movement is happening as well.

Prince (25:51.311)
Yes, yes. And thank you very much for adding those ones I nearly forgot about. We just created our Slack channel for the special influence group for SS Africa. The SS Africa special influence group. So that is a great thing to also collaborate or contribute your voice and perspective and how we can shape this amazing community that we are building.

Yesenia (26:22.766)
So you heard it from Prince folks, join OpenSSF Africa and help them move along. So we’re gonna move on to our rapid fire part of the interview. pew, pew.

Prince, I’m just gonna ask you some questions. You’re gonna say the first thing that comes to mind and we’ll go from there. So first question, books or podcasts?

Prince (26:43.3)
Thank you.

Prince (26:47.478)
I really like a mix of both, but I would go for podcasts.

Yesenia (26:56.342)
Awesome. Favorite programming language.

Prince (26:59.268)
Python

Yesenia (27:02.574)
Good choice. I’m a little biased on that one. Comfort food.

Yesenia (27:10.54)
What is your comfort food?

Prince (27:16.71)
So there’s this local rice, sorry, local food, sorry. There’s this local food called waakye and I really enjoy it. If you were asking about comfort food, what I eat to comfort myself, right? So then it’s basically, it’s waakye. I really enjoy Wachi and nuts and you should have it sometime. It’s really nice. It’s rice and beans.

Yesenia (27:31.085)
Yes.

Prince (27:43.608)
with some herbs, some African leaves. And it’s really nice. You should have it sometimes.

Yesenia (27:52.258)
You got me on rice and beans. I’m Cuban. I love rice and beans. Sweets or sour?

Prince (27:54.138)
Um, sweet.

Yesenia (28:07.682)
Are you an early bird or a night owl?

Prince (28:13.946)
I like to sleep early. I like to sleep early, so yeah. I mean, that’s my response to that.

Yesenia (28:32.236)
There you have it folks. That’s another rapid fire. And Prince, let’s end this with, you you’ve gone through an impressive journey through your tech and open source, right? You you shared it earlier, your resilience. And so what advice do you have for the next wave of folks, for folks that are entering tech and cybersecurity, you know, those that might just feel like an outsider, what advice would you give them and how can open source accelerate their growth and confidence?

Prince (28:58.618)
Okay.

Prince (29:02.572)
Okay, so first, feeling like an outsider doesn’t mean you don’t belong. It usually just means that you are early in the environment or you are in a new environment. And second, open source is one of the strongest accelerators, especially in my opinion, that I have ever seen.

You don’t need anyone’s permission, credentials or prestige. You don’t need anyone’s approval to join the open source space. All you need is curiosity and being showing up consistently and being humble to be willing and willing to be guided by those who are already in this space.

My advice, all you know is start small, learn in the public space, ask questions, and don’t wait until you see your regime. Usually it’s very difficult even if you are in the environment. It usually takes a lot of time. I took a lot of time before actually seeing anything in the community. that really helped me much.

So I would say speak up, ask for help, and then also read issues. And even if it is a small change in documentation that you can make, it really matters a lot and is very much welcome. You should also attend community calls and try to build relationships very early.

And most importantly, this is community that welcomes everyone. So find your community. And one last thing I would say is that growth compounds when you are not alone. So try and find your community. Yeah.

Yesenia (31:34.498)
That’s a good quote right there. Good compounds when you’re not alone. Prince, thank you so much for your time today, for your impact and contributions to our communities. I am so excited for OSSAfrica and to see its growth, its community and contributions this year’s and the upcoming. Thank you so much for your time today and folks, we’ll catch you on the next episode.

Rethinking Post-Deployment Vulnerability Detection

By Blog, Guest Blog

By Tracy Ragan

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

However, security does not end at build time.

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

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

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

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

The Growing Post-Deployment Vulnerability Problem

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

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

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

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

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

Current Approaches to Detecting Post-Deployment CVEs

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

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

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

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

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

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

SBOMs Are an Underutilized Security Asset

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

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

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

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

Detecting Vulnerabilities Without Rescanning

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

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

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

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

Digital Twins and Continuous Vulnerability Synchronization

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

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

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

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

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

Aligning with OpenSSF Security Initiatives

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

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

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

The Future of Vulnerability Management

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

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

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

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

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

Author 

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

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

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

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

By Blog

By Jeff Diecks

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

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

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

Today, we are taking an important step forward.

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

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

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

OSS-CRS Features include:

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

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

From Competition to Community

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

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

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

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

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

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

Get Involved

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

We offer several options to get involved including:

Author Bio

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

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

By Blog, Guest Blog

Cross-post originally published on the Kusari Blog

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

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

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

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

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

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

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

Kusari Inspector helps OpenSSF projects:

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

Kusari Inspector – Secure Contributions at the Pull Request

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

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

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

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

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

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

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

Author Bio

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