 I love seeing so many familiar faces here. Raise your hand really quick if you were at the open SSF day event yesterday. Yeah. Thank you so much for coming. My heart. All right. Good morning, everyone. My name is Jory Burrisen. I'm a program director at the Linux Foundation, and I get to work with the open SSF, which is an awesome community of security enthusiasts. Thank you, thank you, thank you all for joining us and kicking off this track today. Before we get started with two days of awesome content, I think that we'll really focus on like the how and the what and that sort of thing. We wanted to start with a panel that really dug into the why. So, you know, it's not new that we have security issues in software, that's old news. It's also kind of old news that we have big sort of F5 tornado-like events like log for shell or heart bleed. Those are not uncommon. But what does seem to be kind of new, a new wind, if you will, is the shared interest and the shared focus of investing in security issues. That's really taken a front and center stage as we saw this morning on the keynotes. Also sort of, you know, the number of supply chain attacks, that's definitely increasing a lot in our open source supply chain. So, we wanted to spend a time this morning covering why the companies that are represented up here with me today, JPMorgan Chase, IBM and Wipro, are what they're doing and how they're addressing these very real and serious issues. So I'm going to address some questions to them and allow them an opportunity to introduce themselves and then we'll have some time for Q&A. So thank you again for joining us and let me just get started with Jeff Borek here from IBM. IBM has been deeply, deeply involved in open source for 20 plus years. So that's not new, but obviously the investment and the joining of the open SSF, that sort of thing, is new. Why is IBM investing here now? Great. Well, Jory, thanks. Happy to be here with my co-panelists and thanks for hosting this. IBM is investing in this because I need to get a good night's sleep. While kidding aside, I've been proud to be participating in a couple of different ways in open source for over a decade at IBM. And it's been something that when I talk about it, I say I stand on the shoulders of giants because IBM in their early days did a great job of both thoughtfully consuming as well as contributing back to open source in a meaningful way. And part of that consuming was both a risk management from the legal perspective and intellectual property paying respect to the license of the open source package, but also reviewing the quality of that package and investigating it and doing some due diligence. And that persisted up until about 8, 10 years ago and IBM like many entities started to get more comfortable with the open source is part of how we do business and the old classic Linus Torvalds quote of many eyes makes all bugs shallow. And because of that, IBM continued to focus on the legal risk and that's currently today part of my responsibility at IBM is helping to manage that process of reviewing the packages that we're consuming and the licenses and how things on the license landscape are shifting, which you have to pay attention to. But the fact that we weren't, we distributed the responsibility for that security and code review to the various business units. And in doing so, we found inconsistencies. And then I started to have conversations with different colleagues in the industry comparing notes on this and quickly figured out that this is really a systemic problem. It's a problem that's too big for any one company to solve. So I started lobbying passionately for IBM to participate in the open SSF and was really thrilled to see it reboot in the fall and happy to be here again today. Thanks so much, Jeff. Yeah, it's going to take an army to solve this problem, isn't it? Rao, I'm going to go with you next. We kind of can understand why a vendor like IBM cares about this very deeply. They provide a lot of services. But in theory, banks don't distribute software. In theory, banks are not technology companies. But I assume you would maybe in the past have paid a vendor like IBM or Wipro to solve these problems. So you don't have to care about this. Why is JP Morgan Chase getting involved? First of all, thank you, Jory. My name is Rao La Calcula. You guys can hear me in the back. So I'm executive director of JP Morgan Chase. I run teams focusing on building automated systems which will make the developer platforms secure by default and also have been involved with securing the open source consumed by our developers and also secure the open source we contribute back to the ecosystem is secure. So to your question, Jory, why IBM is not solving all our problems? Jeff, actually, why IBM is not solving our problems? No pressure, Jeff. On serious note, I wish we only use IBM when IBM is the only vendor we ever used. Actually, we don't develop any software in-house and everything is taking care of IBM. I think actually IBM might like that idea. In reality, though, is we do have hundreds of vendors, small start-up vendors to all the big giants like IBM, Microsoft, Google, Vipro, right? We have to deal with all the software coming into those. Moreover, as I mentioned yesterday in panel, we do have more than 50,000 developers in the bank. So it's actually not a bank. It's a gigantic tech company which actually serving the financial institution. That means we have thousands of developers committing code using hundreds and thousands of open source packages. We have a closely half a million open source packages in our internal reports ready to use. So if you think that way, yes. We need to invest to keep our systems running without interruption, without vulnerabilities by investing in the open source ecosystem. Thank you, Rao. Andrew, I want to bring Wipro into the conversation here as well. So Wipro, your team has been really participating a lot lately in the working groups, Eric and Vicky are great additions and just increasing your engagement in open source. But naively, we would think that you'd be able to tell your customers that security is a vendor problem, not yours necessarily as the systems integrator. But I assume that the truth is a lot more nuanced than that. What's Wipro's reason for getting so actively involved in security? Thanks. I will say it is not all IBM's fault. I just wanted to get that out there. It's yours too. No, I didn't say that. So for those of you who may not be familiar with us, we are one of the large global systems integrators. Somewhere around 240,000 employees across the planet. I do lead open source at Wipro. What that actually means is a big part of our role that's relevant for this conversation is our engagement with the communities and foundations. I think we're members and active participants in something like 12 or 13 Linux foundation foundations and dozens of other communities. We probably have conservatively, I can't give exact numbers because we're public, but probably over 30,000 open source developers today across the organization and that's probably very conservative. But why it's important for us, at the end of the day it's trust. That's one of the core pillars. My team is in the office of CTO and that is one of the core pillars of our CTO vision is building trust in our clients. In order to build trust, you have to be able to provide secure systems. With the continued incredible adoption of open source and the running of production systems everywhere across the planet, you can't portray yourself as being a trusted partner to your customers without being involved in this ecosystem. So at the end of the day, that's really the bottom line. And yes, we do have a number of people who are active, but one of our commitments to open SSF that we made during the recent White House meetings is that we believe one of the values that we bring is the ability to train our customers. So we are getting 100 of our cybersecurity team up to the level of train the trainer in open source cybersecurity training best practices and we'll bring that knowledge to our global client base. That's one of the commitments that we're making besides getting involved with SIG Store and Salsa and the different working groups and so on. I'm going to switch to the topic of education since you did bring it up and each of you has sort of referenced the fact that you have thousands and thousands and thousands of developers who either are working on security or need to be trained in security. What can our organizations be doing to help increase security education to encourage our engineers to go out and learn more and get educated? I'll stay with you, Andrew, if you want to answer that. There's some really simple things out there. There are a bunch of very basic programs that are either free or low cost. I mean, start with the LF security training suite. That's one that everybody that is relevant in your teams should go through that. Second is, again, there are other simple courses like Udemy offers a whole bunch of them as to a number of other learning organizations and learning platforms. Just start there. It's not just with your cybersecurity team. We're going to talk about S-bombs, I'm sure, at some point in time during this panel. Help your security team and procurement understand that's not something they need to get medicated against. Help them understand what S-bombs actually are and why they're important. We did an informal survey over the last couple of weeks. We reached out. We got 65 responses from large enterprises, both vendors and users across the globe. It was just what are S-bombs? What are you doing with S-bombs? Are you tracking them and so on? Of those, I think it was 64, 65 responses. Only 12, and this is a self-selecting audience. Only 12 were actually asking for S-bombs. Of those 12, I think it was four or five were actually doing something with them. And then only, I think it was two were actually putting them into a kind of a shared repository of information. And this was an audience that is already involved in this space. So if you extrapolate that across the global, I mean the wider global ecosystem here, something as high profile as S-bombs still has almost no traction. We need to teach people that S-bombs is not a four-letter word. That's what you're saying, yeah. IBM and JP Morgan Chase, you all also are doing a lot in the education space. Do you want to kind of maybe address Raoul and the importance of getting? Yeah, JPMC invests actually a lot on the security education and training over the years. But personally, I do believe it can't really separate security training from other finding our software problem, right? We tried with this mandatory yearly security training, everyone hated it, right? So we gradually moving to more like a reward and gamifying the systems, like make that as a fun event for them teams to learn about access issues, injection attacks. And we cannot give you this gold kind, whoever finds it quicker, that kind of. So making a game if I help. But I think it's the inline training is always the better rather than is separated, right? We always have community groups on best practices for the architecture, scaling, resiliency, why not security is a part of it? I think we had a lot more actually success with embedding security as part of those, it's one of the qualities of your system. And then having that quick shot by training as in your inline processes seems to have worked better rather than a separate two hour training you have to take like once a year. Yeah, that seems to be a theme that we talk a lot about in our best practices working group where we need to make sure that security education is not an afterthought the way so many other types of training are. So let's dive into, go ahead, Jeff. Well, I was just gonna add from an IBM perspective on this. It's one of the areas that IBM's trying to push the boundaries a bit. How many of, I'm just curious, I bet it's gonna be low. How many of the audience have heard of the IBM P-TECH initiative? Only a few. So one of the things that, again, systemic problems, not just in open source, but in the IT industry that we all need to collectively try and raise awareness about. If you think about the traditional computer science degree, there are all sorts of elements of getting a college computer science degree that set up almost insurmountable barriers to individuals that are interested in careers in this space. And one of the ways that IBM tried to rectify that is create this concept of not just blue collar jobs and white collar jobs, but IBM's referred to this as kind of new collar jobs. And created a program called P-TECH where we actually look to reach out to underserved groups to get them interested in careers in technology as a fundamental, right? Now, beyond that, when the White House executive order on cybersecurity was issued back in the early part of last year, IBM's response to that was we committed to create these cybersecurity centers in 20 historically black colleges and universities around North America. And that's currently in flight now. And what we're doing collaboratively with Brian is we're looking to supplement that training that is focused largely on these cyber centers. But again, shift it to the left and leverage some of the content from the Linux Foundation with respect to educating developers on how to do this better and incorporating that into that program. So we're looking to do multiple things to increase the participation, increase diversity and get security to be thought of as more upfront rather than again the, okay, I've finished my project now. What do I need to do to lock it down? So I think Todd had a slide on that earlier and I felt that was tweet worthy. That's a really impressive program, frankly. But to something Rouse said earlier, what we've noticed, something happening with our customers as this whole issue becomes more prevalent, is that all of a sudden people who were managers or directors or VP of DevOps, all of a sudden are now managers, directors and VPs of DevSecOps. And so those three letters are being inserted in their titles. And I've had a chance to actually talk to a few of these folks. And almost none of them have had additional training. They haven't necessarily had significant additional budget to add that capability to their teams. So it's again, it goes back to training. It goes back to we, there are two segments to this whole ecosystem here. One are the vendors, the people who are already engaged. Not necessarily a JP Morgan Chase or others, but if you look at the open SSF community or the open source community in general, it's made up primarily of vendors. We need to make sure that as we build these programs, we're actually addressing the end user consumers. Because those are the ones you're gonna have to change their behaviors more than just about any of the rest of us. So that's just something I wanna get out there and make sure that we're targeting these programs also to the consumers. And that's a great point. And also I love the point on the DevOps to DevSecOps because I've definitely have seen that as well and kind of related is the question of hiring and filling all of these roles now with a renewed focus on security. We've got a lot of job openings and we've got job openings at Open SSF as well. If you wanna head on over to the website, I need to plug that really quick. So hiring has been probably very difficult I imagine for each of you and your organizations. How many roles are we really gonna need to fill when we talk about building that army to secure our open source supply chain? How many roles do we need to fill here to answer? Just on the IBM front, I'm sorry. One million, I would say. One million, sorry. Well, just in that HBCU initiative, IBM committed to training 150,000 just in a three year period. And that's gonna take quite a bit of effort to do. But that's just one example. It's going to take a sea change in the way people think about open source. And the way people think about software supply chains, right? It's just security can no longer be the, I'll get to it at the end of the process. And there's not gonna be one silver bullet that fixes things, right? We haven't got there yet, but we're gonna talk about the four letter word SBOM. SBOM doesn't stand for silver bullet. And one of the things that IBM is trying to get out there is a lot of people that are aware about SBOMs today are thinking about it as a compliance issue. And not necessarily something that's gonna help me or help my customers issue. And the real value of SBOM is not to get out there and publish your SBOM, publish your SBOM. I mean, that eventually is going to be mandated by government agencies around the planet. But well before that happens, I hope everyone's starting to learn about, get educated on and begin to engage the constituents within your own organization. They're all gonna have a say in what happens in trying to produce and then effectively use an SBOM internally thoroughly before it ever sees the light of day. Because you're gonna find out things that may surprise you when you finally assemble that SBOM list of materials. I agree with Jeff, I think it's, in my opinion, it's not just about hiring more security engineers, right? I think it's actually need to be more collaborative approach that everyone has to start contributing, understand that software supply chain security is important. So if actually, if any of the managers are in the room are watching this or you can talk to the manager, even start contributing 10% of every developer time into the open source, open SSF projects, there are a ton of work streams. I think that's the only way we can improve the awareness and start thinking about that from the ground up. I mean, having security engineers definitely help, but I think we can make a bigger change by involving everyone. You both have mentioned collaboration and obviously open SSF is a place to do that collaboration. We have a whole mess of working groups. We dream up new ideas for working groups every day. And your organizations have all been getting very deeply involved and we're working on a mobilization plan to start to address these problems even further. I'm really curious how the activities that you're seeing kind of build out within open SSF mesh with your org's goals and strategies moving forward. Andrew, do you wanna take that? Sure. Well, we're making them mesh, right? Can't always say that they did before these efforts. Now we're making sure that they do mesh with our other open source related initiatives and I think that's really important for all of us. Cuz just on the panel and in the audience, I'm sure they're contributors to hundreds and hundreds of different open source projects and foundations. We've got to take the knowledge that we're all gaining and the collaboration efforts that we're all putting into the open SSF and other related activities. And bringing those across all of our entire open source portfolios, that's a starting point. And so that's, for example, we've got our own open source security lab in Bangalore and we're making sure that we're taking the best practices that we're either building or collaborating on with open SSF and bringing that across our entire ecosystem of projects that we engage with. So we get other people beginning to think about this. Because it's not, as we all know, it's not at all prevalent or common in a variety of open source projects to just think about secure coding best practices and what that means. So there's a lot that we can do outside of our open SSF related activities. I think if you take any big company like JPM, CR, repro, IBM, with thousands of developers, it's like a mini open source ecosystem, right? We have to invest on security education. We need to identify what are the critical components in the company, protecting them, which includes automatically detecting vulnerabilities, manually reviewing them. Here comes the SBOM there too. But it's also like even providing these best practices to all the developers and mechanisms. So if you think all the way the ten plan works, that mobilization plan we had last month actually measures with any other big company already working on those. So I do see that I think the JPMC priorities, like any other big company priorities, usually mesh with and align with what open SSF are trying to do. And I'm super glad and proud to say that JPMC being like big supporter of open SSF from the beginning and premium members. So I think we are seeing that alignment more and more. Yeah, and I'd just like to second that because Alan and I have an extra excuse to be up here, right? It's sort of where the vendors on the panel. But JPMC is a great example of progressive organizations that are adapting the way they engage with open source. Five years ago, JPMC might not have been up on this panel. But they've been one of a number of leaders that have realized that there's more value to be gained in open source than just sitting behind a subscription support or services or systems integration company and passively consuming it. They're still gonna do that, thankfully for us. But at the same time, they're gonna selectively start to put their own engineering talent directly out into projects like this that are strategically important and meaningful for them. So I'm hopeful people have talked about will cloud negatively impact open source and will it cloud washing or no, the cloud strip mining of open source was a thing. And I've been bullish on open source in part because I believe that other leading enterprises are gonna join in what JPMC has been doing. Let me reflect on that. I mean, you have one of the first vertical organizations now a member of the Linux Foundation in Finos, which is the FinTech Open Source Foundation, set up to promote open source and financial services. But we see across the planet, more and more and more end users are contributing back to open source, right? They're not just consumers anymore. But there's also still a high degree of immaturity or naivete within the large enterprise user consumer audience. There is one financial institution in Europe that and obviously not remain nameless, in which they twice a year, they send an email out to the developers they know of and say, would you mind please describing the open source you're using and how you're using it? You could imagine the response rate that they get to that. So it's a voluntary opt in Excel based tracking model, right? For a large financial institution. Now they may be on one end of the spectrum. But you mentioned something about compliance earlier. Let's at least get them to start with compliance and then begin to introduce these other more sophisticated concepts, right? Around what can you do with S-bombs beyond that? Because they are the average enterprise today, particularly in financial services, uses somewhere between 20,000 to 30,000 different open source components at any given time. And that number includes five to six to seven different versions of different open source components. So if you extrapolate that across the globe, it's a lot of open source, a lot of old legacy open source. So let's help these organizations start by getting compliant, because that's something that many of them are willing to start with and then begin introducing these other concepts. I agree, but I would say that they're fortunately motivated, not originally by self-interest, but by that cybersecurity executive order. So it's kind of like they never let a good crisis go to waste in some respects. Yeah, but how many people have actually positively already complied or responded to that executive order? I know of two software institutions that have been reached out to independently by the appropriate federal agency saying we need you to be compliant within the next few quarters. Other than that, there's not a whole lot of investment being made to become compliant to the executive order today. I think one of the things that we are talking a lot about within the open SSF community is that balance between the carrots and the sticks to encourage compliance. And that's an active conversation. It's something we seem to be really diving into as we work on the 10 point plan, which is this mobilization plan that's available on our website. If you'd like to go check it out where we've kind of broken down needs across these 10 work streams. And I'm curious to kind of talk a little bit about how your organizations are like getting involved and where the folks here and folks vendors like yourselves or companies like JPMorgan Chase, where can they be sending developers who want to sort of to get involved in open SSF work streams? Just to clarify, Jeff, I think so JPMC actually had a long history of open source contributions. 20 years back, we have advanced message queuing protocol. MPQ has released two open source and then recently the quorum. But I do agree with that there's a lot more focus on actually contributing back to the ecosystem and security though. Just to clarify that, to your to your question, I think we are definitely interested on SBOM because that's how I think we're going to get more visibility into it. So we are already working with FSSAC, Allen, to understand how financial institutions can work together to kind of start work with our vendors to standardize the SBOM and consumption. We're also super interested in education because I said we've been investing on this for years and learned a lot on it. So yesterday announcement with David Willamette, that's actually great, I would like to actually start collaborating on that one. And then also over the years, we've been spending a lot of time on understanding how do we extract what is in each of the package. So some of the plugins we write to the Maven JavaScript, those actually will align with some of the work stream work we do with the SBOM open source tooling. So I'm happy to collaborate on those from JPMC. I want to, one thing I try and communicate to our younger developers, the ones coming out of university, lurking is not a bad word in software, in open source projects, right? So if you don't feel confident getting involved, which is fine, many or most of us don't when we first start getting involved, just be there, show up at the meetings, follow the Slack channels, do all those kinds of things just to get comfortable. So I really encourage our younger developer community to just start and getting involved at the most basic level. And then it's much, it happens much faster than they expect that all of a sudden they make a comment or they contribute some code or they write a little documentation. And they find it's pretty cool. Now we hire a lot of offshore developers, obviously it's not necessarily in their culture to do that, so that's why we just try and say start by, if you want, just lurk for a few, be on a few calls, be on a few channels, and then begin contributing when you're ready. I think that's one of the most important messages, rather than saying you need to have X number of contributions within the next 90 days. That message doesn't resonate, we've found. Actually, I'll allow what stream meetings are public and available for anyone to join. Yeah, the other thing I would add to that, I was just on a call earlier this morning with an IBM client attacks authority in the EU. And I was really encouraged by that call, and as I was on it I was thinking about this panel because the other element, you've got to get started, you've got to kind of start to lean in, but you also need to start to develop your constituency within the organization, because one group can kind of try and spearhead it, but it's going to take your legal organization within your entity to be up to speed on what's going on here and understand the role that they're going to play. It's going to take your senior leadership to more fully appreciate what's happening in the software supply chain and how it's going to affect their business. It's going to take your software developers and engineers, and it's also going to take your product or service teams to all, and that's just a subset of some of the major groups that need to have a seat at the table as you start to approach this issue. I just want to add one group to what Jeff's saying is procurement. I see procurement as being one of the biggest gates to S-bomb adoption in the future, so you have to get them involved and get them engaged and help them understand why it's important to be requiring that of their suppliers. Can you elaborate on that gatekeeping? What's motivating them to be that? Well, and they're not doing it on purpose. It's just a lack of knowledge. They don't know why they should be asking for S-bombs. They're not told to be asking for S-bombs. They don't share with their suppliers what information they actually want. They don't know how to select a format. So it's just a lack of knowledge. I don't necessarily see them putting up a gate on purpose. It is an interesting dynamic, though, because what you think about is you start to realize, well, wait a minute, I've got to produce an S-bomb? What is that going to take? What am I going to need to do? And then the second light bulb goes on. I need to get S-bombs from all of my vendors. Because, right, well, not just current, but I mean anything, right? Because it's just like you're going to get a lot of pushback from your vendor community initially. They're going to go, what? I've never delivered this before. Do I have to? Is it mandated yet? They won't know, IBM knows what they are, right? Right. Smaller software suppliers, smaller ISPs, startups, they won't even know what it is, much less what needs to be added. So security, obviously, is a full-on team sport. I think we have an awesome team here at the OpenSSF. And we've got just about five more minutes, and I do want to leave room for maybe one or two questions. So my last question to the panelists will be, is there a project or an effort underway at OpenSSF that you would like to sing or highlight for the audience today as a favorite or an unsung hero, as Brian says? I think the OpenCRE project, probably the next we're leading, that one, I really like it. It's actually taking all the regulations, all the standards, into more common format. It makes developers understand what to do, which will meet all these regulations. I think that one, I would like to see more getting popularity. Then, obviously, the S-Bomb work stream, one of the 10 we're coming, like there is actually work, I think we haven't started yet, the work stream to build the OpenSSF tool which automatically generates the S-Bombs for the most common package managers. That would be super helpful for adoption of S-Bombs for vendors. It's so easier to ask a small vendor saying, just use these tools to rather than explaining them what is S-Bomb, what to do. To that, I guess I would add, I'm bullish on Sigstore. It's still early, but it's a project that I think is going to become increasingly important as this starts to mature. Beyond that, the thing I would add, though, is I think we are in a critical inflection point in our own little emerging community in that we started out two years ago, pandemic hit, no real funding, kind of a best efforts basis, and then we've done this reboot now in the fall and we've got great momentum and we had the recent White House meeting. It's time, I think, to take the working groups that we had and the expanded scope of the recent paper and rapidly consolidate that into a new cohesive mission that everyone's on the same page with. I would just use the word refine, similar to consolidate. You said mess at the beginning. She mispronounced variety, I think. Variety, yes. No, I don't think she did at all. It's complicated. I mean, getting new people involved, trying to help them figure out where to get engaged, help them pick the right projects, work streams, and so on. It is complicated, and to your point, Jeff, really need to consolidate the 10 point plan with the current work streams, right? I know there's a new best practices working group last week, and there's a lot of time and energy should go into that. We have to figure out what the knowledge is that we're going to share. We have to get it out there as quickly as we can, not just to help people get up to speed, but to also bring more people into these different activities. I'd also say, six door, we're huge fans. Spend time there, but best practices. So, yeah, good, groves, yeah, yeah. We have maybe two minutes. Are there any questions from the audience or from our virtual attendees? Burning questions for the panelists today? Yes, in the black shirt, back there. I'm sorry, I heard, six door. Let's repeat the question for the virtual attendees. So, the spirit of the question is, how does six door and Aspom really, I think, level up security beyond just being another task for the developer? So, I thought the Salsa framework is something to pay more attention to initially. We'll make sure you're at Salsa level one and moving forward. So, maybe for your organization, Salsa is a more important first step. Then what was the second part? I think it was Aspom. Yeah, Aspom, yeah. Yeah, so, not many people are actually even asking for it today, or have the ability to analyze what's in them by the right people or to compare them with other Aspoms together. So, first thing is in your organization, again, I'm just gonna hit on knowledge. Second, creating a database, right? You can actually share and compare the information between Aspoms. The training people are under how to actually just review them and look at them, right? Because there are lots of organizations that do get Aspoms generated by, say, a Black Duck, the white sorcerer, Fossa, right? Or others, but they don't necessarily do much other than look at it from a compliance perspective. I'll just add that. I think it just makes it easier to do the security task, like six-storey. You don't need to maintain the private case anymore. It does help you with that. So I think in a way, it's not really anything new. It just makes what we need to do a lot easier. So I regret that we are out of time for, I just got the big red stop sign, but I wanna encourage you all to come to OpenSSF, working group meetings, get involved. We have, if you have additional questions for the panelists, either find them here or come on to slack.openSSF.org and ask them in our Slack channel. Yes, Jeff? Well, I just wanna leave you all with one thought and a quick plug. The one topic we really didn't get to and the only way we're really gonna get out of here is through future automation and artificial intelligence because this is a problem at scale and we can't hire enough people to figure our way out of this. And come to my session on Thursday. Nicely done. Thank you all for coming. I hope you have a great rest of your supply chain security con and thanks again to the virtual attendees. Thank you. Thank you.