 So, let me just briefly introduce you by name and affiliation, and then I'll allow you each to kind of go and give kind of a deeper kind of kind of intro. But Tracy Reagan from Deploy Hub, Raul Akakula from JP Morgan Chase, and Bob Callaway from Google. All three of them are folks who are deeply, sorry, sorry, involved with OpenSSF, with the governance. Tracy and Raul are both on the OpenSSF governing board, and Bob is the chair of the Technical Advisory Council. So, thought would be kind of interesting to put together kind of a closing panel, again looking at how do we help business understand the impact of what we're doing, how do we help make the case for this kind of internally in our own organizations, and security is one of those things that companies sometimes get a little rivalrous about. We would love our customers to believe that we're more secure than the competition, right, either directly or indirectly yet. Working in OpenSSF kind of is about sharing that as a first-order principle. So why don't we just kind of go down, and I've got a few questions for my panelists to start, but then we'll kind of open it up to broader conversation. So why don't I start with Raul? Could you tell us more about the role you play in JPMC, and kind of what led you to OpenSSF? Yeah. I'm Raul Akakula, the head of product security in JP Morgan Chase. I've been working in startups and technology companies for 20 years. I thought it was fun to work in a bank, so I joined JPMorgan Chase three years back, expecting a bunch of guys wearing suit and running around, and developers in the back working in a dungeon, but actually it's opposite. I'll talk more about it. It's actually a tech shop with a bank face on it, so it's interesting. So with the OpenSSF, I mean, as Brand mentioned, I'm serving on the governing board now. I've been doing that from 2020 from the inception. Before that, I was part of the governing board for the Open Source Security Coalition, which is merged into the OpenSSF. I served on TAC, Bob is serving now, but I was on the TAC last year. So I'm glad you're with OpenSSF, JPMC has been from the beginning a big supporter of OpenSSF and we are a primary member now. Great, thank you. Let's go to Tracy next, Tracy, as representing to some degree the kind of the startup ecosystem in this world of what are otherwise kind of the big monster players in the tech industry, tell us more about Deploy Hub, tell us more also about what kind of led you to participate and join OpenSSF. So my background comes from the build space. I cut my teeth on Wall Street in software development and moved into insurance and finally went to work for Discover Card, Discover Financial. And in all those cases, they always asked for what we now call an S-Bomb. And in 1995, my partner and I created a company called OpenMake Software that really leveraged the build process and locked it down really tight. We sold that to what is now Broadcom and that product has been around now for 27 years, still pays the bills. But now we saw a shift coming with microservices and said how do we reimagine that and how do we start tracking S-Bombs from that perspective when you have lots of S-Bombs and no way to aggregate them up to the application level. So when I saw the OpenSSF start to shine, I was like, oh, they're my peeps. Finally, I could talk to somebody about S-Bombs. And I can't tell you, I literally feel like I've been waiting most of my career to be part of this community because we were on a very, I always used to tell people, we're like a furniture store on the very end of a dead-end street with no lights. Nobody wants to come down there and talk to you about S-Bombs, but now we're talking about it and I couldn't be more excited. Also, it helps to have a White House executive order. It really helps to have a White House executive order is like finally. Right. And Bob, let's go to you. Google's investments in open source security are legion now, kind of well-known, but why is that? I mean, Google's a big contributor to open source in general, but this seems to have risen in importance very recently. Could you tell us just more? I mean, Google has made such a massive commitment to it. Help us understand a bit more deeply kind of your role perhaps in that and Google's priorities. Yeah, sure thing. So I'm Bob with Google, a tech leader manager of Google's open source security team, and our team is 100% focused on working on the same fundamental mission of the open SSF to make upstream more secure. In terms of your specific question as to why, I would point to, I mean, everybody knows what Google is and the role that plays in people's lives. That's given the company a very unique perspective to not only the scale of the challenges that are out there, but also to the breadth of different open source communities and practices that are being adopted. And so at Google, we have the blessing of being able to employ over tens of thousands of people that work upstream every single day. And so it's that richness and that almost community dynamic that gives us the almost informed opinion to say like, look, there is a lot of opportunity to make things a lot better. And so coming back to kind of our corporate rallying cry or motto of do the right thing but do the right thing for the user, when you look at that space and you look at the places where you're working day in and day out, you have that moral obligation in some sense to give back and do better. And so when we saw kind of the formation of the open SSF, we said, you know what, this is a really unique opportunity where we're seeing all of the massive players come together. We need to play a leadership role in that. So for us, the business case behind that is, again, not so much in that, yeah, there's a ton of problems, but if we look at where our customers are going, even if we had a magic wand and cured all of the vulnerabilities and all the issues today, projects are still going to be created tonight that may have issues going forward. So it's about really making sure that we're solving the problem sustainably in the long term. And so we realize that that sustainable approach needs a structural, its own unique structural kind of mission above and beyond just going and trying to clean up everything that exists right now. But isn't somebody between you and Sunder say at some point, like this is costing too much? How do we justify this to shareholders like, no? No, I don't think so at all. I mean, again, it goes back to the breadth of the use cases that we see on a regular basis. It goes to security as the cornerstone of our product and go to market strategy in terms of where we see our differentiation. So there's benefits to us as a corporation that are very clear, but it's also going back to that notion of how do we do right by the customer and do right by the broader user of all of our services. For us to take a leadership role, the business case and the justification is very clear all the way up and down the management chain. Rowe, I'm sure there's somebody between you and Jamie Dimon. Jamie Dimon is your CEO, right? Okay, yeah, there's gotta be somebody. Well, he hates Bitcoin. He was the head of the curve on that, it was really good. There's gotta be somebody between you and him who's pushing back. Who's going, why make this investment? Why jump in? We're consumers of this technology, aren't we? It's actually, I got surprised, I was actually expecting that. But I think part of it is where heavily regulated industry, compliance and security being highly prioritized actually. So most of the business is supportive of the security initiators. So that's what actually made my life easier to support OpenSSF is actually all up to the Lowry Beer, who is our global CEO, and Jamie Dimon, they're fully supportive of OpenSSF. That's great. So, yeah, I mean, do you expect that? But I think probably thanks to regulators, but actually security is concerned that's very important. Yeah, again, it helps to have the White House beating a drum. But there's something that regulated industry is like, especially banks have to follow, which is the NIST cybersecurity framework, right? Does that play a role in justifying this work at all? It does, and also regulators also getting smarter and asking the right questions too, I think it's definitely helping. And obviously, Log4Shell and SolarWinds definitely helps to make the case, right? But I think overall, the trend has been changing. I mean, Log4Shell is a good example. I seen the business execute asking the right questions about earlier, I think few years back, the knee-jerk reaction would be, let's stop using Log4J and let's build something inside, right? But actually now they're asking, hey, let's actually understand more about how do we help the open source community to do better? Where else we could actually understanding the critical software we're using? How do we help them community-wise? So I think the trend is kind of changing and more being transparency, supportive, rather than blaming earlier. For an organization who knows how to price risk to five decimal points, so I imagine some of the better statistics and the metrics that we've talked about to evaluate the trustworthiness of code to be helpful in making that case too, right? Certainly, we do that, right? I mean, as I mentioned earlier, we do actually have 53,000 developers now. You have what? 53,000 developers in JPMorgan Chase, which is actually surprised to me when I joined out, I didn't textbook that number. That was actually 35,000 when I joined three years back. Now we're going to 53,000. So as you can imagine, 53,000 developers developing applications. And most of applications these days have 80 to 90% open source software. That means we're actually using. You're not a bank, you're a software company that deals with other people's money from time to time. Exactly, right? So half a million open source packages are out there for developers to use. So we do actually turn a lot of code, including open source. So we do actually have security controls and automatic mechanism to look for security vulnerabilities. Making sure the right software get into the bank and also continuously looking for vulnerabilities in the process every day, right? So there we do how those mechanisms and that definitely helps. And Tracy, same kind of question to you, but it's obviously at a different scale. Like how do you make the case to customers or even to like your own internal stakeholders about investments you make in stuff that just goes back out and could be easily picked up by your competitors and used to compete against you? So I think that- Is your mic working? The point about being accountable to your customers. I don't think it's working, sorry. We'll just get. Why don't we just get the handheld mic up here? Yep. I'll run and get it quickly. I think the battery went dead because it had a light on and now it doesn't. Yeah, that's just the battery on. The problem with end-of-the-day sessions figures. So I think being accountable to your customers is primary, but we're in the business of doing security. So we're in the business of right now where Deploy Hub tracks. It's a catalog that tracks your supply chain and who's using it. So if we're not doing the right thing, we can't expect our customers to be doing the right thing. So in our world, it's leading by example. That is where we see the reasons why we participate in these kinds of organizations as well as spend a lot of time worrying about vulnerabilities and scanning our own code and eating our own dog food. Well, the three of you are either lead or are lucky enough to work for rather forward-leaning organizations. On this topic though, I imagine there's folks out there working for orgs where you're kind of here on the slide or kind of because you believe in the importance of it. Carving out the time to be able to commit to it might be a bit of a challenge. What's some advice that somebody might offer to them in helping make the case up the management chain to be able to spend more of their time on these topics and engaging with the public community? Like for organizations run by less enlightened individuals. But they always say follow the money, follow the money. I would say, I think for any size company, startups to like a big bank like JPMC, innovation is the key to move forward, right? Innovate faster, like innovate faster, actually open source is the key in my opinion, right? You don't want to reinvent the wheel. So if you think that way, innovation faster, open source is feeding that. And then security is the key to actually enable the technology securely so that we keep the customer trust intact. So I think if you think that way, no one actually is opposite to innovation. Like all the business wanted to is enable the innovation, move faster, deliver value to the customer faster. I think making a case that way, I think makes it easy. So I think we just have to tie that back and educate the business people about how the open source is securely making that innovation go faster. I think the dynamic I would highlight there is it's also about open source gives you an opportunity to learn from peers around what's good and what's bad and being able to take that back to drive that innovation engine. I mean, in my old jobs before this, I often talked to customers and was seeing a trend towards the overall release pipeline and supply chain is really a core part of a company's intellectual property. Not just from a risk perspective and that they need to do it right. It's how they engage with their developers. It's about the cadence upon which they work. And so talking about the learnings that you get from engaging in the community here helps to really serve that core innovation engine or just the core infrastructure there. It helps you personally to help develop your skills and learn from others. It also helps the company really position themselves to attract the best talent and go after the market opportunities that they have. So it's in some sense, you can look at it very short-sighted and say, yeah, there's some security problems and maybe these are projects that we use. But if you actually start to lean into that diversity in a meaningful way, you can actually make your internal systems and your own career pay off dividends in ways that maybe you never thought of before. So it's, I think, about playing the longer game and really appreciating that there's a lot of insight and learnings that come to benefit all of us by engaging in upstream. In the early days of open source, we kept trying to come up with ways to justify companies spending time and money on this. And one of the quotes that helped us came from a son co-founder named Bill Joy who said, most smart people in the world don't work for you. There are more people outside of your own organization who might be helpful to common cause that you might have with them then. You could possibly muster, well, maybe JP Morgan has enough people inside. But my sense is, and tell me if I'm wrong on this, but my sense is that people are realizing now that in the field of cybersecurity, it no longer is enough to just buy great point tools off the shelf and have a bunch of internal controls that there is much more of a, it takes a village kind of thing. There's much greater interdependence even between potentially competitors to try to close some of these issues. Is that, do you guys see that too? Is there an example of that? I mean, if you look at the dependency graph for Kubernetes, it's one of the famous images you're probably gonna see all week long in talks, right? It's a mess, it's an air tribe web of all of these things. And so even if you solve one key point, like, okay, there's still 100 more to go after that, right? So it begs the question, what are the patterns? What are the systemic approaches that we can solve? That we can use as approaches to solve the problem? And in doing so, it's about sampling the community. So I think it's absolutely true. Is that why Google open source Salsa and brought it to the community? Because it started life, if I remember correctly, as Google's internal kind of DevSecOps pipeline tool, right, to manage the risk around the plan. Yeah, it comes from our internal systems running on board, which is kind of the predecessor to Kubernetes, something called BCID. But it was really about, if we don't understand how to apply that within our own infrastructure, that's great. But if you look out there for the broader open recommendations around best practices, how to do this? There really, there were point things here and there, but there really wasn't a single place to actually talk about for verifying the integrity of source all the way through the pipeline to get to prod, what are the best practices? And leaving it in an implementation and tool agnostic way. So just literally saying, what are the right things to ultimately do? And so I think what we've done with Salsa is not only just say what it looks like, but we're actually helping people to answer that in the environments where they really are. So go where the projects are. If they're running on top of GitHub Actions or they're going on top of GitLab or other CI infrastructure. How can they ultimately take where they are today and implement one or more of those best practices and make it actionable? That's where we've seen a lot of the engagement around that community. Not just like, hey, let's all tell people what to do. There's plenty of people up pontificating about what good looks like. Help them get there is really where we're trying to take the Salsa community going forward. But yeah, it does come from our own learnings of building out our own web scale infrastructure on the Google side. Anything else either you want to add on that? Well, I would say when I first saw Salsa and started reading, I realized that we finally started looking at our new door metrics, to be quite honest. I always tell people the door metrics, we can still use them and they're still important, but they may be getting a little bit long on the tooth. And I think Salsa really helps us pivot a bit from that. So if you've not read them and not understand what those basic principles are, I would highly recommend you do that and combine them with your door metrics. So one of the things that's different about OpenSSF compared to other typical Linux Foundation projects is we're not just about writing some code and shipping it, right? Or even lots of different hundreds of pieces of code. We're also about education materials. We're also about specifications like Salsa and tooling to support that. But also we're looking at a number of projects that lend themselves to a little bit more like what Let's Encrypt does, which is another Linux Foundation project. It's very much a service rather than a piece of software that has kind of commoditized the TLS certificate space, right? And there's kind of some active questions in the community about, are there other kinds of information services or other kinds of systems that perhaps started life as something that a company built as a proprietary thing, that it's about time for that to potentially become community managed or community governed? And I don't know if either of you have kind of thoughts on this, but are there services in the cybersecurity space or kind of things that should become public resources the way Let's Encrypt has? And if so, what are some of the things that you think we should be looking at in the open SSF community on that front? Well, again, I come from the, really my head is so into compiling linking code and putting the pieces together. And then from an open source perspective, we've really built this massive Death Star with all these interdependencies. And now we've got to clean it up and sort it out. But if we could talk about AI just for just a minute, there are these foundational models that are starting to come out that's gonna be generating code like Microsoft has co-pilot. I feel like that is something that the open SSF at least should be having a conversation about because what if we have something bad in that, right? And everybody's generating code based off of co-pilot. So and that's not gonna be the only foundational model that's out there. There are a lot of AI companies that are really pushing to build these foundation models and what's in them and who's using them. And as soon as we start consuming them, if we have 53,000 people at JP Morgan alone and as Jamie pointed out, education's important. Bringing in new color workers, I can promise you that they're gonna be using these foundation models to create code. So I'd say that's an area that the open SSF should be looking at, okay. Yeah, two spaces come to mind. One is around the six door project, certainly is maybe the trigger for the question. But looking at how let's encrypt fundamentally disrupted the TLS market, not really of like, hey, we're now gonna give something away for free. But there was this underserved market of people that just said, hey, look, it's too difficult to go get a certificate. And arguably like, okay, it wasn't super difficult to get one. But to keep it up to date and to understand the life cycle of what that looked like, that was daunting. So if you look at what was done there, I think what the six door project has done around code signing certificates, there's a strong analogy to really removing as much of the friction as absolutely possible to A, get a certificate. But then managing the key material that's behind that and removing as much of that friction as possible. Again, not trying to position that that is one model that everybody must use. It is an option and that the six door project aims to be very open and modular to adapt to different folks. Because people, let's be honest, banks are still gonna own HSMs. Companies are still gonna have hardware keys. Those are not going away anytime soon. So I think that's an opportunity though for us to say what are those underserved segments of the open source developer population? And are there better ways that we can reach them? And I think six doors is one example of that. Yeah, six doors is a great example of something that's part software, like just regular open source code. And certainly part service that today is kind of, I don't know, it's under Luke Kynes' desk, the main kind of six door key issue. No, it's in a colo somewhere. It's running in GCP with our world class services. So I think we're good on that front. That being said, I think the other example being the OSV project, right? So you take, hey, we've got vulnerability information from many different vendors out there of different levels of fidelity, depending on what project you're talking about. We said, look, how can we normalize this and define a common schema? To answer very simple questions about I have open source package X. What vulnerabilities exist in that package? And having just this very simple canonical way to answer that question. So within the Open SSF created that. But again, a schema does no good if there's not actually a service behind it to give you that information. So the OSV API that we've launched aggregates all of those different sources that are out there. And from the package managers, from different vulnerability databases, it makes that very easy for folks to consume. And we're now seeing adoption come full circle within Python tooling. So we have now something called PIP audit, which will, at deploy time, run and tell you, hey, wait, is the thing you're about to install, does it have any critical vulnerabilities that you should maybe think twice about before you pull this under your system? So we're starting to see these notions of public good services come out that are either serving segments of the developer population that were perhaps underserved, or answering questions that were just unanswered in the past due to various levels of friction or barriers that may exist for some valid reason. But it's preventing people from getting the information they need to make same decisions at the right time. I think in my opinion, actually, a few years back, the automated tools to detect the vulnerabilities were actually proprietary. Over the years, I think most of them are actually free for public open source practice, that's a great thing. But still, I think the fundamental problem is, we still have turn off tools finding issues. We're still lacking the tools to help the developer and maintainers to fix the issues, right? So I actually would like to see more, I mean, there are some research happen like open rewrite. But I would like to see more of maybe opennesses of taking on that. Programmatically provide the remediation fixes to help the maintainers. I think the biggest challenge there is dealing with false positives. And somebody has proposed, I forget which working group this is within. But I proposed an AI model to try to help weed out the false negatives from reports back from automated scanning tools. I don't know if it's really the right kind of tool for the job, but it's worth at least trying to figure out, can we get better at that? Because that's the main reason open source helpers haven't used these kinds of scanning tools, is there's so much noise that comes out from them that it sometimes feels like it's not worth it. But I think we can change that. I think that if we asked, most people still turn off warnings when they compile their code. And I think accessibility of the information, it becomes problematic as well. Because you think about it, you generate an S-bomb, for example. And it's in a text file sitting somewhere where you generated it. Where is it? Did you version it? And then you've got to map that out to get your vulnerability. So if we're not creating a way to make this easy and developers have enough on their plate, it's really hard to expect them to take advantage of the information if it's not in their face. I mean, I'm guilty of that in so many ways. It's like I don't want to have to go dig for the information. I want it served to me. So I know that we have S-bombs everywhere as one of the projects. And I'm working on that. And I think that that is going to be a primary area to have S-bomb information and the vulnerability information available to everyone and make it easy to find. Not go, where's the build? And I got to go find that. And now where's the vulnerability report? And I need to go find that. It just is hard. There's a lot of pieces and parts in it's heart. I think I mentioned I wasn't a very good programmer. And one of those was I hated all those warnings about my void stars being used as a float in the code. Like, I just didn't want to see that. Well, it was important because memory is really required. Yeah, probably should have paid more attention. Or just use a modern language that is type safe anyway. Well, think about where we really started. It was at least where we started in trying to come up with why we needed a build on it report is because we were trying to solve the question, why does it work on that machine but not on this machine? And if you had a clean build on it all the way down to what the machine looked like, you could do a difference report and clearly see, again, going back to accessibility of the information. How accessible is the information and how can we act on it? Neutrino, so bit flips and memory. So cool. Well, I think we'll have time for one or two questions. And this can really be open-ended about what folks think about the future of OpenSSF or things that we could be doing or things that are going on now that you might know much about. But let me just ask one question before we open it up. What is the most unsung hero in the OpenSSF circus? Like, the project that you guys think should have a whole lot more attention paid to it. Alpha, omega. Alpha, omega, OK, great. Rob? I think OpenCRD, the common requirement one, is actually picking up the specification. I think I'm hoping that we'll pick up really quick. OK? Yeah, I'd go back to OSV. I think it's an amazing tool that answers a very simple question that I think a lot of people have, but it does it in a very elegant way. And I'd love to see more use of it. Mine is we have a repo called Creatively Enough Security Reports that attempts to be an archive of all the third-party code reviews that have been conducted on open-source projects. If I have that right, David, I might have that wrong. I mean, the goal of trying to understand who's been actually looked at by third parties and is there a consistency to the reports? Is it worth trying to create a wikipedia-style kind of archive of this information? I think it'd be a great set of knowledge to have in one place when I'm going out and looking at what's offered to you. Anyways, I'd love to see some more investment in that. OK, with that, why don't we open it up to some questions? Look like Amanda, you had your hand up. So do you want to yell it out? Go for it. So Amanda's question was, and she's from Open UK, by the way, visiting us from London, where you called home. How do we plan to work with other regions of the world and extend it a little bit, as well as other governments to do the same kind of thing we did with the White House? And I'll jump in, but feel free to add to it. So we are already an international project. We've got both corporate members from Europe and from the Asia-Pacific region. And we have contributors. Some of you traveled here from Europe. Some of you traveled here from Australia. I don't believe, and some of you traveled here from Japan, or from Cybertrust, wherever you are. And oh, great. And we do tend to, though, have an unfortunate reliance, in my opinion, on Zoom calls as the fundamental communications bus for the community, which has some great upsides. I've loved seeing y'all's face on Zoom calls over the pandemic. But it does make it hard for those in timezones that aren't kind of US centric to participate. And so one of the things I'd like to see, and I don't want to push this too hard because I want people to be productive and not haggled, but I'd love to see us use email more or use other asynchronous collaboration tools as the most baseline level of form for collaboration. I see our friend Caleb nodding his head vigorously over there. He's from Australia as well, where most of our calls happen at 2 in the morning. So I can see why he agrees. The second part of that question was working with other governments. So as I mentioned, nothing in the mobilization plan or the meeting we had was US government specific. We simply wanted to make sure that our friends in government knew what we were doing and that opportunistically we could find ways to collaborate on one or more of the mobilization streams. We've had interest from folks in Japan, from folks in Singapore. We'd like to, we're working to figure out how to do something similar in the UK. The European Union has put a whole lot of priority on kind of open source software as a policy first kind of thing, which is great to see. And that kind of convening where you bring together folks from different parts of government, folks from local businesses to talk about the challenges with securing the open source community, but also the opportunities is a very repeatable kind of format. And I would hope that it would help us in the long term fill the gap between the 30 million in pledges we've raised in the 150 for the overall plan. But even if all we do is go there and find new allies, it's worth me getting on a plane. So no plan more specific than respond to all the emails so far, but we've got a few meetings in flight that we'll be as public about as soon as we can. I'd like to add to that. So I'm the community manager for open source project called Artilius. It's incubating at the Continuous Delivery Foundation. And we had requests for people out of Australia and New Zealand to somehow incorporate them into the discussion. So what we ended up doing was we have sort of an offshoot of our architecture meetings that we do specifically in their time zone. It does require some additional work, but boy, is it beneficial. Really, really is super beneficial. So if you're on an open source project, I would say find a partner in that region and let them take a project and run with it and kind of build their little offshoot of the open source project. It is a huge way to go. The other thing that we're doing to try to solve this is I'm not a fan of Slack or Discord for tracking these kinds of conversations. So I've reached out to the DevOps Institute. They have something called DevOps in the Wild where it's actually a community discussion board. And we're asking if we can have an Ortelius discussion board out there so you actually have historical record. It's almost like a stack overflow for the Ortelius discussions. So those are some ways that we're trying to address the problem. I feel very old suggesting we use email because I know all the kids want to do PRs by TikTok these days. But... What is there actually? RFC! Oh, okay. RFC. Use net! Go for it. All right, but yeah, I think... And actually another example of this that I forgot to mention. So one of the regions that open source communities often have the hardest time trying to reach is China. Because you have the time zone difference, the language difference and the firewall differences that make using tools like GitHub and Slack and others just a non-starter. So one thing that we've set up within the best practices working group and I've got a charter I'll be delivering for this group very soon and some names specific is a group that will be serve as a bridge between a development community inside of China, Chinese developers, focused on helping translate and eventually contribute back upstream to the guides and the other work products of the best practices. The best practices working group. And if that model works well, we see replicating it potentially for other countries where the language barrier can be substantial as well like Japan or South Korea for time countries where time zones are issues like India. There's a request for Africa as well. Another great one for sure, the Middle East as well. And then potentially with other working groups as well. We didn't wanna try to boil the ocean by doing an openness of wide one just yet. But I think that's key meeting them where they are so they can use the tools they're most comfortable with. WeChat for example, and they've got their own zoom equivalent and the like. So I think that's key to reaching local audiences. Anything else folks wanna? To add, I think as Brand mentioned, all the work streams are actually works globally, right? There's nothing specific to US. Obviously US executive order is helping to mobilize some of them, but projects are actually globally. I would like to see actually the regional leaders actually step up and maybe have the local chapters. And maybe you can have regional open SSF days in future in Europe and AIPAC. Well Arnaud was with me on Arnaud Lior's from IBM was with me on Hyperledger where we build a network of over a hundred different local meetup communities city by city around the world who would host regular kind of gatherings and that kind of weather during the pandemic. But I think we're at the point now where those kinds of things are happening again. And whether it's us or us showing up at B-Sides events and other security community events already happening locally and face to face. The point is kind of fan out and try to get more base into what we do. Sure, go ahead Amanda. And we should be very careful not to duplicate the effort of what folks like Open UK and OWASP and our other friends are doing in that front. Thank you Amanda, that'd be great. I do think we have time for one more question, especially since we tend to give five paragraph essays to answer. I have a question there. In the back there? Yep, go for it. Can I turn the background and ask what we should be doing? But let me repeat the question because I don't know. You mentioned AI and building sophisticated models. So kudos on that. But sorry, I'll repeat the question. The claim was in three to five years most cybersecurity issues will be about automated systems versus automated systems. And we might lose the battle if we deal with it too much as I'm extrapolating here. As a cultural community, let's just go find all the bugs and fix them kind of thing. Instead AI models become much more important and just new kinds of defenses I assume. So unless anyone else on that one. I have thoughts on that. Thank you for asking the question. And I brought this up in DC. So recently I picked up a book on chaos engineering and I was fascinated by it because the point of chaos engineering is outages matter. In our case, security breaches matter. So I feel like we can't code our way out of this problem. I really don't believe we can. We can do a lot to shut down a lot of the penetration points we'll just call them, but we can never be 100%. So I feel like what we should be doing as a community is really coming up with a FEMA response. How do you report a problem? Then what happens? What is the escalation? Is there a central organization that reports to everybody what's occurred? I'd love to find out when Jamie, when IBM found out about Log4J or whoever first discovered that, which I don't know, what did they do? I'm a developer. I found a bad problem. What do I do with it? I feel like that is where we really should be looking at creating a proper response because outages matter, security breaches matter and that's something that we should be laser focused on to solve the problem long after we, Alpha Omega has scanned as much as it can and after we've got S-bombs everywhere we still have the potential of having a breach and what do we do with it? Any other thoughts from the panel? Thank you, Colin, well, yeah. Okay, and any thoughts from you on what you think we could do in this space? Well, I think we have a volunteer to help convene it, perhaps. I see hands up. I think it already has a comment. Oh, is that, no, I think all the hands were like, volunteering to go help. So put together, Ava's gonna help you put together a great proposal for the TAC and I think we have a working group number eight already in hand, great. Cool, well, with that, I think, are we at the time? Two minutes. Anybody have a two minute question that we can give any other questions? Okay. Ava, go ahead. Yeah, I mean, when there's a fire, the FEMA gets involved and they have an escalation policy, right? We don't have that in open source security. We don't. Well, let me suggest mapping out, like what does CISA do in the event of like a future log for J, I'm just looking for Alan. What does ONC do? What does the National Security Council do? As like the government side, but then also what does CERT do, right? And in response to log for J, that was where it was actually discovered by a Chinese developer working for Alibaba, followed appropriately reported it to the Apache developer community. They made a commit to a repo that mentioned a CVE number and then that triggered, there's a whole bunch of vendors out there who watch commits who went, oh, there's a CVE number in this commit. I wonder what that's for. And then that led to it inadvertently getting out too rapidly. I might be way massively under. Okay, thank you. And so they're possibly, if we were to map it out, we could probably find a gap. And I think one of the gaps that we found really spoke to one of the mobilization plan points, which called for the establishment of the emergency response team, right? Which is modeled after other things that we've seen work, but not as open source focus as what we proposed. But even if we proposed that, I know that's what you were responding to with a comment in DC. There might still be a need for somebody who is more FEMA-like to compliment those efforts. Yes, somebody has to manage that incident. That's the key there. And Crow wanted to say something on that point. So the vulnerability, anyone of us interested in scoping out and trying to contribute to solving this problem, everyone is invited. So if you're interested in this problem, find Crow, find Tracy. There's a meeting first week of July, to focus on this, to get that emergency response team set up. Great, well, I think with that, that's a great place to end on. I want to thank my panel. Thank you, Brian, for having me here. Tracy, Rao and Bob, thank you. Thank you.