Exploring the True Threat of Malicious Code vs. Vulnerabilities
In this episode of Open Source Open Mic, Andrew Garrett and Sonatype Senior Product Manager Dariush Griffin discuss the critical differences between vulnerabilities and malware, including how exploitability, reachability, and malicious code impact software supply chain security. They explore why malware requires immediate response, how teams should prioritize vulnerabilities, and how automation can help developers cut through security noise and focus on the risks that matter most.
Transcript
0:03: So your security tools are screaming about vulnerabilities, and in the headlines, we keep hearing about malware.
0:10: But here's the real question, do you know the difference between the two and which one matters more?
0:16: Let's break it all down today on this episode of Open Source, Open Mic.
0:22: This is Open Source Open Mic, the podcast where we talk about everything happening in the world of open source security.
0:29: So pull up a chair, it's time for an open conversation.
0:35: Hello everyone, and welcome to another episode of Open Source Open Mic, the podcast where we discuss all things in the world of open source security.
0:43: My name is Andrew Garrett, and I'm a product marketing manager here at Sonotype, and I am pleased to be joined today by Dariush Griffin.
0:52: Dariush is a senior product manager over the software composition analysis products at Sonotype, and he is based in Austin, Texas.
1:00: And I'm very glad to have him joining us today on this episode.
1:05: Dariush, is there anything you would like to add about your background before we get started?
1:10: Yeah, thanks, Andrew.
1:11: It's a, it's a pleasure to be here and, yeah, so I've been in this industry now 19 years.
1:15: I've been working specifically in an open source software security now for the last 12 years.
1:21: so I've seen, I've seen quite a bit, I've seen quite a growth, you know, over these last two decades, especially with the rise in AI recently, right?
1:27: It's a real exciting time to be in the industry.
1:30: So yeah, happy to be here to be talking about this topic.
1:33: Absolutely.
1:35: Yeah, well, our topic today is one that I think will be of interest to our listeners.
1:41: It's all about the difference between a vulnerability and exploitability.
1:45: So, let's set the stage, let's just start with the basics and get everybody on the same baseline here.
1:53: First off, what is a vulnerability?
1:56: And then also let's, let's talk about malware as well.
1:59: So what's a vulnerability?
1:59: What is malware?
2:01: Yeah, so I think there's a maybe a common misconception that a vulnerability and malware are the same way or the same thing or they should be treated the same way, but, but they're not actually.
2:10: So a vulnerability.
2:13: Is a bug, you could think of it as like a bug in your actual code or product, right, or in an open source product.
2:20: so a vulnerability might be something like, hey, this application doesn't sanitize its inputs, and so, you know, the information that's sent to the database could be exploited, or, you know, maybe that input isn't sanitized, or maybe there's something that's like deserialized and it's executed, but these are all things that are, you know, problems with the application itself.
2:41: so there's some bug that allows an attacker to exploit the software and, you know, gain access to, you know, restricted data or maybe elevate their permissions, or, you know, do things that are otherwise, they, they shouldn't be allowed to do.
2:57: Malware You can think of more or less like a traditional virus, right?
3:02: Like when you download a trojan off the internet or something, or, you know, you, you get some like spam bot or crypto miner on your machine, like these are all instances of malware.
3:10: So this isn't necessarily a bug in the, the open source code or your application.
3:17: this is literally a virus that is being, included with whatever it is that you are downloading and consuming.
3:25: And so, the way in which these manifest themselves are also distinct, right?
3:31: So, a vulnerability will manifest itself because there is a bug in the code, a developer forgot to sanitize the inputs, they forgot to, you know, check certain parameters, you know, maybe there's a buffer overflow somewhere.
3:44: malware is typically introduced because, You know, someone gains committer credentials or elevated credentials to the actual code base, and then they will essentially hijack the application to Be a virus or to do something malicious.
4:03: So like when that open source gets downloaded and installed on your machine during a build, it'll go reach out and connect to maybe some command center, and then it'll download additional instructions to do certain things.
4:15: So it is literally a virus, you can think of it that way.
4:20: Yeah, and I also like to think about the intent behind the two, a vulnerability, you know, that can be an accident, that can be a, a developer that, you know, they're writing their code, and there's some sort of, mistake, or, or typo or something in the, in the code, that leaves a vulnerability, whereas malware is more of the intent is to actually, Do harm, there's malintent behind the malware, is, is that right?
4:55: Yeah, that's exactly right, and You know, going back to what you said, like, since a vulnerability is typically a bug inside a code or an oversight, maybe you can think of it that way as well.
5:07: they're not inherently problematic.
5:09: in other words, like you can run code with the vulnerability and, and, and be fine, you know, it could still function and do what it's intended to do.
5:17: malware, as you said, the intent is to be malicious.
5:20: It is to do something destructive.
5:22: I am going to hijack your machine.
5:23: I'm gonna, you know, exfiltrate data.
5:25: I'm going to, you know, maybe turn your machine into a crypto miner for me.
5:30: you know, whatever your intent is, it is not to.
5:33: it is now to be a bad actor.
5:36: and, and so yes, you're absolutely right.
5:38: There, there's definitely a difference in intent.
5:41: OK, so, let's talk about vulnerabilities a little bit more, so, like you said, vulnerabilities sometimes, they may exist, but they're not a problem, not a big deal.
5:53: So what is it that happens with vulnerabilities that can actually cause them to become a problem in applications?
6:01: Yeah, so because they are like bugs or oversights in the code or, you know, some unintentional side effects of the code, what will happen is, is you'll typically have attackers that Spend a good amount of time or at least.
6:15: Traditionally it was a good amount of time.
6:17: Now with the rise of AI that that's, it turns out that they're actually becoming a much shorter amount of time where they will, you know, find these bugs and leverage them to gain additional access to things they shouldn't have otherwise had access to and that could be something like a remote code exploit, right?
6:34: So we always talk about like a log for Jay is always a good example or react to Shell, you know, these are.
6:39: These were bugs in in those open source pieces of software that allowed people to remotely execute code on someone else's machine, right?
6:49: that's typically when they become a problem.
6:51: So because you, you were, your applications are depending upon these other open source applications that have these kind of bugs in them, you essentially provide a pathway for, attackers to, you know, leverage those bugs and do things they were not intended to do.
7:07: So like that could be something like bypass permissions.
7:09: So like if, if, if users credit permissions do certain things, maybe they can bypass those permissions, they get admin access.
7:15: And then suddenly, you know, they're, they're exfiltrating data or doing whatever.
7:19: And so that's typically how a vulnerability would manifest into like a, a problem for, for an application.
7:26: It requires It requires an actor to actively attack.
7:34: Your application or to exploit these bugs, and it doesn't just happen on its own.
7:38: So, as we, as I kind of said earlier, right, like you can have vulnerabilities in your code, but if there's no way to access them or exploit them, say it requires network access, for instance, and your application isn't on the network, then you know, it's not as much of a concern, right?
7:52: There's, there's really no issue, but, yeah, Yeah, I, I like your use of the word access, or I, I think you said creating a pathway for malicious users, while you were explaining that, I was thinking about this example of somebody who's inside their house, and maybe they crack open the window, and they let in the breeze during the day, and then they forget to close the window, right?
8:18: And then, At night, somebody's walking by the house, they see the window cracked open, and they think, hey, easy access point, you know, if I want to go in and, and with malicious intent, right, and, and try and steal something, exfiltrate, is the word you used, that's, that's really what we're talking about here with the vulnerabilities, you know.
8:43: leave a window open, but it's, if you leave it open for too long, if you don't remediate that vulnerability, or, or essentially close the window, then you're leaving yourself exposed to potential bad actors, so.
8:59: now, now let's, let's switch gears over to malware now.
9:04: as we said, malware is more intentional, that is where the bad actors are actively going out, it, it's almost like they're walking through the neighborhood looking for windows that are cracked open, right?
9:16: So, let's talk about malware and how does it actually enter the software supply chain.
9:23: Yeah, so most malware typically requires that the committers themselves, Or it requires individuals to essentially gain committer access to projects, so they are hijacking the project and, you know, rather than being the normal committer or maintainer of a project, you now have a third party or initial person who has taken those credentials and inserted new code into the open source project with the intent of doing something malicious.
9:53: so like if you look at the recent attacks like Axios.
9:57: you know, there's someone that gets committer credentials and then suddenly the setup for install script, is, you know, when that, when that package installs, is no longer doing what it normally did.
10:08: Now it is, you know, reaching out, calling out to a command center, downloading additional malware or additional software onto your machine unintentionally, and then executing additional instructions, right?
10:18: Like that.
10:20: the intent behind it is to be malicious, be destructive, and, and they've definitely evolved over the years too, like, you know, back in the day you would have things like typo squatting where you would just take a package and kind of rename it.
10:33: Publish it and then hope someone would, a developer would type in the wrong name and then suddenly they downloaded your package, which, you know, when it was installed would do malicious things.
10:42: you had some of the other early day attacks where they would actually advertise themselves like plug-ins to IDEs and then like when you would install the plug-in on your IDE it would actually begin to do a malicious things, steal your code and all sorts of stuff like that, But, but that's typically how malware enters the supply chain.
11:00: It is, it is someone who is.
11:02: Either gaining privileged access and publishing themselves, passing themselves off underneath a legitimate project after they've made malicious changes to it, and that's typically where they get the most bang for the buck, right?
11:13: Like Axios, I don't know how many times it was downloaded on the exact statistic on me, but, you know, you're looking at like potential hundreds of thousands to millions of downloads of your malware, or they will try in like the early days, like I said, where they would maybe do some type of squatting or, you know, things like that where they're just trying to catch whoever they could catch.
11:31: Yeah, yeah.
11:33: So a lot of times it, it sounds like, it, it just takes a moment of carelessness, like, like you said, downloading something that is maybe, maybe they change one letter in the name of it, and, and, just one moment of carelessness can lead to, you know, catastrophic results, So, how should teams be thinking about risk differently for vulnerabilities versus malware?
12:03: Yeah, this is a good question.
12:04: I think it.
12:05: You know, really speaks to How teams have structured their remediation efforts, right?
12:10: So for malware, let's start with malware because I believe malware is the easiest.
12:13: There's no instance where malware is ever acceptable.
12:18: None.
12:18: Like if you have malware, your machine is infected with the virus.
12:22: That's how you should think about it.
12:23: Your machine is now compromised, you now need to begin the process of damage control, scrubbing it, and, you know, seeing what the blast radius is and like trying to understand what other machines potentially are compromised as well.
12:34: That's how you need to treat malware.
12:35: Like, if you have malware in your systems, the mission is over.
12:38: Like you, you have, you have failed.
12:40: The battle has been lost, you now need to clean up and cut your losses and try and.
12:44: And try and move forward, vulnerabilities are different, as you kind of said, you know, vulnerability requires someone to actively attempt to exploit it like it's just a bug in code, and not every vulnerability is necessarily exploited in every environment, right?
12:57: Like.
12:59: going back to your, to your open window example, I guess, on a residential street, an open window is a potential security risk, but if you have an open window in the middle of like a prison yard, like, you know, maybe it's not so much of a risk if, if there are other gates behind it or in front of it, I should say, right?
13:15: and so that's another factor you have to think about.
13:18: So typically with vulnerabilities, you want to prioritize them, you know, stack rank them based on The likelihood that that vulnerability is going to cause damage in a given application context, and an application context could be the environment that it's installed, how it's installed, how it's utilized.
13:35: There can be many different factors to an applications context.
13:39: Yeah, and let's stay on this example of the open window for just a minute, because I was thinking about, what you said about an an open window on a, on a public street, that, that's gonna be more vulnerable than say, An open window on a, on a house that has, is fully fenced in, that is in a gated neighborhood, that has security guards patrolling the outside, right?
14:09: the, the term that we use in the industry, or, or that we hear a lot is reachability.
14:15: let's talk about what reachability is.
14:17: What does that mean and, and where does it come into play?
14:21: Yeah, so reachability is the practice of analyzing the, you know, the code of the application to determine if there is a path from The applications code to exploitable code in in one of the open source dependencies or really anywhere in the in the code base.
14:37: And the idea here is that, you know, you want to use that information, the fact that there is a code path for your prioritization, right?
14:46: Like you've demonstrated that like, Hey, that route to that window is in fact, you know, there, there is in fact a road to it.
14:52: Like maybe you think you have a fence in place that's totally secure and you have guards patrolling, but maybe there's a gap in the perimeter, the fence isn't fully secured, and there actually is a route from, you know, the outside into that open window, and now you need to deal with it.
15:05: Now, now you should probably close the window, basically.
15:07: That's really what you should do, right?
15:11: And so that's what reachability aims to achieve, I view it mostly as a prioritization tool.
15:20: Because it's not 100% foolproof.
15:23: there are other instances where even if something doesn't necessarily show up as reachable, like maybe there's like reflection or other runtime data flows that can cause code to still be reachable even if most analyzing tools don't, don't list as reachable, so really like.
15:39: You still want to be addressing those higher severity vulnerabilities, like, you know, if your, if your, if your window is pretty wide open, basically, but you can definitely use reachability as a way to prioritize between those various vulnerabilities, right?
15:52: So even if something is a lower severity, or maybe it's not deemed as critical, but there's reachability analysis that shows there's a path from your code to that vulnerable code, like maybe that should be treated as a higher priority than something that might have a higher severity.
16:07: Yeah.
16:10: I, I was just thinking of another, another metaphor.
16:13: I'm full of metaphors today.
16:15: I love it.
16:17: so, I, I'm a big fan of the TV show Breaking Bad.
16:21: I don't know if, if you are as well, Dariush.
16:25: but the, OK, OK, so, so this will, this will resonate with you.
16:29: but there's a scene in, in Breaking Bad, where, we, we have Hank who is the, he's the DEA agent.
16:36: He's in his car and he gets a phone call, and on the call, they say, there are 2 men with guns coming to kill you, right?
16:44: And he starts to panic and he gets really worried.
16:47: Well, What if on that phone call, what if he said they're coming to kill you, but they're in.
16:54: South Africa, right now.
16:56: You know, then he's like, OK, I'm still worried about that, but at least I have some time to, to prepare for this.
17:05: You know, that's kind of what I think about with reachability there, and you brought up the, the, the term of, severity, and there are more, more, there are some vulnerabilities that, That are critical, and they need to be addressed immediately because the reachability is, is very high.
17:25: But there are other vulnerabilities where, maybe they are critical vulnerabilities, but they're not really reachable, that they're not, it's still, still something you need to remediate, but when it comes to prioritization, You want to prioritize the risks that are the most reachable, that's where you should, that's where your attention should go first, is that right?
17:50: Yeah, that's generally where I would start is you want to look at the, the reachability of a vulnerability and then, you know, after that, that, you know, when you look at the different severities of your vulnerabilities, you want to try and, and this is where, you know, having developers.
18:06: Contribute to this process is, is very important, right?
18:09: Because Cause like we said earlier, you know, vulnerabilities are essentially just, you you can think of as bugs and codes or oversight, and so really having the developer come in and and look at how a piece of code is utilized to see like, even if there is no call path.
18:24: How exploitable is this vulnerability given our application context, like, you know, as I said earlier, if an exploit requires there to be network access or elevated permissions.
18:34: You know, how much do you actually care about it, you know, if, if, if the vulnerability doesn't require elevated permissions and like any user can, can access it, then it's like, oh man, this, this could be a bigger deal and so.
18:47: Yeah, I would start first with that reachability if there's there's a path that vulnerability, like definitely that's something you remediate, and then after that you need to start doing your analysis of like, well, what's the likelihood that this, this vulnerability is going to be exploited and that's where that developer input becomes critical, and then you can kind of stack rank, you know, based on that information.
19:05: Yeah.
19:07: So, you know, going, going back to your point about prioritization, you know, this is something that teams struggle with sometimes, and, I mean, we all know security best practices, there are blog posts and articles and, and podcasts like this one, and there's so much good advice out there about how to protect yourself, but then at the same time, You know, every day we check the headlines and we see, we hear about another breach, and So, I guess my, my question to you, Dariush, is, why is it that some teams still struggle to prioritize and distinguish between vulnerabilities and malware, and, and how can we help people know what to dedicate their attention to?
19:58: Yeah, so you know, I think most development teams, so there's a few reasons.
20:02: So one is I think a lot of the tooling out there doesn't properly distinguish between malware and a vulnerability, right?
20:08: So like, Some tooling might label something as a as a as malware, but it'll treat it just like a vulnerability and so developers, if you think about the sheer volume of vulnerabilities that we have today or alerts that they have today or notifications they get today, like it just becomes noise and because you're not treating that piece of malware as A serious infraction as a serious situation.
20:35: like, even a, even a failure or a big alert, like that might not be enough because they've already seen tons of big alerts today.
20:42: Yeah, see, so, you know, one is definitely the, the alert fatigue, but other, I, I would also pin it on the toolings themselves.
20:49: The tooling needs to treat malware as its own class, as it so that.
20:55: Both the developer and the security professionals know this is a different situation that is taking place.
21:00: This is not a traditional vulnerability.
21:01: This is, this is an entirely different situation.
21:03: And if, if I'm seeing this alert, then there's a good chance I'm compromised.
21:06: So yeah, There's also like.
21:12: And I think this is, I think for the most part, the industry understands you can't just look at the raw scoring numbers, right?
21:17: That feeds it back just into what I was saying, right?
21:19: So most malware is going to be at a higher.
21:23: Higher severity level, but, you know, given a choice between 2 10s, a vulnerability and a piece of malware, like I would absolutely be jumping up and down on the malware trying to understand.
21:34: what to do first, compared to just any You know, a a a log for Jade, for instance, a log for Jade is terrible, and react shell is terrible, but like.
21:44: Any, any piece of malware above those, I would have been, I would be acting on that immediately, so.
21:49: Yeah, well, let's leave our viewers with some, some advice today, some best practices, you know, in, in your opinion, what does, a modern approach to managing both vulnerabilities and malware look like?
22:07: Yeah, so, so in both cases, you want to try and prevent, Both malware and vulnerabilities from entering into the the development pipeline.
22:18: If there are known vulnerabilities, like there's no reason why your developers should be choosing components that already have those vulnerabilities, right?
22:25: So, you want to use tooling that will Prevent and assist developers, so like prevent the introduction of vulnerabilities, but also assist them in choosing those components, That are better, either better in terms of quality or better in terms of security disposition or better in terms of their innovation.
22:44: So like, you know, here at Sonotype we obviously have guide, which will help developers choose better components, and we also have things like firewall, which will prevent, you know, those known vulnerable components from even entering into the ecosystems developers aren't even using them to begin with.
22:59: But also you want, you want to have absolute prevention of, of malware throughout your entire network.
23:05: So that includes not just your repositories, but any edge networks, because what we know is we know that developers will oftentimes try and get components outside of the repository, right?
23:15: And, and the thing about malware is that, you know, as we said, it's not a vulnerability.
23:18: Once that malware has been downloaded, you are now compromised.
23:21: It's done, it's over.
23:24: And then any tooling that you do have in place, that is trying to prevent malware, you also want it to help you kind of track what is the blast radius.
23:31: So like, if it does get through the gates, which would be unfortunate, but if it does happen, then you want to know like what is the damage control here, right?
23:39: And so you need tooling, you know, like firewall that can detect malware, you know, within like seconds of it being published, because oftentimes, Especially with like NPM or many of these different ecosystems that automatically kind of upgrade their, their dependencies, you know, it's only a matter of minutes between when malware is published and it's being downloaded by your project and then built on your CICD pipeline and now you have multiple machines that have been infected or, or, compromised.
24:07: And then, you know, in order to keep this all in place and to understand more about that prioritization as well, that I talked about, you need to have a good set of policy and automation, right?
24:14: So like, Policy that takes into context the applications is going to be critical.
24:21: you know, developers have so much, so many alerts and so, so much noise to deal with, that your policies need to be able to take in that application context, understand, you know, how is this application being deployed so they know which vulnerabilities are actually more important for that application.
24:38: you know, if, if you're, if the vulnerability requires there to be like terminal access, like that's, and your, and your, you know, your application has no terminal access or doesn't provide a way for users to get terminal access, then like maybe that's a lower priority vulnerability and something that does, you know, these are all things that need to be taken into account with any kind of modern approach.
24:55: Otherwise you're just gonna find yourself inundated and no one's going to be able to understand the difference between 18 and a different 8.
25:01: And you know how they might apply to Application A versus Application B, and developers are just going to throw up their hands and say like, I don't know, man, there's, there's so much here, like what do you want me to do?
25:10: so you really be able to streamline, that process for them and give them that prioritization so they understand, you know, what items within their application context are the most important to address.
25:21: Yeah, yeah, I'm glad you touched on the automated policies because that's so important, because like you said, developers, they have so much on their plates, and if you can make, if you can automate some of this, so it's one less thing to worry about, it goes such a long way, it's so helpful.
25:41: Well, I'd like to wrap up our episode today by doing something I call the rapid fire round.
25:47: this is where I throw questions at you and you have to answer in 10 words or less, just first thing that pops into your head.
25:52: So here we go.
25:54: Dariush, what is the biggest myth about vulnerabilities?
25:59: And I you said 10 words or less, so I'm gonna stick to 10 words or less, but first I'm just going to say that, you know, I think this is an evolving situation because of the rise of AI.
26:10: so let's see if I can do this in 10 words or less.
26:13: AI will make every vulnerability a concern.
26:20: I get that 7 or 8 words, 7 words.
26:22: Yeah, yeah, well done.
26:25: Yeah, yeah, yeah, that's great.
26:28: OK, next question, what is the biggest misconception about malware?
26:37: Once again, I'm pausing to think through it like if I can get it into words, I'm trying, I'm trying really hard to stick to that, you know, I'll just summarize it and say, you know, you know, malware is, is never safe, and it is always a, priority one situation, Yeah.
26:54: what is one signal teams should prioritize over CVSS?
27:08: I would say it's a combination signal of reachability and exploitability within your application context.
27:13: Hm, OK.
27:16: What is one habit every security team should adopt?
27:24: I would say OK, I'll I'll break this up into 2.
27:31: Development teams need to try and embrace more automated tooling, security teams.
27:39: Also need to embrace that same tooling, but on the flip side.
27:44: the volume of vulnerability is just too high.
27:46: We, we have to, we have to try and use automation to cut through and then automate many of these updates, and many of them can, especially with the rise in AI, but also in a lot of our deterministic tooling as well.
27:58: Yeah, yeah.
28:00: if vulnerabilities were weather, what would they be?
28:06: I would say rain and cause you can have like light rain, you can have heavy rain, and that that's how I kind of think of vulnerabilities.
28:12: It's like some days, yeah, that vulnerability is just like a light rain.
28:14: Other days it's like a, you know, deluge.
28:18: Yeah.
28:20: And then same question for malware.
28:21: If malware were weather, what would it be?
28:24: it's a tsunami.
28:26: Yeah.
28:28: That's great.
28:30: Awesome.
28:31: Well, thanks Dariush.
28:31: This has been great speaking with you today and learning more about vulnerabilities and malware and exploitability and you've left us with some great advice. 28:41: any final thoughts, any, any parting thoughts before we sign off?
28:45: Oh, this has been fantastic.
28:46: Any, any, anytime, happy to chat, Andrew.
28:48: It's great.
28:49: Awesome.
28:50: Well, and to our viewers on YouTube, please remember to subscribe to our Sonotype channel.
28:55: Or if you're listening on Spotify, please subscribe as well.
28:58: And if you have a comment or a question for Dariush, please leave it in the comments below.
29:03: And we'll see you next time on another episode of Open Source Open Mic.
29:06: Thanks.
29:07: See you next time.
Related Resources
Software Dependencies FAQs
What is the difference between a vulnerability and malware?
A vulnerability is a weakness or bug in software that could potentially be exploited, while malware is intentionally malicious code designed to compromise systems, steal data, or disrupt operations.
Why is malware considered more dangerous than a vulnerability?
Malware represents an active compromise because malicious code has already entered the environment. A vulnerability may never be exploited, but malware is intentionally designed to cause harm immediately.
What does exploitability mean in cybersecurity?
What is reachability in software security?
Reachability analysis determines whether vulnerable code can actually be accessed or executed within an application, helping teams prioritize remediation efforts.
How does malicious code enter the software supply chain?
Malicious code can enter through compromised open source packages, stolen maintainer credentials, typosquatting attacks, or infected dependencies downloaded during development.
Why shouldn’t teams prioritize vulnerabilities based only on CVSS scores?
CVSS scores measure severity, but they do not account for application context, reachability, exploitability, or whether the vulnerability can realistically be abused in a specific environment.
What is software composition analysis (SCA)?
Software composition analysis tools help organizations identify vulnerabilities, malicious code, license risks, and outdated dependencies in open source software.
How can automation improve vulnerability management?
Automation helps security and development teams reduce alert fatigue, enforce policies, block risky dependencies, and prioritize the most exploitable threats faster.
What are examples of software supply chain attacks?
Examples include typosquatting attacks, malicious npm packages, compromised open source maintainers, and malware injected into trusted software dependencies.
Why is open source security becoming more important with AI?
AI accelerates software development and vulnerability discovery, increasing both the volume of open source usage and the speed at which attackers can identify exploitable weaknesses.