 Well, what we want to talk about is what is the state of open-source supply chain security, why should we care about it, what are some of the initiatives and tactics and strategies in this space, what should OSPOS do about this, and also what you as an open-source, you know, activist participant should do about this. So with that in mind, I'm going to turn to my panel and ask each of them to introduce themselves and how they got into open-source security and what their interest is in open-source security. I'm going to start to my right with Rao. That's the trick. I look at Andrew and I turn to Rao. Hi. My name is Rao Lakkakula. I'm a senior security engineering director in JPMorgan Chase. So your stuff is security, but I'm going to start with open-source and then move into security because I started in open-source close to 20, 22, 23 years back when I started first working. I started in startups and then basically we looked at open-source as a free way to kind of minimize the cost for the open-source, but eventually I got hooked into it because then the stuff I don't, I need more features or the stuff I need more enhancements rather than going through a big vendor and wait for a year. It's actually easier to just either contribute or work with the maintainers. So that's how I got into it. I helped with the startup to save money too. Then eventually I got into security 15 years back. So obviously it's a good juncture to like apply security into the open-source and that's why I got into open-source security. And I involved with open-source security coalition. We was back in 2019 when GitHub, Microsoft, IBM, few of the guys that we need to start looking into open-source security more holistically and we started that group and that actually group eventually turned into open-source security foundation and giant Linux foundation. So I'm from the beginning of the open-source security foundation, the founding board member and I'm still one of the board members. So to circulate that, I think it's more of a start as a open-source than security and then I had opportunity to combine those two. Jeff. Hello everyone, I'm Jeff Oric and I work for IBM and I've been in and around open-source for over a decade and I see some familiar faces out in the audience. One of the things I became responsible for goes back about seven or eight years ago because IBM has a very rigorous IP risk management function that I was asked to take responsibility for. And as I'm sure many of you know, when you're consuming open-source, there's two risks that primary risks, there's others, but the primary risks are the IP or legal risk. And then what is the code quality and or security of that package, that free software that you would like to consume? And you know, new into that role, I started to realize, well wait a minute, we're doing this centrally from a legal perspective, but who's doing the centralized security quality review? And the answer I got back initially was kind of crickets, which is kind of concerning. But then I realized, well wait a minute, IBM had distributed that responsibility out to the business units because IBM's a big matrix company, IBM's got over 1,800 products and virtually all of them have some level of open-source under the covers. But it did start sleepless nights because when you distribute an important function like that across a large matrix organization, you can get distributed results. And so I started having discussions with colleagues outside of IBM as well as inside of IBM. And that led to my getting involved with the early version of the open SSF back. Just when the pandemic was hitting about three years ago and no one was willing to write a check, it still got off the ground initially because you know, not just IBM, but Y-Pro, JPM, Morgan Chase, Amazon, Microsoft, Google, and many other tech companies were also starting to have the same realization. And it's a problem that's technical debt within the ecosystem. And it's too big for any one organization or company to solve. So that's what got me interested. Yeah, exactly. A lot of our stories are very similar. Andrew, how did you get involved in open-source security? Well, let's see. Andrew Akin, I'm a global head of open-source for Wipro. And let's see, I've been in open-source about 23 years and in security just about the last three years. And I think it was actually one of our account managers at one of our banking clients, not JPMC, who came up and said, our client wants us to develop an open-source cybersecurity strategy. You're the open-source guy. Your team needs to do it. Really, I did not know much about it at all. Obviously, I understand open-source pretty well, but not cybersecurity. And so then my team and I spent a lot of time. We got involved. We did a lot of research. We got engaged in open SSF. And here we are today. And just to tell my story, I'm Nithya Ruff and I had the open-source program office for Amazon. And my story is just like you have been involved in open-source for 20 plus years. And it was actually at Comcast. And I was running the OSPO at Comcast. And we wanted to use the same software composition analysis tools. And we discovered that the security team was already using white source or other tools to do security analysis. And so we started partnering with them. Then we realized that we had an opportunity to pull our security team into open-source initiatives like open SSF. And so we started talking to them about becoming members of open SSF and really worrying about upstream security and not just, you know, when it comes through the door and then screening for it and then thinking about fixing it or, you know, even looking at vulnerability databases and things like that. That was my first kind of introduction that our security team really needed a guide from the open-source program office side. And we needed to collaborate together on tools, on approaches, on, you know, membership, supporting upstream, etc. So that kind of really impressed upon me. Just, I know we've touched upon this briefly in our introductions, but why should we all care about open-source security? What is the state of open-source security today? Is it why? I mean, is it because we are consuming it more? Is it because it's produced all over the world and we need to understand the state of it? Rao, do you want to take a stab at it? Definitely. I think it's actually all of them. I think more software being produced in general and more open-source being consumed in all the software we produced. Something like 80, 90 percent. Yeah, definitely more than 80 percent and somewhere around 90. And also we're seeing it's not just the vulnerabilities in the open-source packages we consume. We're seeing new trends in the industry that there are packages which are to start with being malicious. The intent is to do bad. We're seeing more back as that. And we're also seeing the attacks on the supply chain of those packages. So the last three years actually been really changed the dynamic that we have to worry about this lot seriously now. LA was like there was a known vulnerability. There's a patch. So it's more about it was a more a vulnerability management problem. But this no longer a vulnerability management problem. It become a fundamental software security problem. I think that's the reason we need to understand. And one other thing is like, I mean, most of you guys from a big enterprises, in enterprises, we bring in a lot of packages. It's not handful. You're talking about hundreds and thousands of packages, which has hundreds and hundreds and thousands of dependencies. It's a transitive dependency that is very critical here, because now your supply chain is going all the way back to their dependency, their dependency, their dependency. It's not just the package you consume. So that's why I think it's a lot serious problem. Then it looks from the surface. So you're pulling in a lot more than you think you are. Jeff, what would you think? Well, it's a serious topic. So I just want to quickly just get a kudo for being the IBMer who didn't wear the blazer up here on the very good. Yes. But kidding aside, there are three things that I really wanted to share that fit into this. One is that if you think about the way open sources evolved 10 years ago, again, it was mature. It's 10 years old, and now it's 20 years old. And does this mean that we're now at an inflection point where open source is now vulnerable? The answer is yes, but it's no more vulnerable than proprietary code. Open source is not the problem. Open source is part of the solution. But studies have shown that it doesn't matter whether your code was developed in a highly distributed across the globe manner or behind the firewall in a major organization. It's other things that determine how secure that code is. And if you looked at the average enterprise application that was developed maybe five or six years ago, it maybe had 70, 80 packages under the covers. Today, that number is well over 500. So it's just the sheer knee of the curve growth and the use of open source that we're all taking advantage of that makes it this attractive attack surface. And so that is another reason why IBM really wanted to get involved and help the overall ecosystem in the community because we've seen some examples where people misunderstand what the real problem is. Andrew, how about Wipro and your assessment of the state? So putting a few data points on a couple of the things that Raoul mentioned. So in the last couple of years, software supply and chain attacks have gone up by almost 700%. And MENDIO just came out with a recent study that says they've seen a 315% increase in malicious packages in package managers like NPM and PyPy. And that's the ones that we know of. So this is kind of a plug. I came to cybersecurity late, but very active in open SSF. In fact, Jonathan Meadows and I of Citibank founded the end user working group with an open SSF. You don't have to be an end user to participate. So we'd love participation there. But it's really, and we were just presenting on that a few minutes ago, talking about the difference between end users and vendors and that there is a real distinction in their issues. One client we got engaged with a little over a year ago, they told us they said we think we're using about 400 different open source components, but we know it's probably higher than that. So we came on board and within a couple of days we'd identified 800 and then by the time we were done we'd identified 8,000. And this is a large global bank with a very, very sophisticated CISO department and a very sophisticated DevOps team. And it was two orders of magnitude higher. And that's not unusual. The average enterprise is somewhere between 10 to 20,000 different open source components. And one sonotype did a study recently that said we all know log4j, I'm assuming, right? That's the poster child for what not to do in open source vulnerabilities. So 29% of log4j vulnerabilities, I mean log4j libraries downloaded today are of the unremediated versions today. After all the publicity around log4j, 29%, if you think about that, because it's still a widely used package. So I agree with you. I think the sheer scale of where open source is produced, right? Hundreds and thousands of developers worldwide, different projects with different varying levels of security, awareness and education and inconsistent qualities. So there's no standard in open source around security. And then on the consuming side, as you all said, there's so much consumption across the enterprise and developers across the company using it for really mission critical applications. There's this mismatch between the quality of code that's coming out and the consumption of it and then the ability to track it and deal with it from a patching perspective and then the malicious nature. There's so many moving parts to this problem. What are some of the strategies and tactics that you're seeing in play? What's OpenSSF doing on the producer side, on the consuming side? How should we feel safer today? Are good things happening? What do you think, Rao? I'll start with the backwards idea. Should we feel safer? The sad answer is no. Are we doing good work to work towards that safety? Yes. The last few years, I think OpenSSF is actually driving from up front, but it's also government involved in a right way. And we're seeing a lot of work groups from NIST, CISA started, and they actually open to the public to involve common and land. So there's a lot more industry from public and private sector trying to solve this problem. So we're not alone. So and also we're stronger together. So involving more into those will help. But end of the day, to secure your form, it actually starts from you, right? I think you need to understand what are the software processing in your form, right? Understand where the software is coming in, open source, it could be the vendor software, it could be hardware coming in because pretty much all hardware has software on it. It's considered a software these days, any hardware piece. And understanding actually, how do you monitor those ingestion points? It goes back to good old days of like automobile industry supply chain, right? You try to bring in as few quality components as possible to get work done from a very well reputed suppliers. I think what I think from software that prospect to try to minimize the components you consume and also bring in the quality components, there are ton of tools open SSF actually have scorecards. There's a star rating system provides the hygiene of the package so that it helps you to which package is actually in a good state to bring in. And then the traditional all security defense in depth applies here to right having a good appsec process, vulnerability process, security incident will help. But I think now you had to go a little further on, think more about when you ingest the first package because it's going to stay with you for a long time. Once in the form, it's very hard to take it up. A very good point. Yep. So just to make sure that you're all on your toes and you're thinking about those questions for us in a few minutes, quick show of hands. How many recall or have heard of the book, The Jungle by Upton Sinclair? Oh, good. More than half the group. So I bring that up because if you, you know, I like to use metaphors and history repeats itself. And if you think about the package foods industry in this country about a hundred years ago, you know, before that period, you know, people grew their own basically. And then with the industrial revolution process, foods became a thing. And then when that happened, bad actors started to put sawdust in your pancake mix. And so the government had to step in and start to regulate. And now you go into any grocery store and pick up something off the shelf, you get a fairly specific and detailed list of the ingredients, calories, breakdown, etc. The same applies to what's happening in the software supply chain. And the government starting about two years ago with the executive order on cyber security, clearly sort of put a stake in the ground to call attention to a concept that had been developing for many years prior. And it's this idea of a software bill of materials or SBOM. And I'll just end if you're curious, you can Google IBM policy, SBOM, and you'll find a thought piece on the website that talks about an IBM point of view on the SBOM and what's currently important because it is going to be a major factor. You should be thinking about it. You should be getting your teams to start to get their hands dirty with it, but it's way too early to start passing SBOMs around like trading cards. So I'll reflect on that a little bit. I'm a big, big fan of SBOMs. We need to do more and more and more work there. Not only in making SBOMs more capable, more accurate, there will probably be at some point in time a de facto standard. Today, there are a few different ones, formats. At some point, I would expect the industry to kind of coalesce around one of them. Right now, they can almost be a little bit of a Trojan horse because there's a lot of media and press and there's a lot of outreach being done by OpenSSF and others around SBOMs. The challenge is what we're seeing in some organizations is that the engineering teams are saying before you procure any more software, you must get an SBOM, which is great. That's a great starting point. The problem is procurement is like, okay, they ask a vendor for an SBOM, the vendor provides an SBOM, and they're done. Right. They don't share it. They don't create a database. They don't update it. They don't know how to analyze it. And one of the challenges is one of the changes we've seen in enterprises over the last five years is they are becoming much more open to working with smaller software startups and the new and emerging technology faster than they have been in the past. And one of the challenges there is you have a procurement person ask the salesperson at XYZ startup for an SBOM. He says, sure, he goes back and asks his team, what's an SBOM? And they're like, bill of materials of some kind. They generate it, not sure how, and then they get back to their client. They say, we've got an SBOM. Right. And so you don't know the validity. You don't know how updated the software is. You don't know what attestation exists. So it's really good, but there's a lot more work that we all have to do. I agree. And I feel it just gives you a list of ingredients, and it's not standardized as you said, but it doesn't tell you transitive dependencies, I suppose, or how it was built and how it's configured. And I can't imagine getting, I don't know, a thousand page SBOM list and saying, how do you use it? How do you make use of it? Right? So I love what you said. You have to catch it at the door. Before it comes in, you need to know the scorecard. You need to know the quality of the component coming in, then the SBOM. What else is happening to make sure that the supply chain is secure? Did you have a question on SBOM? Yeah. Okay. Sorry, I saw her raise her hand. Yes, yes. So it's not really an object. It's there's so much opposition because what do we do if they're so important? Like how do we move forward? Yeah. That's a really good question. Absolutely. How do we keep evolving and improving and making them trustworthy? Yeah. I mean, you have to start somewhere and the better way to start is get SBOMs and also use the traditional methods, right? So the most of the forms... That's been verified? Yeah. We have to even trust, even like just give us the SBOM. And we do actually have tooling available to get some insight into the, if it is open source package, we could use package analyzers to understand what the material... If it's a vendor software, a closed software, it's a little bit tricky, but still their binary analysis tools kind of approximate what the contents are, which then you can validate. Well, at least I see these four packages. It's not an SBOM. Can you verify it? So I think that will start the conversation to, oh, actually they have a way to validate it and then we're going to get better at the SBOM. If we don't do that, I think we're never going to really get an accurate way to get SBOMs like at least beneath time. So I think doing a combination will help. And again, it's not the SBOMs. I think even there's a lot of hype on SBOM. And personally, I don't believe SBOMs by itself solve anything, right? You need to actually understand the good analogy I give to folks is if you have a very small application, maybe your SBOM is like a box of candy. But in real life, any size, any enterprise application you take, you're probably not looking at actually, maybe not a bunch of boxes. Actually, you're looking at a candy store. If you look at a candy store, something like Economy Candy Store in New York, right? Like I start being there for 275 years with like hundreds and thousands of the candy. And candy came from all over the world. Some are not even produced anymore. That is exactly the same way. You're going to get SBOMs of the packages, which are no longer managed by anyone that abandoned. What are we going to really do with it? So I think it's a combination of, I think, understanding that gives you actually a transparency on what is in your software. But I think you need to operationalize your need. There's a new standard coming by VEX, vulnerability, exploitability exchange that gives you at least, is this actually transit dependency impacts may or not that cut down some of it. But then you actually have to, I think, start cataloging SBOMs will give you how to prioritize when next log for shell comes up. So it's a matter of, I think, it's not directly useful now, but start collecting will help you in the long run. So it's a starting point. Yeah, the only thing I would add to it very quickly is that there's not going to be any sort of single silver bullet tool that's really going to help you, you know, work your way out of this challenge. And so it kind of is really, truly kind of a, you know, don't panic now, but start your journey, get your organization on alert, because it's kind of an all hands on deck moment, especially if you're an enterprise software provider, if you're on the receiving end, you still need to start to scale up, but it's a bit different. Yeah, and something you mentioned, Nithya, I think operating, moving to a zero trust architecture is probably the best approach at this time. What is zero trust architecture? So it's where you look at your entire IT system. We're probably familiar with dual factor authentication, which is one of the elements of a zero trust architecture, right? It's looking at your entire architecture, your entire supply chain, and essentially applying zero trust towards it, right? So there has to be verification at every step in your, or at every process, every action that occurs within your architecture. You start with not trusting anything, right? And then it's, I don't even like saying that, but it's, you know, from a practical perspective, that's one of the design principles we need to be thinking about today. And to what you said about VEX, what I like about VEX is the fact that it actually forces a supplier to, they can't, if they're subscribing to VEX, they can't just provide a list of components to you. They actually have, they have actually had to go into their own bill of materials and they have to understand how they interact. Because you can provide a list of components and they may have vulnerabilities, but if they're reviewed in context of how they're actually interacting, how they're layered, how they integrate, then that provides a lot more, a much richer set of information to the person who's consuming it. That's exactly right. And that's how I feel it's a starting point, just like food labels started with perhaps just a list of ingredients. And now they're so rich with information that one can actually walk away and say, do I want to consume this or not? What's the impact to me? It's a good starting point and we need to see how it plays out. And we are open for questions now. Guy. We're a customer of a company that I shall not name. Came and said, give us your S-bomb. And the engineering team went, huh? Right? We've all been familiar with the story. Where from the business side does this get driven? Right? Because what ended up happening in that particular case is the salesperson said, oh, oh, oh, customer needs an S-bomb. So of course, we dutifully produced the list and then the engineering team forgets about it. And then the next customer comes and says, we need an S-bomb. They're like, oh, yeah, we did that thing way back when. There's no, what drives the institutional desire need to do this? Wanting to stay out of jail. Yes. Yeah. Exactly. And there's a forcing function too with the directive, I believe, as of a certain date companies need to be able to have the muscles and the capacity to produce an S-bomb that's demanded within a certain amount of time. Absolutely. And so in cases that I've seen, like at Amazon, the tooling team that's responsible for the development pipeline is building that capability in so that any team that uses that service to release their products gets that as a benefit or as a service. Humor aside, though, it's a carrot and stick proposition because Uncle Sam is saying, hey, if you want to continue, if you're an enterprise software company today and you want to continue to sell your products and have us purchase them, we are eventually going to be requiring an S-bomb. So start developing your capabilities now. So there's the carrot and then the stick is going to be around future legislation that when I think government officials believe that there's been enough time that that muscle or capabilities started to become more common in the industry, it'll start to become more of a stick proposition if you're not ahead of the curve. Yeah. I consider it's more of a paid forward actually also, right? If a software producer is actually need to produce S-bomb to get a good S-bomb, you need to ask your dependence to even get the S-bomb. And it's a cycle of, right? I think then you realize actually it's my responsibility to give the S-bombs to my consumers. So I think in my case it's actually, I think we all need to think from itself, part of our responsibility is providing S-bombs to our customers. Just like we do with attribution notices when we distribute software, right? I think you, okay, sorry. I don't know who was first. Sorry, David. Thank you. Excellent panel. Really appreciate the insights, but you just brought up the attribution document, Nithya. So that was actually what my question was. Are you working directly with your OSPOs to layer into your S-bombs the attribution information such as licensing and copyright statements because those are not part of the NTIA minimum elements? And I'm curious, or are those disjointed functions in your companies? I love your question. Today I think in most companies it's probably disjointed. And S-bombs don't have nearly enough richness and detail that needs to go into attributions, but I think we should be cooperating and working together to get both functions fulfilled, distribution attribution as well as S-bombs. S-bombs really should get to that kind of richness to be honest with you with regards to license information and release and all of that good stuff. But I would also say that yes, this is a chance for an OSPO to further demonstrate leadership within the organization because when you start to wrap your head around this challenge you start to realize, wow, there's a lot of additional information that I under my management team might benefit from that sort of becomes a large list of hashtag, what do you really want to capture? And then what subset of that are you going to be directed to or encouraged to share? And those two lists could be very different. Yeah. And the fact that those lists could be different is a scary thing because then you're producing two documents that don't agree from the same company. Yes. I would add that I was talking to someone from SPDX group last night, the 3.0 version they're going to release actually have concept of profiles. There's a dedicated profile for licensing elements along with security profile. There's also AI model profile. So I think that actually the newer version of SPDX may actually have one document have everything. But they're not there yet. We should get to one doc. Yes. Yes. So I'd like to explore the idea of the carrots versus the snakes. You know, I definitely, it rings very true. We may, as a company that consumes software from third party vendors, we may ask for S-bombs, but we don't necessarily have something to do with them yet. So there's definitely a mismatch there between the type of information you can request and what you can do with that and then how you act on that later. Kind of just setting up the question here. One of the things that we do when we work with a third party under many circumstances, we want to see evidence that they can produce an S-bomb. I'm working on revising our procurement template to require this from companies who we buy software from. The idea being we're not going to be able to use it now, but at some point in the future we'll be able to. And to the point that, you know, once it comes in the door, it sticks around for a while. Contracts are usually durable for quite some period of time. So you may find a situation where you want to go back and, you know, you may not have the tool today. You may have the tool in the future, but you may need to lean on some language that says this vendor will produce this for us when we ask. Getting to my question, I'm curious what ideas you have for other carrots that we can put in place that will benefit us down the road? Like what can we be seeding today for when everything catches up and we are actually able to act on these? Are you talking about what vendors should supply you along with the S-bomb kind of a reader or other types of tools? Yeah, so maybe not necessarily, you know, vendors and tools and readers and things like that, but it's more what behaviors should we be encouraging in our suppliers that down the road will look back and say, dang, that was a good idea. I think real quick, I'm sorry. Well, I was just going to say one of the I think benefits is that we all collectively need to find a way to make better software to try and have grace with the developers that are toiling on this and also at the same time find a way to realize that if we can start to improve that holistically across the industry by sharing information and cooperating like people do through open source that a rising tide can float all boats and by putting that rigor against your suppliers you're actually making them up their game and it's going to improve the chance that they're going to be a long-term supplier to you as well as a more successful and hopefully profitable going concern. I'd echo what Jeffrey said and I think it's important for us to recognize that we're in a period of education and we have to educate ourselves, we have to get engaged, we have to contribute, we have to make these tools better, but large and consumers or end users also have to be willing to educate their suppliers because you're going to be working with a lot of suppliers and some of them are going to be quite knowledgeable and actually give you an S-bomb with updated information, but you have to help others understand that if they're giving you a piece of software that has log4j in it, there are tools coming down the road that will automatically notify you to which version if it's an unremediated version, but right now you have to help educate your suppliers and why it's important for them to provide that information to you. So I think we're all in this stage of education. Yeah, I agree. I would go further and say expect your suppliers to be actively involved in upstream communities and in making sure we are lifting the quality of upstream through opportunities like the Alpha Omega project or scorecards or other things. I think we all need to be holding each other accountable and raising the bar for all of us. I think there's one question at the back and then we'll come back here. Thank you. I would agree that. I think OSPOS are a great way to have a structured program office that works with procurement security and other groups across the organization to get S-bombs, but have you seen any intersource initiatives or intersource program offices that are happening now as a pathway to open source security? Yeah, definitely. I think actually JPMC has a very strong intersource community and one of the things actually we've been trying out is start producing S-bombs for our software we create, right? And that's where we could start generating, validating, also look into operation before we start consuming other S-bombs. So treating each other as customers inside the company. That would help I think in the down the road like open up that to the open source packages too. So in a way you are starting program early. I'll quickly add to the previous question I mean it's not just about carrot or stick in my opinion it's more about when we had log for shell attack, right? I'm sure a lot of us actually end up calling when we're saying are you actually impacted? Tell us. And they don't actually have answer directly, right? I say yeah we'll get back to you and then we'll panic like should we block them or are we need to be worried and we wait for the patches and it's a long process. And imagine I think yeah it's a little bit long of in the initially extra work to produce it makes a lot easier for them to like within first day simply say we're not impacted this is S-bombs good on and even we can validate we don't even go to them. We can see what are all the vendors with S-bombs where this package is there right away and we feel good about it they feel good and relationship gets stronger and stronger. So I think it's a win-win for both in my opinion rather because government ask you to do it do it that's a stick approach but in my opinion it's a more of a win-win situation. And to your point on intersource, yes I think some of that's though driven by the size of the organization you're supporting but you know in parallel IBM is having its think week and there's been a lot of announcements about a IBM's next generation approach to AI and Watson X and that's a direct derivative of an intersource initiative that we kicked off several years ago. So it's another way I think it's hard for smaller entities to both have an effective open source OSPO and try and do intersource at the same time but at a certain critical size it's definitely a benefit. I know we are over time but we have one more question. Okay so a lot of open source security work is about preventative measures to prevent these supply chain attacks from happening and my question is around how do you I mean I work in an open source technology center and like it's we find it difficult to incentivize risk management when there's competing priorities with features and like things that and a lot of what you're doing is like we want to do this so we don't get sued like in compliance cases or like to you know work with the federal government like how do you incentivize risk management in open source security when it may be like it's not actively producing revenue? Why do we have to do that it hasn't broken yet? Yeah I would say you know automation building it into the pipeline but even building that is like take cycles and like that's right it does take cycles and it's making it dead easy and and you know with guardrails built in that sort of thing because human nature you're absolutely right is that you know feature priorities and customer issues take over and you cannot do the the good things that you do need to do from a security and compliance perspective so that's that's what that's the approach we're taking is just just build it in and make it easy for them to do the right thing. Eat your vegetables. Eat your vegetables. You know my mother used to do that I did not eat vegetables as a child and she used to just blend it in you know with sambar or rice or whatever and and I could not pick it apart so I would eat it. I learn something new every day. Yes I think considering also it's not just a security problem it's more of a hygiene problem and an easy example right you wait a year and now all of a sudden you have to upgrade from 1.2 to 2.8 or 3.1 for God's sake then it's it's a lot of work you don't know what changed it's a lot of work on the team and also in a panic moment you have to do it security is on your throat to do it versus if you start doing every beginning of the spring I'll just update to whatever is the latest minor version. You're ready you just need to go to the next version when it is ready so I think making that as a part of your hygiene is the only way we can scale. One last comment though if you're not in the security office go to the security office and ask them how they address it because one of the biggest challenges for CISO teams is the comment that hey we did everything right and we still were hacked right and that's that's the question that whenever CISO teams go for budget that they face that oh we'll do everything right we'll still get hacked we'll just wait until we're hacked and then we'll remediate it right no we don't put all that upfront investment so they've got some great answers to that so if you're not part of the CISO a security team go to them because they can actually help position this. By the way open source program officers can learn a lot from the security teams because they're very very good at getting attention and getting investment as rightly they should and we should be partnering more and more with them in in terms of you know making sure the right things are getting invested in. Amen to that because the having tried to use the carrot to motivate transformation within IBM for several years and then moving into the CISO organization and suddenly it's like well gee you know we can issue this edict and you comply or you don't ship your product it focuses the mind. Yeah so thank you so much for thank you to my panel and thank you to all of you for all the brilliant questions asked it is a moving target and we all need to get involved is what I'm hearing and that we should use good old-fashioned supply chain you know discipline and hygiene inspected from the beginning and make sure that we know where we are using it so that we can respond fast and don't look at SPOM as just the government telling us but as a starting point for really discovery building trust etc so thank you everyone and shameless plug tomorrow or tomorrow at two o'clock another session on navigating open source and open standards to try and find the right balance for your OSPO if you're interested. Awesome thank you Nick Chaffer. Thank you. Thank you.