A Look Into Snyk’s 2024 State of Open Source Report – Predict 2025

Hello everyone and welcome to today's webinar, reducing Fatigue While Keeping Your Software Supply Chain and Secure A look into SNYs 2024 State of the Open Source report. Each year Snyk conducts a survey on the state of open source security gathering trends and insight from peers on securing open source software. Join us for a closer look today at some of the statistics and get insights into things like why over 50% of security teams or failing to meet vulnerability management goals and which way supply chain security practices are still immature, and how overtrust and AI generated code can lead to some pretty serious security concerns.

Hi, I am Richard Sherrard staff product manager here at snyk, and I'll be your presenter today and taking us through this, uh, insight into SNYs 2024 state of open source report. You know, we're going through a high level overview today of each of the sections of the report. I'm going to touch upon a couple of observations from each of the sections.

We'll then cover some key takeaways from that section and some talking points that can, you can use in your conversations. Uh, some overall background. You know, open source software is everywhere.

It helps organizations really build software faster by leveraging the open source community created and managed software that it presides. Um, effective prioritization can leave fixed fatigue. One area will cover will be the concept of security or fixed fatigue, including how it will fit in with, uh, SLAs.

The software supply chain security challenge, open source is a key element in software supply chain security, but it's not the only element. Expanding automation and AI today are playing an increasing important role as well. Just, uh, an overview here of the, the 24 state of open source reports.

You can get it through the websites, through the PDF link as well. And we also have blog posts. Uh, we're going to go through a high, um, we surveyed over 450 technologists across application development and security.

We used many of the same questions we had asked in the 2023 state of open source security and compared the past results to this year's were applicable and we mixed, you know, a number of yes no questions, as well as thank ranking questions. Uh, we published this in December of 2024. We'll run through the four uh, sections of that while covering slowly expansion in the open source security efforts and signs of AppSec exhaustion covering supply chain security, uh, remains immature.

They're gonna look into there. Uh, also looking at continued misplacement of confidence in the security of AI generated code and evidence that of general open source security progress, uh, is progressing. But I'll start with a quick overview of the software supply chain and in particular where the coverage of the questions fit in sny, because we're sny, we, uh, put a, an a lot of emphasis on the developer.

Um, there were questions around generative ai, you know, do you use it? What about, uh, ga uh, AI concerns you? What impact are you seeing from it?

We also, uh, explored the open source ecosystem, how libraries are choose, uh, chosen, how they're chosen, and how often you make sure they're secure. We asked about the SCM checks and things like the CI CDA pipelines and commit and PR checks in your security practice. We also dug in on, you know, folks and what they're doing with SBOs software bill of materials.

We want to see where in the SDLC teams are building in security and what they're doing to make it happen. And let's take a look at those results today. The first section, slowly, uh, slowing expansion into open source security efforts and science of AppSec exhaustion.

There are signs of slowing in the open source security efforts and in the DevSecOps efforts more broadly across many questions about supply chain security. We saw either little change year over year or surprisingly declines in the adoption and usage. Some background and insights into the how the teams work.

Uh, we asked, uh, one of the questions how frequently organizations are releasing code today. Uh, and the code deployment frequency remain fairly consistent with the vast majority of our, uh, orgs shipping at least monthly. But when you look at this in the frequency of security scans, uh, we see that dropped with less than 50% actually auditing daily.

So a shift to the lower test frequency is, uh, is a view that we saw. So let's zoom in that a little bit more in a detailed view of this. We noticed that shift across the board compared to 2023, where the shift from the continuously or daily scanning to moving out to more of a weekly or monthly audits.

With that, this is bad news for zero day vulnerabilities entering into your code base, uh, where they can enter in, uh, in between those frequencies. But for organizations, it's really about finding that balance between frequency of auditing and security testing and possible vulnerabilities entering the organization impact by the software supply chain or open source vulnerabilities coming in. You know, how has your org been impacted in the last year, uh, with these two areas?

And this was really a two-way question. How were you impacted and what did your organization do to try to make things better? If there was a decline in new tooling adoption as well as a, a drop in education, it's clear to see that a large number of organizations are impacted by vulnerabilities.

We saw there, uh, around 50% of organizations either with open source or the software supply chain have been impacted, but we must remain vigilant in the fight. Continued efforts to really educate and train development is a key in our fight against security. We did see a mixed delta in security tool usage this year.

You know, we saw SCA went up a bit, uh, around nearly 70%, uh, but SAS and everything else went down. The question, is this due to the economy or what's going on here? Um, we also saw a decline in license and security scanning.

These are really gaps that can be posed serious risk to an organization. Secrets obviously leaving, you know, it's like leaving your car keys on the seat in your sports car licenses on the other hand may not be as obvious. Knowing which licenses and license types your applications and the dependencies use allows you to be proactively verify whether or not your applications carry on.

Knowing license risks, license compliance is still an important piece of the software. Supply chain dependency analysis was pretty much unchanged from a yes no standpoint, but with a nice shift on where the depend on which dependencies are being tracked. This slight shift in direct versus indirect dependency tracking is encouraging to see as well.

Tracking all your dependencies is key to fully understanding your risk from all angles, so you get a trillion insight into your posture. Overall dependency analysis remain stable. We can see here, um, continuously, uh, testing and analyzing your package managers in an automated fashion is still very popular.

Now when it comes to SLAs and missing vol SLAs, it's very, uh, we see that fairly strong SLAs are in place with organizations having a committed higher or greater severity fixes in under one week. However, when we see, uh, we see signs that meeting these SLAs is challenging though, for organizations with over 50% missing at least sometimes or more often, uh, than that in terms of frequency of missing SLAs, prioritization of vulnerabilities is important here to meeting those SLAs. It's also a sign of vulnerability fixed fatigue creeping in when these SLAs are starting to be missed.

Now, some key takeaways for our first section, you know, hints of AppSec fatigue are showing through, and some actions to take away from here is scan frequency can directly impact your ability to quickly react to zero day vulnerabilities. Yeah, the reporting can help when you're, you know, which package is bad, but you need to know in order to have that. Putting insecurity gates through the SDLC encouraging developers to leverage IDE security checks or testing via s uh, CLI and training is also very important at this stage as well.

Avoid or at least reduce security fatigue by prioritizing your best base on your business critical context applications. AppSec, you know, we need to keep up a good work here, keep up that good work, but don't get discouraged. Look towards your security champions to help you with this.

And educating new security champion, uh, program in place might be worthwhile looking into one and implementing one for your organization. Section two, this section focuses on a bit on lessons learned and the software supply chain trends. Okay, so admittedly this is a fairly broad set of technologies and there's no way to encapsulate a gauge for software supply chain in one question.

This one was meant to be as much thought provoking or, you know, are you doing this since no single vendor out there can really secure your entire software supply chain? If they say they can, they either don't know what that actually means or while they're, you know, lying to you. There are a few themes in this.

Knowing what in the things you're running, making sure that you're right from a trusted source and then making sure that people can change stuff that they're not, uh, cannot change stuff that, uh, they're not supposed to. Just like there's no single vendor angle. You may not need to do everything here, but if you are doing one of these things, you wanna ask you whether what should you be doing instead?

So the SBO parts are a good example of this. You might not need to if you're monitoring everything through an SEA, but again, make sure that it's not a gap also in your organization. Some of the questions start to get into guidelines and specifications like the SLA, which helps organizations make sure that the processes are following good security practices.

Roughly, um, two thirds of respondents are using SEA or SAST static analysis security testing. Unfortunately, we don't know what that overlap is. Also to note that there's also some level of error in these surveys.

These numbers are slightly different than the way the question was phrased, but it's the same ballpark. Just over half of the respondents are scanning IAC, maybe not everyone uses IAC, so that's a valid reason not to use it in your practice. Uh, slightly more are performing vast dynamic application security testing.

Think of this as an automated black box testing that checks your application from the outside, um, for the same types of vulnerabilities that SaaS does. Uh, just side note, you might have heard the s snake's recent acquisition of probably is a DAS and API security testing company. So we'll be adding that to our portfolio as well.

So check that out. There's also a low rate of container testing. I'd really hope to see that, um, closer to the CM level as SEA honestly, and a lot of the CM vulnerabilities that you might find in open source projects still live in your, uh, containers.

Turn across the SED, uh, SDLC. Here we get a good insight into where the companies are sing the security gates across their ides, across their build systems and into their CI CD pipelines. Uh, it's good to see the companies are applying security practices across the SDLC, attacking it from multiple perspectives.

Note that, um, the bars here do go to the right, it's a skill thing. No single one, uh, of these is more than 50%. If you note this is one of those, select all, um, uh, apply all questions.

So I expect that there's, some of these are stacked. The first two that we look into are the bare minimum, uh, around CVSS, severity scoring, uh, and internal scoring systems. With that, it's better than no prioritization method at all, but this can be where a lot of fatigue comes in.

Spending time fixing vulnerabilities that might not even matter. EPSS score and somewhat related exploit maturity start weighing in here and those take into consideration a bit more of the likelihood, which is a nice progression, but we're still looking at static prioritization here. Now reachability is where we start to get more personalized scoring.

It can tell you when there appears to be a call path from your first party code to that particular vulnerability. It's a nice indicator, but it's not, uh, only definitive tell that when there is suffering in the path, it doesn't tell you for certain that there's not suffering in a path. So it's a good metric.

But also, you know, not every vulnerability has that function level details to perform reachability calculations either. And the last one around here is around business context and deployment status. These are really the next gen prioritization tools.

Do you really need to prioritize a vulnerability in the component that isn't even deployed? What if it is deployed but not directly exposed to the internet? Sure, you probably want to fix it, but maybe not fix it first.

So section two takeaways. Um, good trends. Preventing monitoring may help offset the slow tool adoption, but relying on those static prioritization techniques can add fatigue and analysis paralysis.

With that, some actions to take away here is give developers the tools they need to secure your, your AppSec before they check in, like in the ID or three CLA and encourage them to learn how to use them as well as security best practices. Treat external SBOs with the same scrutiny you would with your open source projects. And finally, don't rely on just the traditional or static prioritization techniques.

Look to those smarter fix, uh, advice and they can help you with your prioritization, including a, a more robust risk score, robust as well as those dynamic risk factors as well. Section three, continued misplacement confidence in the security of AI generated code. Three, focus on the impact of automation and developers increasing usage of AI in their coding practices.

We saw pretty similar results to the last year and as this depe, uh, descriptions of the between expectations and reality, and even more folks using AI and more are unsure if they are or not orgs feel or maybe hope the generative AI is helping developers write more secure code. But the stats show that that's not simply the case, even if you drop the very few here in this me, um, question more than half the respondents said that it increased by at least a moderate amount. So this is the first party code, uh, vulnerabilities.

Things like SQL injections, cross-site scripting. Really AI is not, uh, securing as well as you think it is. So it's a concern for risks introduced by j.

Uh, gen AI might be also suggesting codes that requires new open source libraries. And if the libraries for those libraries aren't compatible with your RX policies, there could be an issue. There could also be hidden issues.

What data sets were the backing AI model trained on? If it was trained on code with restrictive licenses, it could generate, might be violating copyrights as well. You just don't know.

And here's the, uh, where I always say with a gen AI is simply, uh, this certainly is taking the place for trust, but verify, make sure you're testing all the code paths, whether it be open source software or gen ai, code generated code section three takeaways, automation and AI risks, opportunities that disconnect between expeditions and real world experiences. Some of the actions to take away here, devs are likely going to be using gen ai. Make sure they know your rules.

If you don't have these rules defined, maybe come up with some guidelines for your development organization, GNA can introduce some efforts of security risks that handle, uh, the risks that handwritten code can, but likely most, uh, much more faster into your organization and really educate your developers on ai, both the pros and the cons. Sns deep, deep code AI doesn't use off the shelf engines, but rather we use multiple AI models that are securely aware. But you also need to think about the s uh, SEA side of it to check the open source as well as the first party code.

And again, educating developers on AI along with general security, uh, practices is really key and important here. Section four, uh, looks at some high level trends and the overall health of open source ecosystem with respect to fixing vulnerabilities across the board. The overall, uh, total time to fix for open source community has dropped for critical or high severity vulnerabilities.

We've seen that across the years, and if we're looking at, you know, open source community is still out. Pieing proprietary code fixes for the total time to fix for highend critical. Uh, we see this across the years from 2019 to today, 2024, where shorter is better and we see that over time that the fixes is getting implemented faster.

So overall, it does look like the open source communities are stepping up, taking more responsibility and responsiveness to the impact vulnerabilities really have on their projects. So some of the takeaways for, uh, section four, the open source community is really becoming even more responsible, uh, responsive and responsible for fixing critical vulnerabilities. And priority teams seem like, uh, they're slowing down a little bit.

Prior prioritization smarter is key here. Open source mat, uh, maintainers are fixing vulnerabilities faster, which means that you can remediate even sooner. Checks for vulnerabilities earlier in the SDLC is key, uh, blocking a merge or using pre-commit checks or grid.

But remedi these vulnerabilities before they even hit the SAM is even better. Take advantage of automa, uh, automated fixed prs here and check everywhere in your SDLC, uh, that you can continuously check your existing projects for new zero days and scan containers before you push and before you deploy. So, report, uh, conclusions.

Now these findings suggest that the industry must find new ways to balance security requirements with team capacity with while maintain vigilance against emerging trends, including those potentially introduced by the over reliance on AI tools without addressing these challenges and adjusting additives towards AI generated code security and organizations risk falling further behind in their security posture as threats continue to evolve. So first step, um, is really assess your approach to the security to prevent burnout and ensure sustainable practices in your organization. Second step is to improve prioritization in your vulnerability management and other software supply chain risk management tasks.

With that, thirdly, prioritize the adoption of fundamental supply chain security measures and deploy newer supply chain security measures to improve your security posture overall. Fourthly, include more holistic risk analysis as part of the SLA determination to ensure security teams can focus more time on the risks that really matter. And fifth, lastly, take a more cautious and measured approach to AI generated code implementing rigorous security reviews rather than ensuring the inherent security of gen AI is important.

And again, education of your development organization is key ongoing practice for your security practice and your security posture. Now that brings us to the end. Uh, don't forget to download your full reports.

You can get it at the available link from that and will be helpful. Uh, happy to enter and a or ask answer any additional questions that you may have on the 2024 state of open source report from sny. Okay, thank you and, uh, have a good day.