Software Supply Chain Security 2026: Insights on Vendor Capability, Market Gaps, and Regulatory Readiness

Good day, good morning, good afternoon, wherever you may be. My name is Jonathan Care and I'm the lead analyst with KuppingerCole Analysts. With me today is Mitun Zavery, who is VP Solution Architecture for Sonatype in EMEA. Hello Mitun, it's a pleasure to have you join me for this webinar. Pleasure to be here Jonathan, looking forward to this and welcome everyone and thank you for your time.

All right, so the webinar we have today is on KuppingerCole's recent software supply chain security leadership compass and what we hope to do is provide you with insights on vendor capability, market gaps, and regulatory readiness. It can be supported by Sonatype, but as always, obviously, we present our own independent opinion and findings.

So, a few housekeeping points before we begin. You are all muted centrally and we're controlling those features, so there's no need to mute or unmute yourself.

Secondly, questions. We will be having a Q&A session at the end of the webinar.

In fact, we're going to be running a panel session following the presentation, so please, and we do encourage you to enter questions at any time using the Livestorm control panel. Thirdly, recording and slides. We are recording this webinar and the recording and the presentation slide decks will be made available to all of you, pardon me, for download in the coming days.

So, without further ado, without further ado, let's continue. Let's go into the presentation.

So, what I'm going to discuss today, we cover five areas. First of all, I'd like to give an overview of the market context and scope. I'd like to show where I think the regulatory floor, which is certainly driving some of this.

Thirdly, I'd like to talk about how we rate the market. Fourthly, some key, three key findings from the 2026 Leadership Compass. And finally, what buyers should do next, followed, as I said, by a discussion panel, which we invite you to participate in.

So, moving on. Why are we looking at supply chain security at this time and in this way?

Well, what we're seeing is that attackers are bypassing the hardened perimeters, the expensive firewalls, the WAFs, and all of these, you know, perimeter security controls, because they are exploiting trust arrangements. They're exploiting the build pipelines. They're exploiting the open source dependencies. And there are three vectors which I've listed, obviously, on this slide. The first being weaponizing of open source packages. And by this, I mean that you have malicious publishing and typosquatting.

So, for example, there was a piece of code called XZ, or XZ for those of you in the UK, that suffered this. They had some contributions from a pseudo-anonymous person who made several, you know, valuable, positive contributions to the source tree. And through that, became seen as a position of trust, and then started introducing very obfuscated code, which also had, unfortunately, a vector for remote, arbitrary remote code execution, or as we would call it, hacking in. And so this happens, and this happens not just to XZ, but to all sorts of packages.

The Python source tree and the packages tree, PyPy, has actually seen this happen, and is certainly taking some stringent steps to try and get away from it. The second vector is where code enters the repository with no author, no license trail, no attestation. So this is what we would call AI-generated code of uncertain provenance. So it may be good, it may be bad, but we have no way of judging that because we have no way of understanding where it came from, which is one of the key methods of determining software quality. And the third is what we call a cascading dependency failure.

So for those of you who've seen the dominoes toppling games, it's a bit like that. So one package breaks, and then that triggers breaks in package after package after package. And the blast radius, if you like, the locus of the damage is discovered after the fact when you see, well, actually how many packages were affected by this, and can be quite significant. Think about, for example, a buffer overflow in the DES algorithm. Think about the bug that was found in the libraries for finding everything from logging to Minecraft, log4j. So log4j breaked, and the blast radius was massive.

It was everywhere, and we're still trying to figure out exactly what was affected by it. So moving on to the market definition and scope. We tried to benchmark vendors across the entire delivery path, and not a single stage. And the source, repository control, secrets detection, contributor identity, through to build, so pipeline integrity, SLSA alignment, non-human identity governance, through to the package, SBOM generation lifecycle, dependency and license analysis, through to distribution, and consume. And you'll notice that distribute and consume are red flagged.

This is because we found the weakest coverage in these areas. Clearly, there's obviously an opportunity there for new vendors or existing vendors to expand.

So again, code signing, provenance and attestation, registry policy. It's not just GPD anymore, folks. So there's some interesting stuff there.

And again, downstream consumer risk, third-party SBOM ingestion, and compliance evidence. So again, if you are trying to ingest an SBOM to do some comparative risk, this is an interesting area. And so I'd like to talk about the regulatory floor. And by this, I mean the regulation that drives this. And I think of the regulation driving a particular area as a baseline or the floor. It is not the pinnacle. It's not the summit of achievement. It is the baseline that we absolutely must maintain rather than a technical aspiration.

And so clearly, there's a few legislative instruments that come to mind here. And one, being a good European, is the EU Cyber Resilience Act. It demands SBOMs, it demands vulnerability handling, and update obligations for the product lifetime. And it binds anyone shipping software into the EU, which includes pretty much every vendor, large or small. If you plan or you do ship software into the EU, if you provide services into the EU, then this impacts you. And similarly, we have NIST SP 800-218 or SSDF. And these are documented secure development practices and build provenance.

This binds US federal suppliers and their subcontractors. So between those two, you have a large part of the – well, certainly the northern hemisphere sewn up. And you look at DORA, you look at NIST too. And of course, this extends to third-party risk registers. This extends to concentration exit analysis. And DORA is aimed at EU financial entities and their critical providers.

So if you are providing into a bank, if you are providing payment software, if you're providing treasury, if you're providing ledgering, if you're providing customer account origination and management, all these things – the core banking packages, all these things are impacted by DORA. And NIST 2, supply chain security as a named management responsibility. So in the same way that if we were running a manufacturing center, we would consider our supply chain security to be a critical management responsibility, it's the same with the software supply chain.

This is considered essential and important for, yeah, key entities in the EU. So how does Cuppinger Coal rate the market? We created, or I created, six areas across all rated vendors. And we noted market-wide as one of the factors. And the six areas are source and build integrity, vulnerability and dependency management, secrets and non-human identity governance, package repository controls, code signing and attestation, and downstream consumer risk.

And again, you'll see this pattern that I mentioned earlier. So source and build integrity, there are very, very good solution there by sophisticated, mature providers, and similarly for vulnerability and dependency management. We consider those market areas to be mature. Secrets and non-human identity governance is somewhat uneven. There are provided in there. They provide software of quality. Nevertheless, you could say that the competitive landscape is perhaps unserved, and perhaps there's a possibility for expansion of capabilities, expansion of feature scope.

Package repository controls, again, much the same. It is uneven. There are a few providers in this area, but you don't have the scope that we see in the first few areas. And finally, code signing and attestation and downstream consumer risk, we consider those to be underserved, which means there's plenty of room for competitive entry in there. There's plenty of room for existing providers to expand their capability portfolio because actually, yeah, the market is not getting the value that we would anticipate being provided in that area.

So I'm going to talk to you about how I think you how we should read our leadership compass, and we have four independent ratings, and it's quite possible for a vendor to lead one and trail another. So we have the product, the functional strengths and completeness of the offering as it ships today. We have mentioned innovation. This is a delivery of new capability that moves the category, not just the roadmap. And then market.

This is, yeah, customer base, geographic reach, partner ecosystem, financial position. And finally, of course, a combined view. This is the only rating to be read alone, and it is the weighted combination of the other three ratings. So we had 12 vendors rated in full, probably an indication this market is developing, and certainly found eight vendors to watch.

So again, I remind you this is being recorded, but for those of you who wish to do a screen grab, I will pause a little bit while I talk about this. Our overall leaders in pretty much alphabetical order, SciCode, Data Theorem, Palo Alto Networks, Sonatype, and Veracode. They were overall leaders in this leadership compass. So we felt they led the market from both a product innovation and market view. We saw Lineage as a product leader, so we're particularly impressed with their capabilities.

We rated, in addition, Armika, CloudSmith, GitGuardian, NetRise, NSFocus, and Orca Securities. You'll see there's a global mix there of vendors. And obviously, I'm – I would say that vendor recruitment for the next version of this is already starting. So if you to participate, do drop a line to leadershipcompass at capandgicole.com, and our research operations team will be very glad to assist and direct you, point you in the right direction. So let's talk about the findings, because these are important.

I said attestation is the market's most underserved capabilities, and this is exactly what Finder 1 is. What do I mean by that?

Well, code signing, provenance evidence, where code came from, is the lowest across the rated field. And it's precisely where Cyber Resilience Act, SSDF, DORA, and NIST too are most explicit. This is where you say you must have these capabilities. So let's say there's considerable scope for expansion in this area. The second finding is that the platforms are closing the gap on the specialists. Nevertheless, the specialists still have certainly some considerable headway. The unified platforms are acquiring their way into SSCS.

They're reaching feature parity on breadth, and they have a lower operational complexity and a single policy surface. And the trade-off, as there obviously are with the platform providers, category innovation lags. They may be good at some parts, but not, say, all parts, and obviously depth varies by the modules that they have acquired. Our focus specialists, so people that really drive the innovation and indeed drive this market, they're still leading on secrets detection, S-bomb generation, and code signing. They are fastest to ship when emerging threat classes come out.

So when something comes out that you need coverage of, it's the focus specialists that turn something out quickly. The trade-off.

Well, we see the integration burden is consistently underestimated at purchase. No tool in the security suite is completely isolated. So even though you might think, well, what does the software supply chain have to do, it should certainly integrate with your risk management platform. It should possibly integrate with your vulnerability in the ASN platform.

So yes, the integration burden is consistently underestimated at purchase, which isn't just software supply chain. We do see that across a number of areas. And the specialist advantage is compressing.

By that, I mean, yes, they still have the advantage, but obviously the distance between the unified platforms and the specialists is reducing. So my advice is to buy for the capability you are weakest on, for example, secrets detection, for example, S-bomb generation, not necessarily for the longest feature list. So I think what that requires, obviously, is a very mature piece of self-examination as to where you need help the most. Finding three. AI-generated code breaks all sorts of things, but certainly breaks the human-provenance model. If there's no author, there's no attestation.

We see generated commits arrive without the human-provenance chain signing machines. Now, obviously, in between the finalizing the support, and now we have seen the frontier models talking about watermarking the artifacts they produce, which include text, which includes graphics, and can include code as well. The second is that models are undeclared dependencies. So obviously, the frontier models, we all know about the code. We all know about OpenAI, ChatGPT. But there are the open-weight models like LLAMA. There are the open-weight models like GLM.

And the open-weight models, again, including Kimi, and the list goes on. Well, these open-weight models and their training data are not normally part of any S-bomb format. I've had to go further than that. I've never seen them in an S-bomb. And what that means, of course, is that if someone perturbs, the open-weight model is changing the weightings. If they change the training data, so the model reacts differently, then the code that they produce will be different.

So, for example, if you feed an open-weight model with lots of examples of exploit code, it will be more likely to introduce exploit code as a response to a prompt. And, of course, there's various other ways of perturbing the models to produce the results you want.

And, of course, because there's no author and no attestation, we don't know whether it's being produced by a Claude. We don't know if it's being produced by a LLAMA. We don't know what's going on, where this code will necessarily come from if it's done by AI. And I have to say that the vendor responses we got on this were largely, not exclusively, but largely, it's on our roadmap.

So, again, we're seeing wide claims, but narrow demonstrations of code governance. And I think it's important if you are in a buying position that you ask for the shipping feature, not the code that is going to arrive real soon now, the stuff that is here right now. And my advice on this finding is that final sentence in the last text. If you have provenance, attestation, and threat intelligence, these are baseline expectations. This is table stakes. They're not differentiated anymore. You should expect this. And the differentiators are the other things that you look for.

Deployment and interoperability. We find that to be a persistent weakness.

And so, when you think about the various deployment environments, there is perhaps some understandability to this. When you have hybrid estates, which can be on the cloud, could be on requirements.

So, again, the requirements of a DC has it in Switzerland be very different from DC has it in New York State. The on-premises environments with strict network boundaries, and indeed the ultimate strict network boundary, the air gap, which is obviously applicable in some high security environments. Think bank treasury, think some central bank environments, and even possibly think government and defense. We see certainly a again, a great variance there. How organizations interpret or integrate with the existing tooling.

So, CICD, ticketing, and registry is, again, is not a uniform skill, although one would think that that becomes a, again, it actually is not. Overall, and I think this is true not only of software supply chain, it's true across the board, that if we add friction by adding security, we are asking to be bypassed. And devs are extremely impatient. They just want to get to the next thing as quickly as possible. This is obviously innate in the developer mindset. It's why we, you know, why we love them as devs.

But it's also something that's being strongly pressurized by managements who want to see their developers producing functionality and moving on, producing functionality and moving on in that kind of productivity loop. And so strong programs, the best programs, take that secure path and make it the easiest path, the one that you would fall to by default.

So, I'm not asking people to do different things. I'm not asking them to jump through hoops. I'm making that the easiest path, the one they can just fall into by nature, if you like.

So, we had some vendors which are called vendors to watch, and these were not rated in full this cycle. However, they are interesting, and they either have narrow scope, they are new entry, or they came in outside the evaluation window. Several of these are candidates for the next edition, and I will leave you to guess as to which those may be. But all of them are interesting. Aikido Security is a developer-first consolidation of the scanning at the SME price point.

So, again, they are trying to democratize, they're trying to bring source code security into the hands of the SMEs. By doing so, they managed to push this down the supply chain. It's not just for the top of the chain, the bank, or the manufacturing organization. This actually, yeah, we're extending it down.

Apiro, very interesting because they have an application risk graph which links code changes to business context, and clearly something that we are all being asked to do is to demonstrate efficacy of security code by linking to business context. So, again, ChainGuard, interesting because they provide these very minimalistic, very hardened base images, and they put provenance built into those, so you know where the code that is in these hardened images comes from. You know what the development lifecycle was.

So, again, an interesting approach. Checkmarks are established, and they do a lot of work in the AppSec security space, and they're extending that into the software supply chain.

So, a subtly different problem. Essentially, I would sort of say moving from managing the internal dev problem to the external dev problem.

And, similarly, Endor Labs. Endor are providing a reachability analysis. The reason they do this is it cuts the volume of dependency alerts.

So, if your code never actually reaches a certain point in the execution point, it never goes near that code, then it's something you can pay less attention to. Always remembering, of course, that the goal of an attacker is to make code execute something it wasn't intended to do, hence the name executing arbitrary remote code.

So, Endor, again, I think is providing some quantification on this, and, yeah, it's an interesting company to watch. JFrog do provide registry native controls at the artifact layer.

Again, nice, innovative, and looking forward to seeing if they participate in the leadership compass next year. SNCC, as anybody who has put a commit into GitHub or GitLab, I think, for that matter, you'll get a message from SNCC telling you where you have made a mistake, where you've included a library that has a security vulnerability. And that broad developer adoption across the largest repository in the world, GitHub, and the ability to reach an integrate with IDEs at quite a deep level, makes SNCC a very popular choice in developer shops.

So, hence, it's one to watch here. And finally, Socket. Socket do something which I find very interesting coming from a fraud investigation background, as I do. They provide this behavioral analysis of packages which catch malicious publishing.

So, the idea being that not only do our human actors have behavioral traits which can be monitored, observed, and used to make decisions about security and so on, but our packages, our non-human actors, also have similar traits. And, of course, where we see packages doing something malicious, where we see them phoning home to a command and control server, where we see a package once installed downloading additional code which, upon scan, proves to be dangerous.

Where we see them trying to execute low-level disk operations, which is obviously very common for malware and ransomware, then Socket is designed to catch that. So, if you have these kind of narrow, specific gaps, then these watchlist vendors can be a better answer than a platform module.

But, as I say, what we are hoping is that next year we will be expanding our coverage to include many of these very interesting vendors indeed. So, what should buyers do next? And this is where I'm wrapping up and shortly going into panel session.

First, you should anchor the evaluation in a risk exposure and then ask three questions. One, how demonstrably ready is the vendor? How ready are they to show you provenance and show you AI code governance?

Secondly, does platform consolidation justify trading away specialist depth? This is a serious consideration and needs to be thought through. And thirdly, is active open source threat prevention is shipping or is it just roadmap? And you need to be looking at the threats provided by open source because nearly every software supply chain out there from, well, from anyone you can think of, from the largest of vendors to the smallest, usually contains at least one open source package.

So, a little bit about Cover Your Cold before we move on. We are analysts. We should analyze trends, markets, and software solutions. We do this through a mixture of our research, our events, webinars, and our advisory team. We provide, as I said, our advisory services are a group of extremely smart, extremely intelligent people who provide vendor-neutral strategic guidance. And we help organizations define, design, optimize, and evolve their identity and security capabilities with confidence.

And I know that my colleagues are working with some of the largest organizations in finance, telecommunications, manufacturing, what have you. Coming up on October the 7th is AI and Non-Human Identity Impact Day. If you want to meet me in person, that may well be the place to be. Our key topics are going to be the evolution from human IDA to machine DGE. And this is something I think that my friend and colleague, Matthias, will be covering. We will be talking about workload identity and cloud native trust.

We'll be talking about identity for AI agents acting on our behalf, which again certainly impinges on source code software supply chain. We'll be talking about identity governance beyond humans and indeed identity threat detection and how this intermeshes with cybersecurity. And finally, we're rounding off the day with identity fabric for the autonomous enterprise. So if you are available, I look forward to meeting you in Munich on October the 7th.

As I say, we have some related research here. I'm not going to skip on, stay on this, but certainly the clickable links will take you to our relevant spots on the Copenhagen Research Library. So without further ado, if you have any questions, do feel free to obviously drop them in the chat. But now I'd like to open up and invite my colleague, Miten Zavri, to join me for the panel session.

Miten, hello, how are you? Fantastic, Jonathan, and yourself?

Yes, good. Tell me what you see in Sonotype as sort of your vendor journey through software supply chain. A really great question, actually. So as an organization, Sonotype is kind of born in open source, right, if I am to use that term. We started as an organization that created the first open source registry globally. If anyone's ever done a bit of Java development, Maven Central is fundamentally what our founder and CTO created, Brian Fox.

And through that journey of, you know, sharing open source packages and allowing enterprise organizations to use those open source packages developed by, you know, someone developing it in their garage or their garden, we realized very quickly that it created a unique problem of, I would say, scale and consumption. And so that then led to the ability to create a single source of truth within organizations that they could consume from. So proxying it by a, you know, a solution, an artifact management solution.

But then that evolved into, now you've created that problem, how do you solve the next problem, which is, how do I know that open source is good? So supply chain to us, or the software supply chain as it's come to be known today, is something that we've been living and breathing since the inception of Sonotype, actually. And so we really believe that it's something that we have the identity and the DNA in to be able to help organizations solve that unique challenge that, I would say, I've been talking about it for, you know, over eight years.

Organizations are only coming to the realization now over the last five years that software supply chain is extremely brittle, right? And you look at the consumption of open source as, you know, 9.8 trillion open source packages that were consumed just last year, right? Right.

And, oh, thank you, Meaton. And before I kind of carry on the conversation, yeah, Maya, to the audience, we welcome you. Please do put questions in the Q&A tab, and we will answer those.

Well, first of all, we'll answer those by rotation, but also by how cool the question is. I play favorites. I have no shame in that. You said something just then, Meaton, that really interests me. You said it's brittle. Why is that? So open source is an ecosystem, I would say, across all of the different languages. When you think about it, there are some mature ecosystems out there, Maven being one of them. You have MPM, obviously, out there, MPMJS, sorry. You've got Python.

But all of these ecosystems are backed and are effectively contributed to by developers that are not really paid to do this as their day job, right? Also, if you think about it, just from a sustainability problem, these ecosystems are, you know, are contributed to.

So, you know, there is no paid service or way of maintaining these open source registries. So brittle in two ways, right? How do I know that that individual contributing that open source package is doing the right thing, right, for my organization, even though I'm using that framework, you know, take log4j or XZ utils or whatever it may be, right? And then secondly, is that registry going to be up tomorrow? What happens if that registry disappears?

You know, we've done some research on this and realized that as an ecosystem, the open source registry itself is the third largest economy in the world, right? If that was to disappear, you know, people would be back, you know, probably 10 years in terms of their innovation, their digital transformations, and so on. One other thing surprised me. Many of the source code repositories use GPG, a popular encryption package, and I was, a few years ago, I discovered that the guy who maintains GPG was living on the breadline, just about, and he was, you know, in a state of near poverty.

So this package, which is essential to all of us, this guy is running out of food, which, yeah, well, is, again, I think, a sign of this brittleness. But as you say, there are so many people who are contributing their code for, yeah, love of the art, I suppose we'd say. And as you say, if all that went away, we would all be, yeah, we'd all be in an uncomfortable position. And I was particularly interested when I came through these results, and when I saw that, yeah, code signing and attestation downstream consumer risk, there appears to be quite a gap there in terms of the capabilities.

I don't know if you had any thoughts on that. So when you look at solutions as a point solution, right, we've seen these sort of peaks and troughs in the industry, I think, specifically, you know, when you think about cloud, when you think about Kubernetes, when you think about digital transformation, we've seen all of these big ticket item, you know, sayings in the market. And this year, the latest one, as you all know, is AI, right? And so what we're doing is abstracting or complicating the already known to be, I would say, complex problem of software development, okay?

And trying to address point capabilities in the market for organizations is extremely difficult, because what may be a serious problem or a serious capability for one enterprise customer may not be that problem, right? So for example, you look at the banking industry, regulation, CRA, all of those things potentially are a problem.

And again, it applies outside of that. But take banking rules and banking industries, that applies to them. So they may have specific things related to them, right? But that may not be the same for a gambling organization, right? So when you look at solving these problems, as a vendor, as a solution provider, you have to think about what's the long-term and wider problem you're trying to solve. So if I talk about it from, you know, just my perspective, and Son's perspective, we know that organizations consume open source.

We know that organizations rely on open source to develop their software, their frameworks, their infrastructure. So giving organizations the ability to govern that through policy and an agnostic way to apply that across all of your development ecosystem.

So, you know, not just bottling it into, this is NPM, this is Java, this is information security, but giving organizations ability to look at that risk of open source and their, you know, regulatory needs in a single pane of glass, in a single platform, makes it a lot better because ultimately maturity is going to be driven by regulation, best practices within the organizations.

And you talked about some of them there, when you talk about NIST2, when you talk about DORA, CRA, we can ignore those regulations as long as we can, but at some point there will be fines, there will be implications, there will be individuals asking for, tell me what your S-bomb is. I mean, we see that today with our own solutions, right? Organizations asking us, what do you do for software supply chain? And actually that's a really interesting story to ask a vendor who kind of designed and created this space, right?

Yeah, I, yes, I saw some of the early S-bombs that were published had some, yeah, some surprising inclusions in there. So, yeah, and I think this is leading on to some of the questions we have from the audience.

So, Sunak asked a pretty broad question, it's never, it's interesting, how can the supply chain problem, he says, how can it be solved? Yeah, that's like, what can we do? Take a sledgehammer to a hammer problem, right? How do we do that?

So, I think there are multiple areas, right? Solving the software supply chain problem is about best practice and what organizations do. Let me use an analogy, when we look at car manufacturers, the supply chain is, the software supply chain is really just a different type of abstraction of the supply chain of an automotive manufacturer. When you think about back in the day, Edward Deming, and the principles of how you build cars, source from fewer suppliers, make sure that you are building the right things into a vehicle, making sure that you have the community from a software perspective.

And what that requires us to do is address two of the first things that I said, which is source from fewer vendors or source from fewer individuals. And what that really means is don't have 350 different versions of React inside of your organization, have one version of it, right? Maybe that's a guaranteed framework that you use across the business. Make sure you're sourcing your open source libraries from a known trusted source, right? Gone are the days where people do code snippets and pull things in. They use AI these days. But where do you think AI pulls its components from?

Controlling that and being able to make sure that your AI coding assistants are pulling from the correct sources, they're pulling from known registries like NPM Maven, PyPI, Hugging Face, because those registries have between them agreed that there has to be a joint initiative to solve this problem. And when you see things like Project Decretis and all of the other initiatives that massive large enterprise organizations are taking part of, you realize that it's a problem that everyone is trying to solve, right? And they're trying to protect that supply chain.

So at a highest level, the open source the best components. Validate that that component is actually what you believe it to be using. Validate that your AI coding assistants are using the correct open source libraries and they're sourcing from the right parts. Have policy, right? Validate that across all of your supply chain. Brilliant answer and thank you for the completeness. I suppose in discussion I was having, you know, with one of my colleagues and we're talking about where software supply chain starts and attack surface management stops.

And I think the software supply chain, as you say, you are ensuring the safety, the provenance, the, you know, overused word, the governance of, yeah, the software product you bring from outside, whether it be open or closed source. And whereas as an attacker knows much more about your internal security posture about, you know, how are you standing up all this stuff and how are you managing risk to it? I think that leads us nicely into another question from Marcel. Marcel asks, does it use, does it make sense to use a solution like this also for commercial software?

Well, yes, absolutely. And our supply chain is both open and closed source. I would like to have every, a broad solution that covers everything to ensure a convenient process, which sounds good. And I think, yes, you should have something that covers your open source supply chain and your closed source and indeed the mingling between the two, which you'll discover. But I mean, yeah, how would you see that sort of in practical, tangible terms, Mita? So I see this as open source feeds the creation of the closed source elements, right? You're obviously going to have your own internal libraries.

And if I answer this from just how we talk about it and how, you know, Sonotype C closed source, of course, anything you create or any, any libraries that you create or code that you create are not going to be things that the vendors or the solution providers have an understanding of, right? They'll understand whether it has, you know, a remote injection attack or it's bad code or it's not optimized in a specific way, but they won't know what the context is.

However, when we think about software or software supply chain, anything that we don't know, and what I mean by that is anything that we don't have identity on. So it doesn't have, let's call it a passport number, right? We classify as unknown. So what that means to us is if we don't know anything about it, we're hoping that you know something about it, the fact that it's in your code base. So we allow, you know, our customers and organizations to be able to claim those, those closed source components and say, actually, right.

Sonotype or whoever the vendor may be, doesn't really know anything about it because it's actually not a third party library. It's not open source. So I'm going to claim it. I take responsibility for my library, for my code. So now what you're doing is when you think about SBOMs and you talk about SBOMs and how people have to generate this, SBOMs, I think are sometimes misunderstood, right? People assume it's just a third party. No. SBOMs are a definition or a recipe for everything that's inside of your software.

And so if your closed source is inside of the thing generating your SBOM and it says it's unknown, it's unidentified, that's not a bad thing. That's just saying I, as the solution provider of your, let's say your software composition analysis or your software supply chain, doesn't have any identity information, but if you know what it is, tell me, because then I can enrich the SBOM with that. So there are many solutions out there that have the ability to do that, right?

But you should have, and I think this is the most important part and the part that really matters when it comes to this question is, the policy and the rules that you have for allowing the egress or ingress of those, let's call them libraries or closed source components you use, should all be mapped against a single set of policies, right? You should have the context to know, is it a public facing application? Is it a hosted application? Is it an internal application? No one really will worry about it that much.

Applying the context on it is really, really important and that's something, you know, we definitely ensure our solution, our customers actually have access to. I think, Sunak, you come back with a bit more clarification. Is there a concrete solution to the supply chain problem?

Well, yes, there is, but like most, I think, in cyber security, it's a mixture of policy procedures and processes. So, yeah, things that people do. I think the tooling is what we've addressed in the leadership compass, but there is no doubt that this also involves making sure that you change the way you work, you change the way you ingest software into your organization, as well as adopting tooling that checks provenance, that checks vulnerability status, it checks package repository status and so on. What are your thoughts, Mita? Is there a concrete solution?

Yeah, look, I would be remiss to not say that there isn't one, right? I work for one of the leaders in this, right? There is. The software supply chain space is one that I think will be here for many, many years to come and I think it's just going to be propagated by the fact that AI is contributing to that positively and negatively as we evolve in this space. All of the solution providers, all the registries out there, already implement their own validation checks on the open source libraries, right?

I know from a Maven perspective, we validate all libraries that are committed to Maven Central. So, actually, if you look at the registries, you'll notice that NPM, PyPI are in the market and see a lot of this, but in Maven, you won't see many of those except for, I would say, vulnerable libraries, things that have aged really badly, okay?

So, the vendors, the repos, the central repositories are doing all they can to validate the components. Things like, you know, the open source projects like Project Decretes and things like that are doing things to try and solve and fix those problems in the open source registries as well. We monitor whether the open source libraries are good committers or bad committers. How often are they doing that? We can't control that open source element, right? We can't force the projects to upgrade components and so on. That's a community based approach, I think.

But if you and your enterprise provide your developers or your AI coding assistants with a single source of truth, a single place for you to pull those open source libraries from, a single way to convey your policies and your risks to them, to the developers of the AI coding assistants, you provide remediation guidance, an ability to actually fix the thing that is broken, right? You're not going to expect your enterprise developers to go and fix open source code.

No, that's not something you do. You simply upgrade the version or move to a different framework, move to an open source library. But if you're providing all of this, and you're doing this in a, you know, single control plane, right? In a single way, that's solving the supply chain problem to an extent, right? Or making that problem far less big and scary than people think. So I think it can be solved. And I think that's the concrete answer.

The concrete answer is, give your enterprise, give your engineers, give your AI coding assistants, a single source of truth, a single ingress point, a single way to understand what has been used, identifying what is within the organization, understanding the risk, understanding what is going out, and just doing that as a platform, I think, is the right way. Having point solutions that do different things requires you as an enterprise to jimmy rig that all together, which is extremely difficult and a huge maintenance cost. Thank you.

Yeah, I agree. I think, by the way, Tunax come up with another question and said, oh, I'm sorry for another question.

Well, don't be sorry. We love it when the audience engages. So from my perspective as an industry analyst, yes, it really is. And that's a driving force behind why Cupping & Co produces these leadership companies. We are doing our best to identify reliable suppliers. We're doing our best to identify ones that are feature complete, that are financially stable, that have a track record of successful delivery, reliable delivery, and provide solutions that we see are relevant and important to the market we're researching. So that is a driving force behind our leadership companies.

And as I said, there are solutions I described previously that, if you like, hit our leader's space, and Cenotype being one. Those are solutions where I think we can have a high degree of confidence in. Other solutions may have, if you have a particular requirement, other solutions may be suitable. And we're looking – just to give you folks a sneak peek behind the curtain – we're looking at how we can quantify where those challenges in the space provide the most value.

So we're looking to see how we can provide an extra dimension of quantification, which, again, we do in the hope that we are identifying good suppliers, good solutions for you. But yes, obviously, getting a reliable supplier is important. Getting a supplier that you trust to deliver is key to this. And just to add to that, Jonathan, how do you trust a supplier? Look at their provenance. Look at where they come from. Look at what matters to you as an organization. Both of us, actually, have talked about attestation, identity, understanding what the open source library is or where it comes from.

If an organization or a supplier does not have the ability to reliably understand what open source or what code or what packages are in your application or your solution and doesn't have the ability to do that, would you classify them as reliable? So understanding what really matters in this space of a software supply chain is going to be identity.

Does that supplier, that solution provider – even if you do this yourself – does it have the correct, accurate, precise intelligence to be able to identify if the thing that is inside an application that I've built using Claude, for example, is exactly what I think it is? Because it's, again, the old analogy of a cake. If I give you a cake and I give you a recipe to go with the cake, how do you know that that cake actually is based on the recipe?

Yeah, quite so. So we have a couple more questions come in. On this one, I'm going to do very quickly, how do you position Black Duck software composition analysis?

Again, a quick insight into the way that we do lead to companies. We have questionnaires with, I think, a thousand questions on there covering all aspects, all the things we can think an organisation would reasonably ask in an RFP. So the answer is, how would you position Black Duck?

Well, please tell them that we welcome their participation in the next leadership compass. So I think a final question from Robert, who I think we've slightly ignored. I'm going to try and squeeze Robert in. How do the discussed solutions fit in the overall picture of information security? Is there any overview how many types of solutions we should use today to help get safer?

Well, again, I can give you my perspective, and I think you've got the advantage that both of us here on the panel have been in the game a good while. This, as I say, is not our first rodeo.

So, I mean, my perspective is that the information security field is constantly evolving. The fact that we are now looking at software supply chain as a market sector with its own vendor sets, with its own featureless capability sets, and so on, is an indication, I think, that we are maturing. And as we grow, as we learn how to secure different areas, clearly the next thing is going to be, well, where are the attackers shifting their attack vectors to?

And so then this is a constantly – and I can say that somebody's been in this field 30 years or more now – and this is a constantly changing field. It's actually one of the things I find most attractive about it.

So, how many types of solutions very much depends on your organization's risk profile. For example, if you are handling financial information, there are certain regularity imperatives that say this is what you must do. Similar for healthcare, similar for defense, and obviously similar for anything that's considered a critical piece of a national infrastructure.

So, that can be as prosaic as supply lines to fuel stations can become part of critical national infrastructure. So, I think that's – I mean, Mitin, what's your final view on that?

So, yeah, I mean, great question, Robert, so this comes down to like a consolidation question. Consolidation helps when it unifies context.

So, correlating different findings across the SDLC or the software development life cycle so that teams can fix what matters and it doesn't just hurt or it just doesn't appear on the has the ability to reduce the number of decisions or the context switching the individuals in their teams like the developers and the AI coding systems are having to do, then you can reduce the number of vendor logos. Sure, fine, right? But you have to be able to reduce the number of decisions that your developers are making. And that is how you create innovation. That is how you move at speed.

And that is how you scale as a business. I think so. And I think on that note, I think we are at time. I'd like to thank all of you for attending, and I'd like to especially thank our supporter and the guest here, Mitin Zavri.

Mitin, thank you so much for giving us your valuable time today. Thank you. For all of you, this is, you know, a webinar. They will be recording and the slides will be distributed for you if you signed up to the webinar. And please do watch our LinkedIn channel on our company called Analysts there for more webinar announcements of this type. And see for company called Analysts, I've been Jonathan Kerr. Thank you very much.