 Excellent. Thank you, Candace. So yes, I'm excited to spend the next hour or so speaking with everyone and welcoming you to this conversation about addressing cybersecurity challenges and open source software. This comes on the heels of joint collaboration between both sneak and the Linux Foundation of authoring our annual sort of state of open security report. So recently released what we'll be doing is actually going through some of the interesting data that was gathered through that report and sharing some of the common themes discussing those discussing, you know, potentially some of the trends and reasons behind some of the information that that we're seeing. So, without further ado, it's best to probably start with some of the information and insight and details as to what did the report consist of. How was it created what a little bit of the background behind it as I mentioned, it was co-authored behind between the Linux Foundation and one of the authors is joining us on that the call today Steve, as well as information and data specifically from sneak information and some statistics in order to share some insight of what we're seeing in the industry. The research for this report started back in March and as part of that research. In order to build out the surveys and the questions that we wanted to ask of the industry there were multiple interviews 15 different interviews that were performed in conjunction with open source software maintainers cybersecurity experts to make sure that we were in the right questions of the information and data that we wanted to to extract the survey itself launched in just April of this year, and it actually targeted a fairly broad spectrum of individuals so everyone from open source software to core contributors, some occasional contributors, developers of software that actually using and consuming that, and other individuals that were focused on the software supply chain. So, broad spectrum in addition to going across many different industries everything from from small organizations with only small handfuls of developers to, you know, some sample sets of organizations with very large developers. So, the combination of the survey results as well as just information that sneak is able to gather based upon our interaction with a lot of our customers is the information that shared in that report. There were over 550 survey respondents. The interviews we talked about and those actually also spread and we focused on sort of five key language and ecosystems that are shared in the report. So with that said in order to make this a little bit interactive and what we do is what we thought we would do is, is queue up a quick poll. And it's to get a feel for everybody that's on this this meeting to maybe share some of your thoughts as far as when you start looking at open source and software and and the concepts of direct dependencies and indirect dependencies and some of the themes that we saw in the report and that were shared. What is your confidence level as far as understanding your security risks in your direct dependencies right the, the open source components that developers are pulling into your applications, as well as the confidence level in indirect dependencies and so for for some of you that may not as be familiar with with open source software indirect dependencies are the ones when when you pull it in open source package. You can actually have a dependency or use other open source components and those components might use other open source components and so you get this hierarchy right this parent child relationship, and those lower level ones are the indirect dependencies also sometimes referred to as transitive dependency so what is sort of the security risk associated with those and your confidence level and understanding if you're aware of those your organization. Interesting aspects that we were able to derive in one of the themes that fell out of the report was the open source security has become basically a greater challenges, but especially as part of the software supply chain and and I think last year it was evident that the software supply chain has become a big focus from a security perspective as we saw greater sort of attacks and different threat vectors. So it looks like we've got the poll results. So this is, it's actually very interesting. So I see direct dependencies 15%, somewhat, you know, as far as very confident, somewhat confidence, three quarters of you which is actually pretty, pretty confident and then not confident about 11% looking at the audience they're using software composition analysis. Good for Matt. Indirect is very confident we've got 4% somewhat confident at two thirds which is which is pretty awesome and then not confident, but the intriguing part to me was one of these data points that's actually in the software software security was 24% of organizations. So even a little bit higher we're actually had high level of confidence in indirect dependencies but that shrunk to about 18% in indirect so not. If you look at the very confident not too far off in there but maybe even a little higher and probably somewhat in between the mixture of the two so interesting to see some of these poll results. With that said, some of the numbers that were shared in the report and some of the again so these are very intriguing ones when you start to get a lot of the collective data from from across the order across the globe right some of the the information is shared with what organizations are using and one of the things that was shared and set the report from from the data was projects that are using open source software on average have about 49 vulnerabilities and these 49 vulnerabilities and again, on average are spanning about 79 direct dependencies now that that varies significantly across, you know, sort of some of the ecosystems and on the right with what shared here is what those ecosystems represent right how they actually influence the the averages that you're seeing one of the other interesting and this is again more and some of the details in the open source report was that the vulnerabilities themselves on average 40% of those are actually within indirect dependencies meaning they're buried a few layers deep so with this I would definitely love to get, you know, Steve, Matt, especially Steve from an authoring perspective, some of your insight as far as you know, are these numbers surprising. Do you feel like there's an increase in open source usage and any sort of insight as far as we have these vulnerabilities what's what's sort of the difficulty associated with with addressing them and fixing them and things that you're seeing in the industry. One of the first things to say is that 98% of organizations use open source software in some capacity whether it's unrestricted or with certain kinds of conditions. So open source is everywhere realistically from the standpoint of dependencies you know we're transitioning from to an approach for developing software and we have been probably for the last close to maybe five to 10 years, which is very much on microservices. Some modern application development really does rely on smaller components, typically that have dependencies on other components that's just stylistically the most efficient way to build build software this these days. And with lots and lots of open source components out there and being created every day. There's a real advantage to being able to from a time to market perspective, and potentially even quality, depending upon the quality of the components being used a very strong rationale behind using open source and not being overly concerned about the number of dependencies that I would expect the number of dependencies both direct and indirect to rise over time from the standpoint of applications get developed. And I don't think that's a concern because of course we have tools that allow us to look very closely and scan across the portfolio to find out you know where all these dependencies are where particular components being used across the portfolio. Not a concern, but you know once again, you know good governance, you know risk and compliance controls need to be in place. Yeah, I mean I think you know it's it is important as Steve alluded to that this, this model of developing modern applications you know in terms of what we think typically is somewhere like a 80 20% split of hunger and these, you know, pre package modules pre package libraries that have been brought in that's been a tremendous driver for innovation, because it means that people don't have to reinvent the wheel. You know, and it's really enabled people to to speed up tremendously, you know, the software development process with creating much more software. And so there's been a generally a very beneficial thing but you know clearly, you know open source has become somewhat victim of its own success in that that that sort of ubiquity has now made it a target for bad actors you know attacking the supply chain is in many ways probably an easier target than than looking for zero day vulnerabilities in directly in in applications right and you know that's what we've seen as a trend generally in the industry, you know, we see more and more of these things like type of squatting you know directly in the package repositories, I'm trying to trick people into into using alternative things without without people realizing that they were doing so. I think the, the, you know, clearly the, the 79 figure there's the kind of average of averages across ecosystems and we see on the right hand of this slide. There's a lot of variation. You know, I did get asked as a result of this slide should should software developers be looking to stop using JavaScript because it's clearly, you know, more more dangerous than the other ecosystem. But you know, there's things in in this differences fundamental differences within these software ecosystems that will tend to sort of skew these numbers you know JavaScript packages tend to be much smaller in scope. There's a lot more choice available within that ecosystem for things that do have a specific function in comparison to, you know, something like Python where there's a, you tend to have one one package that rises to the top that does all the things for that particular function and what it does say within those package ecosystems is the clearly where you where you have many more dependencies on average in a project in JavaScript, for example, that that makes the scanning and awareness of vulnerability to potential vulnerabilities in the code probably more important for you to consider because you are pulling in pulling in, you know, more more third party packages there. I mean, it's worth saying that, you know, the given that the packages tend to be smaller in scope, you know, this this that you could put an argument together to say well, there's less code there right so you know that it doesn't directly translate into more vulnerabilities being in JavaScript than anything else but it's, it's definitely something to be aware of for developers within those particular ecosystems. And Matt, I'm glad you shared that that sort of ubiquity comment because as we see some of these larger frameworks being shared across organizations, I would agree from a security perspective path of the least resistance is always the most attractive ones from attack perspective it's it's the easiest way in those common grounds and then simultaneously I think I believe this is echoed in the report to we're seeing a growth in just open source packages right this continues to grow and grow and expand which means there's a broad sort of spectrum of what can be used to consume and I think both of those start to bring sort of their own sort of unique implications. Yeah, absolutely I mean you know we have we have the idea that we use inside sneak showing you know in every package ecosystem massive trends of upwards into the right and you know, well I guess we'll touch it a bit more on, on the implications of that idea about more software being created on some of the numbers that we get to later in the deck right. Yep. Absolutely. And that said, one of the other things that was an interesting sort of theme and actually potentially surprising. And I know that was shared inside of the results and some of this directly came from the survey itself is that there is still a lot of organizations that don't have the open source sort of security prioritized. The statistics and the information that was derived from the report. What what you can start to capture and one of the things that was shared was that currently across organizations only about 49% of them at least from the survey respondents seem to have a security policy in place that addresses the open source software and if you look on the left of the hand of your screen here too you'll see that it, it does vary across sort of the organizations and size of the organizations right the dark color they're representing one to 500 employees and then sort of growing as you look at the green and the yellow where it's 500 5000 and 5000 and above. And what we start to see is, you know, how many of those currently have one in place. And then those that explicitly answered no and sort of, I think one of the more surprising ones, you know, you kind of expect that on smaller organizations right newer they're just starting up they're just starting to get programs in place and so building out that is is typically part of an evolution of an organization is is putting a little bit more of those stringent controls the more you grow in order to address the risk. And then probably on the other side is as you look at larger organizations you kind of expected that number to be maybe a little higher maybe a little no lower on the, the no side so curious again from Matt and Steve from from your perspective talking with organizations what what your thoughts on this and then probably a side conversation of what what what you see as an impact of some of these responses rightly, and I know that's a loaded question, but the impact of, you know that the don't address it being about 30% in very very large organizations 27% is shown here. Well, let me, let me comment on this first. So the origin of 49%. Just see on the right side of screen is actually the overall number of organizations in our sample for this particular survey that said that they have a security policy for open source software in place. So 4% overall said they don't have a security policy for open source in place, and we had 17% that said don't know. So, it's okay in this particular question to actually sideline that don't know not sure is. And if we do that the ratio of having an open source software policy in for security versus not having one was six was a 6040 split is dismal as it sounds but I will say there are some very alarming characteristics to what you see in the chart here. The fact that we can have organizations of all sizes have at least 27 at least 27% of them growing to 44% for the small organizations, saying they have no open source software policy in place is actually very. But it's alarming to me, because, as I said earlier, we know that 98% of organizations use open source software, not having a policy in place, the standpoint of how you want to do GRC for open source. It's just infighting in, you know, it's, it's, it's setting the stage for catastrophe, realistically. So, I think to me that's very alarming and from the standpoint of what the impact is not having an open source security policy which you would think would be a relatively risky offshoot of overall security policy means that you really have from an open source standpoint, no way to manage the governance, the risk management and the compliance of what you're doing with with open source software. And as I said, because it's so widely used that's a that's kind of a recipe for disaster. There's a couple of interesting trends that that are that are kind of, you know, that you can that you can view this data through through a lens of right I mean, I think if we if we went back, even even five or so years, I think you would have seen a smaller number of very large organizations with open source security policies, I think in large enterprises, you know, you, you might, you might be on the one hand you could you could argue that that, you know, large enterprises much more resistant to change, and they have a lot more ingrained kind of, you know, legacy applications and all that kind of stuff. But I mean actually we've seen over the last few years, a massive rise in open source program offices within within very large organizations and, you know, typically things like this if you if you've got an open source project office you're going to be all over this because that's what the role of your open source, open source program offices. And I think as well the, you know, whilst, whilst the, you know, we can talk about the no figures when we look at 40% plus of small to medium enterprises having an open source policy, you know, I think that for particularly when we look at the kind of startup world, you know, these, any new entrant these days is in who's who's a tall technology company and you know, we have to make the assumption that most, most people starting businesses at this size are going to be have technology at the heart of what they do. They don't have that legacy there so they're starting they probably have a development and engineering teams who are, you know, used to working with open source they've been doing it their entire careers. And so, and then and their greenfields so then, you know, makes it much easier for them to adopt new technologies and, you know, understanding of how to how to best leverage open source. Yeah, those are, those are both great points and I definitely like the perspective that, you know, an organization that's been in motion had this solution and adoption that probably affected their business fairly quickly versus, you know, some of the agility of it's just common place in the, in the newer ones as the startups to have something in place because it's it's a known entity right you're you're starting with with that so might as well start to tackle it as soon as possible. And the interesting part again is is, as we saw a lot of the, the threats and some of the attacks last, you know, over last year that it's becoming a target. We've, we've discussed this will talk about some of the software supply chain impacts with some of the vulnerabilities on a little bit but it's an interesting area where I think it's, it's by no means going away and definitely growing in sort of presence. One of the other things that I think that was an interesting statistic that was shared in this, this report was for those that do right for those that are actually leveraging open source and for whether or not even there's a security sort of policy in place but what sort of components and approaches are in place in order to look for those risks right to, to maybe proactively identify and understand as, as you're starting to use somebody else's code. So what, what does that what risk does it pose on your organization and can you be proactively aware of any of those and take action, one of the stats that came out. And again, want to want to share and Steve I'm going to let you give some insight into these numbers and what it actually entails and how you see them, but 44% of companies have have some sort of approach with developers or other types of approaches and the source code in order to look for these risks. And then we saw sort of multiple sort of categories in these responses of different types of approaches in order to say, What is that risk, like what, what is that level of trust associated with it and can I identify any of those sort of an a proactive method and so it was interesting to see sort of some of those and which ones are more common across the different different organizations. Yeah, two key points here first, the 44% bar that obviously the tallest one. The response there was we use tools to examine source code, open source source code. And what that represents is sort of a holistic view of, are we using tools and tools could be are typically prompt, typically going to be dedicated open source security tools. Like SCA, stast, DAST, and IAC, well that's not dedicated security but it has a big impact on security. There's not 10 categories overall of these kinds of tools. A lot of these tools are in use today and they're very effective at helping improve your security posture. So, so it's good to see that nearly half of organizations are overall are using tools. Many of the other bars are really interesting because the subset of them essentially say that the community that stands behind the open source component that we are looking to use is vibrant it is responsible it has the right kinds of people and it has some core contributors in it, and the right kinds of cycle times to be to give us confidence that there's a care and feeding of this particular component is ongoing. And this is a component that we can have a level of trust in. So I think those are the two things that kind of jump out at me on this question. And from my perspective what's actually good to see here is that, you know, we're, as well as focusing on the on the code what we're seeing here is at least some level of understanding about what the key kind of metrics of health, you should be in open source projects and, you know, it's not just about about function, you know, when you when you're looking at using and integrating something open source you really want to be looking at, you know, how healthy is that developer community, you know, how often are people committing to it, how wide a developer based as it have, and what's the governance of that project right because, you know, we've seen it recently with some of these ransomware things in the community like the colors and faker incidents where we have a single maintainer projects where the maintainers kind of on rogue and, you know, put in code that potentially can cause problems to to users or in other cases have removed the functionality of the product altogether of the project altogether. And so, you know, these things about, you know, looking at package download stats looking at commit, commit cycles releases, you know, and, and, and, you know, checking what the governance of the project is is, it's good to see that people are recognizing that those are important things as well as just purely focusing on the code and I think we're seeing a evolution as well in the kinds of tools that are available to people to make those kind of judgments, you know, for a long time you might be looking purely at commit histories or you know if you were working GitHub looking at stars and that there's a kind of quite very broad brush metrics in a sense but you know we're starting to see things like with the open SSF scorecards program, you know having ways where we can even programmatically assess whether a you know what the security kind of health of that of that project is overall. Yeah, I think that the one thing it building on both of those that that I think was interesting to me is this, this starts to actually build almost an industry best practice and some of those judgment protocols like looking I mean, check in to see if there's a responsible disclosure policy and an open source package is an interesting sort of approach right and then looking at Matt as you just mentioned the maintainers and that trust sort of mechanism as well as automated solutions to provide that that guidance for you but all of these sort of multiple layers of knowing, you know, is this something that I have confidence in, and can have that trust relationship and there's these are multiple sort of layers of judgment. I mean, I think that that security, the fairly low scoring of the security MD is interesting one because, you know, the security MD is a kind of community sort of standard that's been around for a very long time in open source communities, you know we have kind of best practices of having a number of these files exist in the root of an open source repository things like contributing to MD, which is going to give you information like trips into the project and the security MD is actually a very long standing thing but it's interesting that not many people consider that to be, you know, an important health metric. One of the things that this also suggests and we haven't talked about, yes, our, yet our software bill of materials. That is a very important dimension of solving this particular problem. It was instrumental in helping the Lynch Foundation put a report out on it at the very beginning of this year so check out that report on software bill of materials, if, if you have an interest in that it's very comprehensive work, but with respect to what it is here there's there's three things that a software bill of materials gives you, it gives you a lot of understanding about the existing component. And so there's a very rich metadata. And that is instrumental understanding, you know, who was responsible for it, what is the, what is this all about it's got the source code. Also, so, so it gives you that rich source of understanding about what this component is what it's supposed to do and information about its license information about its vulnerabilities. It has info on what's been what's been fixed. And then by looking at the various, you know, registries, either US focused or worldwide focused you can sort of deduce what hasn't been fixed. So this is, this would be absolutely critical from the standpoint of understanding the knowledge that's having trust in it because this information is non falsifiable and understanding usability, which has to deal with its licensing. So, as bombs are a very important part of the equation here. We didn't spend a lot of time on this particular study but still very important to recognize. Yeah, I definitely see I think we'll see that as a as a theme as we discuss some of these other the other interesting part about this and that kind of building on that that security and db and a prominent approach is also that it illustrates that there's many different vectors and so it can be sort of intimidating and burdensome in order to actually investigate though. I think a little bit of that the themes I think that was derived out of this report about reliance upon other entities in order to help provide some of that guidance which I think is critical. It's also captured here right we can see in some of these stacks about relying upon the community relying upon, you know, vendors and solutions to also help provide some of that guidance because it's, it's, it's definitely, you know, it puts a big burden on individuals in order to try to do this across the board with every single one, especially when we talked about the average being 80, 80 or just direct dependencies within within an application using open source software. I think ultimately at the end of the day where we need to have an automated approach to how to deal with all this information and I think that's within reach at this point. Yeah, I mean in some ways the scorecards stuff plays into that you know that's all about a standardized format that can be read programmatically straight out repository with, you know a whole set of sort of health and security metrics in there that that can be interpreted programmatically. Awesome. Well, let's let's transition and talking to probably one of the more prominent sort of discussions that happened last year, and some take takeaways that I think you know you when you start to look at some of the details and some of the information that that shared as well from from the commercial vulnerability so you know, December last year I think anybody in security was probably very well aware of some of the scrambling associated with trying to identify or immediate a lot of the impact of a very prominent open source package and Matt talking about some of the ubiquity you mentioned before about a very, very common component that very popular and used across the industry all of a sudden had this this this risk exposed and sort of the scrambling in order to actually address those. A couple of sort of intriguing elements that I think that that were shared was. And some of this is again from what was seen is that you know 79% of applications that had this log for shell vulnerability log for Jay had more than once right it was it was actually embedded inside of the application multiple locations. And the other interesting one and this is one of those things that we talked about when you start to look at the complexity of open source and the open source relationships and the hierarchies and one of the reasons Steve like did like you just mentioned that that software bill of materials that I think is is extremely critical is understanding that hierarchy relationship and having it both for reference as well as communication and documentation. This illustrates that you know when we looked at some of the, the data that 60% of instances of, you know, log for Jay vulnerabilities as part of the log for shell sort of exploit was found in indirect dependencies, meaning it was potentially buried several layers deep on another open source package that relied upon it, which meant you had to figure out what the solution was, and probably a slightly different matter so we'd love to get sort of the insight and takes both both from you and Matt and Steve on any sort of impacts that you saw and how you saw organizations actually handling this right what what was some of the approaches for some of these complex sort of problems that they had to deal with. Sorry. Sorry, you start. Now I was just going to say this is this is kind of a almost if you if you wanted to come up with a perfect illustrative example of this whole problem space, you really couldn't have invented one that was that was any better than this right you've got a a logging component in Java incredibly widely used it's basically you know the standard way to do this in in Java. It's in an ecosystem that is, you know, used gigantically inside enterprises, you know, people with huge, huge amounts of internal software business, critical software written in Java, and those kinds of Java applications tend to be, you know, complex multi layered with dependencies, you know, lots of indirect dependencies. So, you know, this was a perfect storm, really, and I mean, you know, it's, it's, you know, having, having a component like that that is used by almost everybody is not necessarily a bad thing and I mean under a lot of circumstances you would have thought you know the kind of Linus's law thing about eyeballs would have would have been, you know, for those of you who aren't old enough to remember this is that, you know, I'll paraphrase a bit because I can't remember Eric Rayman's exact terminology but you know that that all all bugs are shallow and given a large number of eyeballs. But you know this was really just a use case that people hadn't considered when a particular commit was put in this is going back some years. And so, you know, very, very widely, you know, vulnerable, almost everybody in the, in the kind of Java ecosystem, and, you know, kind of difficult unless you've got scanning tools and you've got scanning tooling in place to really be able to scan all of your applications at a, you know, multi nested level. You were going to have a problem. And I mean this is still going on right because there's also a huge exposure to this in the embedded space and you know embedded devices if there were something splashed into hardware is a much, much harder problem to upgrade than than enterprise applications. Yeah, in many ways this is a perfect advertisement for software composition analysis tools, because these tools with some vulnerabilities and identify these tools can go out and tell you where all the instances of that those vulnerabilities are. And once you know where they all are, you know, you can do automated remediation potentially although I certainly are testing. If I was going to go down that path. But that, but here's a great example of how tooling can provide a very effective and scalable way to go find the problems and help you get them, get them remediated in a very, very short order. I think there were fixes available for this very, very quickly once the exploit been out in the wild. And, you know, if you were using SCA tooling you were able to find and fix it very quickly. But I think, you know, what was clear to me when you know with my with my kind of sneak hat on was that it there were a lot of people who didn't have software composition analysis in place, who was suddenly scrambling to find a software composition analysis. We certainly had a very large spike in new users during this during this period. I think I just make one more point here you know which is kind of, you know, again slightly slightly tangential, but you know, because you could argue well we should never have, you know, applications that are ubiquitous because they're always going to be, you know, a point of attack but I think probably if you looked at the, you know, the total cost of development for for every, you know, Java application to have written its own login code versus the cost of remediating long for Shell, you know, you may find that that it's that it's surprising in a very large ecosystem like that, right, because we'd be talking about millions of hours of developer time that that would be required to The Linux Foundation for years has had research going on to understand what the most widely used, you know, so many different categories and identify the top 500. So, this is all being done on purpose so that we know what's widely used provide a much higher level of scrutiny on those highly used components. So that issues like this will be in hopefully far less likely to happen in the future, when we get more more emphasis on security And on SCA tooling, there's a statistic in the report, although not in the slide deck here, 46% of organizations in our sample use SCA tools. So we don't even have a majority using them yet and it was probably why, as Matt said, the scramble for for use of that technology after after I was just going to say, I think that that scramble is probably illustrated by the stat on the right, right, it's, it's one thing when you got a direct dependency it's fixed you simply replace it. It's, it's another thing when you're trying to figure out the hierarchy in a relationship and it's not just something you go to you go sort of, you know, directly upgrade yourself this is also very a situation Matt to your sort of point about being a perfect storm to me also like rolls back to one of the other themes that we saw earlier why the criticality of having some sort of a security policy associated with open source becomes so critical because that starts to dictate the software build materials that starts to dictate, you know, having some sort of solution in place that so that you can not only be proactive of having the ability inspect and find things and take the appropriate action but when situations where you need to be highly reactive, you know, are dictated you've got a plan in place in order to actually execute on those which is, this is exactly what happened here is it was a highly reactive sort of situation and understanding your risk was extremely critical as part of being able to take action in reactive fashion. Yeah, I mean if you're doing this manually would just be impossible I mean you know, there's, especially in an enterprise I mean you've got to have automated systems in place here that are maintaining that that list and that list comes from, you know, scanning of some description when during your software development lifecycle. Excellent. So I think that actually rolls well into I think one of the other common themes that we saw as part of some of the information that was shared was, you know, finding a solution a complex solution for this complex problem, you know there's there's a lot of different approaches across the industry and it was interesting to see some of the data that was shared as far as some of the, the trends that are in the market, both from one, you know, looking at open source itself and then looking at organizations and how they're handling from a, from a first perspective. We have seen a very interesting one and I know there's, there's probably many sort of stories and reasons why a lot of this. This may have happened but you know the time to fix vulnerabilities so if you look back just a few years ago, 2018, you know the average time for open source to actually remediate issues with around 49 days. Next, it's, it's gone up based upon, you know, some of the, the, the, the data that we were able from a state perspective in order to, to share. In addition to that fixing vulnerabilities so the approach to actually solving problems when there's open source involved is actually potentially takes a little longer than, and you know fixing those in the open source takes a lot longer than some of the first party codes that's being used inside of organization so I know, you know, Matt Stevie probably got some insight that that I think is extremely interesting to share as far as the reasons why you believe we're seeing some of these trends like it doesn't feel like it's a good thing, but it doesn't mean it's also bad. Yeah, this is nothing more than this is to be expected this is the sign of the times. The years is quite a long time, especially from the standpoint of how security has evolved, and, and the use and how the use of open source software has a dramatically increased. So, we've got organizations building more software today because it is such a strategic advantage for them. We've got more open source software componentry, you know, coming into the marketplace. We've got greater emphasis on security these days and looking across the lifecycle of that dev to be able to deal with security issues. And there's lots more observability and visibility into vulnerabilities. So I think a lot of this is conspiring to find more information these days relative to what we had at our disposal in the past I'm not surprised to see this number go up. But I think the one thing I would say is that when you look at the profile of vulnerabilities and those that are most critical. Those that are most critical are typically a smaller number, even by language, and they get resolved very quickly. But with all open source components we have many low level vulnerabilities that you don't also need to be resolved, but because they're low level. They're not important they're not going to cause or lead to huge exploits, potentially, then that means those can sit out there for a long time because of resource issues that pretty everybody has. And that's to be expected that the number will increase but it doesn't necessarily indicate that that's about that. Yeah, I mean, you know, looking at looking at the whole of ecosystems in in kind of aggregate is, is, you know, not all projects are created equal either right I mean you know we're a very broad church in the open source community from, you know, huge scale projects like the Linux kernel like Kubernetes where almost everybody on those projects is a is these days is employed by a company to work full time on that project. And you know for every one of those, there is 10 or 100,000 tiny little projects that are being done in someone's spare time. So that when you when you're developing something in your spare time and you're trying to develop new features you're trying to support your user base. You know, there's a limited amount of resource there and I think Steve's perfectly right there that what we're seeing is this sort of low level of vulnerabilities probably more. More towards the low medium type of severity. And that's growing, because, you know, we just haven't got the resources and across a lot of projects for folks to be to be to have time to fix them and also having access to the kind of information to be able to fix them right. I mean, you know, this is this is what the what the one of the open SSF missions is to provide that information to to open source contributors to open source maintainers, you know, to provide tooling and security information at scale to, you know, the to to a wide, a very wide range of open source projects and so hopefully those initiatives as those start kicking will start to see this, this maybe slow down this trend and you know ideally reverse but. Yeah, I would agree and I do like the theme of Billings Foundation of pushing more for community and giving back and getting more individuals involved in these because they think that will have a direct impact on some of these types of changes right there's organizations large sort of open source projects have a lot of resources and a lot of people working on it, the smaller ones and I think one of the statistics was 30% of a lot of open source factors have a single maintainer and some of none. And so when when you're limited all those resources it makes you know the ability to change some of those things a little bit more difficult because it's not always your, your full time job or your first. I mean, this is going to be a two pronged approach here you know this from the end user perspective, you know clearly as we looked at the policy numbers and stuff like that we've still got some way to go in educating end user organizations about how they need to manage their risk in terms of open source, but at the same time, you know we've got to provide resources and and and support to the grassroots community level, so that they can get better at doing better at doing security as well. Excellent. Things that was extracted from some of the data was with some of the approaches that are being used by the industry as far as like, so how they tackle this how do they look for security vulnerabilities and I think and maybe obvious but it's probably one that makes sense and consistent that we see some of those when we look at you know some of the solutions that are being used in the market in order to address discover remediate these types of approaches that SAS static application security testing. We've mentioned SCA software composition analysis right or are some of those unique approaches but then we also see some of additional ones that are in there so interested a little bit on on your feedback as far as you know is this the surprising you know is this lacking or you know some of the other areas and I think one of the other things we haven't talked a lot about is just education to which sort of component of you know how we actually approach this in a more effective manner as well. This is this is a very good sign this particular chart because it shines the bright white on SAS and SCA tools. And those are the really the two most popular tools and have been for a while, when it comes to dealing with security. This particular question doesn't tell us but it does, but we see it elsewhere in the report are that infrastructure is code IAC tools are used quite a bit. The organization is very heavily reliant on it as well to deal with security because the automation and it can provide across the ICD. And more automation means less manual touch points, where you can do things that help expose you to exploits. And then finally, what's not said here is dashed dynamic application security testing tools. So we have web application scanners first testing tools tools that are typically used when an application is in production, not during development. So that's another key category that actually ranks medium high from a standpoint of usage, but hasn't did actually show up in this particular question so I would make the case here that really a combination of SAS, SCA, DAST, and IAC is probably one of your best offenses from a standpoint of being able to be addressed security in a more effective way. Yeah, I mean, I think, you know, it's great. The interesting takeaway for me is, you know, the correlation here between the people actually using security tooling and having a security policy right. So, you know, that correlation and we've seen this in lots of other, in lots of other survey work that we've done at sneak. I mean, I think one of the most important things in this space really is about automation and, you know, embedding security tooling all the way through your software development lifecycle, you know, we have to move to this model of kind of for security and having developers have the responsibility and the tools available to them to fix stuff, you know, in the software development lifecycle. And I think we see this through this right, you know, we're using IDEs, tooling in IDEs, tooling in command lines, tooling in CI. And all these things have a slightly different, certainly different reasoning to use them at that particular point in the STLC but, you know, we did some work last year around the cloud native application security report. And, you know, for organizations with fully automated CI CD pipelines we saw much bigger take up of security tooling because it's easier to integrate when you're automating stuff already. You see a gigantic increase in time to fix. So, you know, these things have a real impact and I think if you're good at that automated deployment piece it becomes much easier to integrate security into it. Yeah, it's an interesting I think it actually it transitions over to one sort of the key takeaways mechs I think this that goes exactly what we're just talking about is the maturity of the ability to address a lot of these security issues is probably directly proportional to the automation associated with it's only what it's going to be the only way you can, you can scale it accordingly and so if we looked at, you know, knowing we're just about to the top of the hour of some of the key takeaways that I think, you know, are derived from from the information that was extracted and shared is there's a few approaches and I think one of these I picked up one of the questions that was queued up in there specifically around, you know, how do you how do you get me rephrase that how do you make sure that things are met and standard security processes and practices are in place especially with with DevOps and I think this aligns directly to that right so some of the key takeaways that I think you can derive from this report is involving developers in order to improve their security knowledge. So and that's a combination of you know, security awareness and training. So providing some of those details and guidance associated with why you're asking them to include that in there provided that opening up the common a little bit and sharing some of the details and insight and I think empowering them in order to actually make the decisions, most effectively and given the guidance on solving those problems can be extremely effective as far as improving your security posture across your organization. So hand in hand with that and what we just discussed right is is leveraging specialized security tools so as seeing sast I don't think you're going anywhere because they do provide some of that that guidance associated with and I think one of the other interesting this is inside the report which I will share the link to or the details associated with here just a second but one of the themes that that I think towards the end of the report that was also shared was a lot of individuals are looking at at vendors in the industry to help provide that guidance they know they can't take that burden on themselves there's a lot of sort of elements of of understanding security postures continuously and monitoring and looking for those risks and as we talked about a lot of those different sort of vectors of inspection in order to identify areas of trust can be very, very, you know, and daunting it if you were looking at doing it yourselves and so relying on outside, you know, industry and vendors and a lot of that that work for them and guidance and help solve those problems. And then kind of that last theme. And this is again we just we just touched on quite a bit was automated automated automated right that the, the only way that you're going to be able to address a lot of these security issues without impacting the speed of innovation is going to be embedding a lot of these types of things as early and often in sort of the development process and empowering sort of all of those members across your organization to make them security individuals make them or allow them to actually have a lot of the interaction and the ability to to make those decisions based upon providing that guidance and details and insight and feedback as early as possible but doing so that it works inside of sort of the approach that they use inside of your organization. So, with that said, here's last thing I'll use just to wrap up is the reports available there's a lot of additional details you can actually see in the screenshot there there's some summarize sort of statistics that we saw that more intelligence tools that I just mentioned is actually shared right there but then there's a lot of other additional insight that I think is extremely useful side of this report that you know downloaded and reading yourselves I think is extremely valuable wanted to think Steve is part of co authoring this report to because I think there's a lot of useful information data with that said I think there was one question. You just picked up on that I just wanted to answer the the other side of that question you'll be there which is, how should we consider the platform and DevOps side of security stuff well, you know, very, very briefly in exactly the same way that you consider your application code right I mean that that that movement, you know, towards removing manual intervention infrastructures code. Most are there among many, many scanners out there in the marketplace for scanning infrastructures code. And, you know, I think we've got this kind of emerging field of cloud security posture management, which is, is the sort of flip side to that of looking at your live environments and testing those live and comparing it back to what you had defining code so I think that's definitely the direction of travel. If you're not there already that's definitely where you should be going in terms of considering your kind of platform side of security just treat treat it like software development runs through CI gets scanned. Yeah, let me let me add something to this. So, adding to the conclusions. Number one, from the standpoint of developers and security professionals was more intelligence in tooling from vendors. And number two was higher level of reliance on best practices, when it came to security policy. And so I think to the to this question, I think best practices could go a long way to helping you understand from the standpoint of a framework for helping me understand where we are currently from the standpoint of best practices and use best practices, and graded or can't say the word but for the standpoint of, you know, things you should do versus versus follow a lifecycle essentially of best practices. Linux foundation has already built these best practices, go to open SSF.org, and look at best practices you'll see a course in there for secure software development. This was written by David Wheeler one of the industry experts in the space. There's about 150 best practices in total. You don't need to kind of try to, you know, eat the elephant one bite, but there's a course of certification, it's all free. And it could give you a great view into not only what you should be doing from an organizational standpoint and relative to what you've already done, but also understand from a perspective of how should we improve our security posture over time. It'll give you a lot of good ideas from a standpoint of what these best practices represent and what they do. So I think highly recommended as a way to help address the problem. Excellent. Thanks, Steve. Appreciate that additional insight. And with that, I know we're right. We're probably actually a little past. So Candice, I will turn it back over to the Linux foundation in order to wrap up. Thank you so much, Mick, Steve and Matt for your time today. And thank you everyone for joining us. As a reminder, this recording will be on the Linux foundation YouTube page later today. We hope you join us for future webinars. Have a wonderful day.