 Buenas tardes y bienvenidos a Security Research con Open Source Software Volume Omega, soy Yacenia. No, this is not going to be in Spanish, so if you just freaked out a little bit, you're welcome. I'm very excited to share information about updates to the Alpha Omega project from OpenSSF. But before that, I want to talk to you a little bit about who I am. I'm a first-generation Cuban American. I'm paving the way to awaken the indomitant warrior spirit within all of us, protecting us in both the digital realm and the physical worlds. I'm a proud Latina, standing as a beacon of strength, attacking global security challenges and traveling, while symbolically building communities as a servant leader with a dedication to fostering self-confidence, cultivating partnerships within the tech space, and championing diversity, equity, and inclusion. Alpha Omega will be at the Grace Hopper conference next week, and we are hosting our OpenSSF Alpha Omega project at the Open Source Project Day for Grace Hopper. I have an extensive background spanning over a decade in cybersecurity, software development, I hold debaters in computer science, masters in digital forensics. I use none of those. And I've worked in various areas of cybersecurity, including security operations, security research and development, supply chain security, and open-source software. Beyond my contributions to improve protective measures in the cyberspace and our open-source ecosystem, I also train Brazilian jiu-jitsu, and I lead our women's self-defense program called the lioness instincts. Throughout my career, I've taken a proactive role in establishing and nurturing various DEI organizations, including co-founding the Latinas in cyber organization. My advocacy to empower women not only to join, but also thrive in the tech industry by being a strong advocate for personal development, self-assurance, and acting as a cyber hunter and a big sister. If you're an OpenSSF Day, I spoke a lot, so this morning I woke up and my voice is like, we're not having it today, so it's a little raspy, so bear with me. A little fun agenda for those that don't know about the project. I'm going to dive into the Alpha Omega project, then talk about some of the challenges, give you a little details on the Omega tool chain, talk about our science fiction that we want to make into reality, and how you can contribute if this is an area that interests you. So over to the Alpha Omega side. The Alpha Omega project is the beginning to the end of manual security vulnerability disclosure processes. Both sides has its own unique mission with the Alpha side focusing on the now and the Omega side focusing on the future. The Alpha side is focusing on working with foundations such as Python, Eclipse, JQuery, and recently announced this week, Rust, in order to improve their security postures through funding and consulting. And then on the Omega side, which is where the most of this presentation is going to be about, is the how. How do we bring an end to manual security vulnerability disclosure process and ease the burdens of our open source maintainers so that we can clean up this ecosystem that we're in with little to no headache for our maintainers. So we'll get into that. And here's just a little bit of our how. So as I mentioned, the Alpha side is focusing on working with our open source maintainers. But from the Omega side, we're targeting 10,000 critical open source projects. We have a list. We welcome feedback on the list. We run it through multiple sources like Harvard consensus Linux Foundation research to kind of compile that list we do. It does need cleanup. But any information or guidance you can provide to allow us to target the proper 10,000 or even more. We just had to throw a number at the wall and go for it. So we said 10,000 and and no, we're not going to shoot for 10,000 at once. It's like, are you gonna do it? No, I plan on doing a rollout with some pilots. So a little bit about the team. Our team is less than a year old. I started back in November as a software security engineer and then Jonathan light shoe and our mascot sassy the duck. You probably seen him and the duck roaming around the halls of this conference. They jump back in January. It's been an interesting ride as in any open source journey. With our two extensive backgrounds and security security vulnerability, we're pioneering this work in hopes to resolve the challenge across the ecosystem. A little update this summer we had the privilege of hosting our own mentorship. This was run through the Linux Foundation mentorship and we are looking to do it once again next year. We were able to hire four mentees to were software engineers led by me and to were security researchers led by Jonathan. It was really great. Starting our journey, it was clear to Jonathan and myself that we needed help. So both of us are very passionate about bringing up the next generation of technologists. So we're like, how do we help the next level of technologists as well as move forward towards the mission and objectives of the alpha mega project. For more details on what the security researchers did please reach out to Jonathan, but essentially they worked on an XSC vulnerability research piece writing recipes for that, and then worked on multi multi variance data flow analysis, and that is the extent of what I can explain on that piece. But as far as the engineering side, we on the omega tool chain, I call it three different phases, so to speak to kind of lessen the complexity of it. We have our identification of our security vulnerabilities. We'll have our triage piece, which is just where I'm compiling all the campaign research, the analysis the recipe writing the testing the communications to our open source containers to communication to our source code management systems to make sure we don't do DDoS their systems, and they're aware of the campaigns we're about to run. And then of course the security campaign execution. And then part three is a remediation on this summer mentorship. We focused on the first piece, which is the identification. So we have a tool called the omega analyzer, which scans, which is a Docker container that contains about 20 plus open source scanners, including some proprietary licensing tools. We have that piece, it runs, it scans an open source project that's pulled down from either get hub or it's right on your local. And from that it produces a single seraphile, and from that we uploaded it to our central hub which is called our triage portal. So the mentees essentially developed a whole full flow from our analyzer into the triage portal, developing a graph graph in API, implementing authentication hardening so JWT token to make sure that we have an authorized user submitting our seraphile validation that it is a seraphile and then checks them to make sure that from our analyzer to our triage portal, these results haven't been compromised. A few other updates, we do have a university program that will be on hold for right now during the summer we had Purdue University working with us, leveraging the omega analyzer for their research. More will come out on that soon. We also had the creation of the vulnerability disclosure auto fix SIG, I see some participants here that are part of it. And from the SIG, I'll go into more details on documentation further. We've created the specifications drafted out document for specific specifications on how to run an auto fix campaign creation. So taking the open source container in consideration, taking our source code management system in consideration, how would one actually run this on their own, and then kind of guidelines for how the alpha mega team is going to run it. Most of the conversation for the omega automation is driven through this working stick through the open SSF. We also have alpha grants that have been sent out and there's been being mentioned with an open SSF day on alpha mega, mostly working with open source foundations. But you can check the open SSF blog for public release or any information on that because I'm not too sure which ones I should mention which ones I shouldn't. So I'll just leave it up to the blog. So some of the challenges. So this one's interesting. I was, I was having a conversation with somebody earlier this week about this problem, and they presented the idea of a doctor and a prescription. And I'm still structuring this in mind. So the challenges may be similar in some nature. And grants in medicine and security vulnerabilities are two big different complex issues, but a security vulnerability in open source is like an infection is essentially as a sickness. At times we walk around and we're not aware that we have an illness, and it's not until we see a doctor or run a security scanner that we become aware of the sickness. If we choose to see a doctor, some of us may be stubborn and not seek this medical professional while others may just not have a means to seek these medical professionals. A doctor can prescribe a remediation. So similar to chatting to a security vulnerability security expert about the vulnerability founds. Now, as I said, I could be stubborn with prescribed remediations from medical professionals. Sometimes I just ignore it. And just allow my body to naturally heal. However, software hasn't had this magical property that we humans have to get rid of sicknesses. So not yet at least. So we can just ignore it, or we can do something about it. If we work with a doctor and follow their, their guidance from remediation, it will heal the infection that was discovered. So once again, both medical and security vulnerabilities are just much more complicated than this. There's the human aspect as well to security vulnerabilities. Disclosures such as an open source container has a life. We all know that we have lives. A lot of these projects are side projects or we're just running multiple things at once that it's really hard to stop and sit back and do the research necessary to understand how to remediate this vulnerability that we've discovered. On top of that, these are stats that Jonathan has published. So there's no research on it that I can point to. However, a single vulnerability has taken him from three to eight plus months to full to flow through a full vulnerability disclosure process with a single maintainer. So we have a long lifespan from identification to full remediation, even when providing a patch. So let's move over to the tool chain. Our mission is to build tools and processes for conducting automated campaigns that discover triage and remediate security findings to significantly reduce the presence of security vulnerabilities at scale. That's the important piece and the more complicated piece from our open source software ecosystem. Just a little highlight of some of the multiple tools that we are building. All of them are in POC very much development and we do need assistance and contribution and putting these pieces together to make them all work and communicate. And all the wonderful things that come with software development like testing, operations, CICT pipelines, deployment, I can just go on with that list. So essentially, I have a pointer or analyzer. This is the one I mentioned earlier to Docker container with 20 plus security scanners. This is what we'll be doing the analysis that analysis is sent over to our triage portal. The triage portal is kind of like a centralized hub where we'll be doing a lot of the orchestrations of our automation. We also have our assertion assurance assertion framework. And this is our policy driven bar, which is an additional bonus to what we're trying to build. And this is essentially as an open source. I'll say you get a lot of SQL injections. However, your database, you know, you've looked at it, you've analyzed it and you're like, this is more of a false positive. It's not really affecting us. It might be a database used for cash or testing or it's not used in any functional way that the impact of the vulnerability is going to have a likelihood of bringing you down. So you can write a policy to just say, if you continue seeing this, just ignore it. We have our disclosure check, which we're trying to move over to we're trying to or we did move it to the vulnerability disclosure working group. And this is essentially what scans an open source projects and collects a lot of the disclosure contact information. So is there a security md file? Who do we contact? Is there an email associated kind of getting those communication first pieces of how and who do we communicate if we do identify a security vulnerability. And then moving more into the, the nitty gritty of the security pieces, we have our open auto vulnerability disclosure, which is a state flow machine to orchestrate the vulnerability scale right now that piece is also the tests have been written and then the functionality to flow through the different states is the next steps. But this is kind of what will be flowing through the steps for our vulnerability disclosures. And then we work with modern. So Jonathan has written a wrapper around the modern SAS client, which will go ahead and automate a lot of our security vulnerability of reporting into get hub. One of the concerns and issues with it is that currently pushes for public issues. One of our goals is to make it where it pushes into private issues, which is a capability. We're still scratching our heads on how do we implement this and get this done. We're working with get hub and modern to kind of figure out these functionalities and features so that we could automate into a private vulnerability. So just a little deep dive into the analyzer. As I mentioned, multiple times it's a 20 it's a document in there with 20 plus security tools. Most of them are open source and then we do have some license like a sneak sneak. I always say that went wrong, but it is what it is. It connects to our assertion framework for the policy based data if you wish. We've also implemented over the summer a flag that you can push it to a production or a local instance of a triage portal. It produces a single Sarah file with all the results so it'll scan with all 20 or whatever set of scanners you set it to and you'll receive one file with all the results. You will receive multiple files per results, but we did compilate and compile all the results into one so it makes it easier. Instead of looking at 20 different pages with or 20 different documents with 80 different pages. Now you get one document with as good set amount and you can actually structure it so you can only get the criticals and the highs and produce the results you actually want to see. And that's our link to get hub. Next is our triage portal. I'm not going to play the demo that's just there for content and if you wish to look at it that was a demo from our mentorship and some of the changes that we did to the triage portal to produce these results. The main goals is to add automation as I mentioned this is going to be our centralized system this is going to be a system that's going to be orchestrating our automation of pulling the contact information from our open source maintainers repels. Documenting how to contact if they prefer an email if they prefer Jira. If they just want us to, you know, create a public if they wanted to do private whatever method it is, we'll be collecting that with a disclosure check and updating that on the portal. That's helping us track vulnerability disclosure. I don't know how many people here have done security vulnerability raise of hands. How easy is it to keep track of all of it. I see some smiles doesn't seem easy right. Let's say you pull about 10,000 poor quest. How do you keep track of that so that's a common issue right now is keeping track of where we're at with those communications and understanding like I have a large scale of poor quest. Each of them at a different state each of them at a different level of conversation each of them with a different problem. So being able to provide a central system for our security vulnerability security reach searchers to be able to keep track of the work that they're doing. So the creation of private vulnerability disclosures as well in get hub so having that automation system tool to be able to actually automate your creation of your PVR your private vulnerability report in get hub and then being able to publish any reports or any fixes that can be made to it and performing some actions in get hub like let's say I need to add a comment or a comment was added. I need an update to know that I need to reach out to that individual maintainer. It is built on Python Django framework. There's both a UI and an administrative background back ends with Redis and Postgres and then some lovely Easter egg QR codes and some links. This one we will watch. We this is the Omega material client and this is the piece of the automation that kind of keeps track of public vulnerability reports from when campaigns are ran just so you can get a view of what happens. It's a very short one minute video that would probably end. But as you can see in a campaign has been executed. We have the status of where that campaign has been ran. And this isn't the status of remediation or anything. This is just the status of a campaign running. You can see the associated organization the associated repo, which branch is targeting which most are master main whichever the default branch has been set for that organization. The number of results that it returns. So this is the number of lines or areas that we've identified the specific vulnerability that we're executing on file searched and then time ran. And I think it's finished or the video is over. I won't move on anyway. Cool. So some science fiction to reality because I mean I'm a nerd. I love Star Wars, Legos, Super Mario, anything that's not real. It's great. So when I came out to this project, it just seems like a science fiction ideas like how do we scale all this? How do we just identify all the vulnerabilities out there? Create a fix, send it out, patch it and move on with our life doing 10,000 millions at a time really cleaned up the ecosystem. If you've worked in development for a while, you know, there's a large tech debt of both documentation. That's another that's another one where we're not going to get into this talk documentation security testing operation those pieces. So the vision for this is essentially being able to automate the creation of private vulnerability reports. Currently with get hub we will expand by focusing right now with get hub because baby steps with a fix at scale. We're looking to do over 1000s of pull request tracking and monitoring of the executed executed security campaign fix. Properly managing the communication. So having a central system that helps let us know like, hey, this one wants an email. This one wants this one does not have private enabled. So let's create an issue, a public issue requesting that they enable private monitoring and metrics because we all know stakeholders like that. None of us. I don't know anybody here. Anybody here likes automated metrics. That's what I thought. Oh, one person. There you go. Data science background. No, no, the answer is no. Short answer is no. And then of course retrospective feedback from our retainers. We're pushing these processes out we're affecting their workflow we're affecting their lives essentially. So we want to make sure that what we're doing is not putting heads with them is not getting them upset is not getting them on Twitter, Metro drone and yelling at us. It's essentially, I would like for this to happen and someone was like you just made my life easier. That's my goal. So really getting that feedback and that innovative process communication with our maintainers to make sure that we're doing this well, which is where a lot of the folks in this room come in is to make sure that we're not going to put heads and we're not going to have to, you know, rumble. And then of course, as I mentioned, incremented rollouts. So starting with probably a pilot of 10 or working with a foundation to just target them to make sure that once we do go at scale, we're not going to get to the challenges or the world's you know, it's like that dog name, even though I love chaos. Where's Ryan? Okay, through the vulnerability auto fix sick, we've worked through several different types of documentation. As I mentioned earlier, we have our specification document. point right there. It's a long document. It's a long read. It's a good night's sleep read, but it's kind of how we're trying to drive our vulnerability automation. So if you need a good read, if you've got a long plane flight and you want to provide feedback on how to make this process better, that would be one of them that I start with. That's more of the nitty gritty of technical how and some guidance that we're also sharing for our community. For OpenSSF and for Alpha Omega, we've also worked with creating proposals and documentation on outgoing vulnerabilities. So somebody in OpenSSF or Alpha Omega has identified a vulnerability. What's our process going to look like? And then vice versa. You have somebody out in the ecosystem has found a vulnerability within Alpha Omega. We're vulnerable. Yes, we are all vulnerable. Or OpenSSF, how do they come in and do the same thing and provide us feedback on letting us know, like, hey, we have, we've identified this and found this. Go ahead and check the documents itself for its status. They've all three been at different stages. So opening the document itself will allow you to see. And where I'm really requesting some feedback is in the design. If you like architecting, if you like security, if you like vulnerabilities, if this interests you, we are working on designing our user stories and our next steps to kind of roadmap what the Alpha Omega Omega pieces are looking like. We've identified eight, if I can count this morning, eight different personas that will be interacting with our systems or ourselves at some point in our time. This is a security fix engineer. This person's primary focus is creating a recipe. So they're the ones that are going to be looking at a vulnerability, doing the analysis, working with our different clients like the Modern client to create a recipe that will go ahead and fix it. Modern is limited to only Java at this moment that we've known. So also looking at other systems to be able to support other languages. Our security researcher would be the one that will drop in and do some of the analysis as well and working with an open source container. As far as the technical nitty gritty, we have our non Alpha Omega organization. So these could be some of the foundations. Anybody that's not an Alpha Omega, anyone that's an organization that's not Alpha Omega essentially that will be interacting with us. We do have some stakeholders and some folks that are working in collaboration. Open source containers like yourselves are probably the biggest persona on this. Our developer advocates, it's very important to continue having a proper communication with our open source containers. So being able to have that relationship building with them and keeping sure that if we do submit 10,000, we're not going to be spending the time of a security researcher to go through each and every GitHub issue or pull requests, but we can spend a developer advocate to look it over, kind of be our tier one customer support and escalate any issues to the appropriate member internally so that we can alleviate. Granted, this is all big dreams. It's only me and Jonathan. So we're both wearing multiple of these hats. Software security engineer, we need the folks that are going to be building, operating, maintaining and troubleshooting the system. And then our Alpha Omega stakeholders, that's where the metrics come in. And then we're looking to leverage LFIT for some of the cloud operations. So these are the different types of personas that we were seeing to interact with our system. If you want more details on, and just a definition on what they are, this document up here, the user stories is kind of where we define some of the concepts. We define some of the concepts for our internal vulnerability, fixed campaigning, our requirements, our requirements for persona, and then some of the GitHub features that we're looking to chat with them to roadmap into their product. And then if you're more of a planner and want to go into many gritty details of those individual user stories, we do have a spreadsheet that we're working on our planning, our prioritization, our dependencies, and all the fun documentations that all of us engineers love doing, right? More of a, let's just get this going. Yay, there we go. Yay. So we are in the mix of working on that. So we would appreciate any feedback to kind of help drive this and make sure that we're prioritizing properly to get what you need. And then how to contribute, as I think is the most important section. Open as a staff. If you're not a member, the slide is just to show you the different ways that you can work with us, YouTube, Slack channel, mailing list, public meetings. We do have for the Alpha Omega project, a monthly meeting. And then we do work with several of the working groups. I saw some folks taking pictures. To work with us specifically, we have our repositories. I might be missing one. So the analyzer, the analyzer and the assertion framework fall under the first one. I'm missing the disclosure check. The disclosure check is not out there. And then on the open as a staff Slack, these are the channels that we work off of. We are heavy participants in the vulnerability disclosures. We run the vulnerability disclosure out of fixed group. And then I work heavily within the security education and DEI. And that's where a lot of the university and the mentorship came out of. We have a public meeting. Vulnerability disclosure meets every week on Wednesdays. We have multiple. We have the vulnerability disclosure. We have the auto fix. And then we have the, the APAC call measure. I think it's the vulnerability disclosure APAC call. And then if you want to get into the nitty gritty, get your hands into the wheels and grind out some of our issues. We have technical issues. You can look for first good issues or help wanted. You might see help wanted on a lot of them. You can check that out or reach out to myself and see where you can get started. And then of course, non-technical issues are always welcomed for those that are either new and trying to understand the product or the space. You can go ahead and start with that. And then we can gradually move you into more technical if that's where your career path and goals are. And with that, I'd like to keep my things, my presentation short, short and sweet. So thank you for your time today and listening to me. I know we're right before lunch. So I see the lunch faces. So I don't want to keep you from that before the lines get long. But thank you so much for attending the presentation today. And if we have any questions. Thank you. I was curious if to what extent upgrading dependencies within a project is in scope for for alpha omega or if you're looking for or if you're only looking to fix. Votabilities that exist within the project itself and not its dependencies. So not so not taking a project and drilling down into the dependencies, but the dependency may be in our list. Sure. And I suppose what I'm asking is like, would you ever help help a project upgrade from one outdated dependency to the to the new supported dependency that doesn't have a vulnerability, but maybe the project can't can't do that upgrade because of like API incompatibility or something. But they can't easily do it. So if it is a version difference, that could be part of our remediation guidance. But as far as targeting that and putting that in scope, it is not in our scope. But if we do see one and we're like, hey, I'm not going to send you a fix or maybe our fix is just going to your requirements file and updating upgrading to the next. That is something we can do. But it's looking more into, I like to use a seco injection because that one's a little bit less complicated. But if we identified a seco injection and your code, we've identified it 10 times throughout is will submit one pull request, one pull request, fixing each lines of those code where seco injection was identified. Great. Thank you. Where's the hard questions? Come on. Something a bit related to that. As far as I understand and correct me if I'm wrong, you try to like get this all the vulnerabilities and make a single point of communication for that. With that, it would be really interesting. And I haven't seen this on your users and user stories slide. But wouldn't it be interesting to include like package maintainers for distributions or something like these roles that can benefit from your work as not the primary target, but as a secondary target or stakeholder? So working with the package managers like in the communication process, if I'm understanding it correctly. Because they have to update the open source project, they are maintaining as a not maintainer of a project, but maintain as a package maintainer. And that's a valid point. That one's come up a couple of times in our discussion. But from the way we're perceiving it and granted, you know, we can always have a discussion about this is that's where the CVEs come in. So once you do the fix and you push out the CVEs, it should be the package maintainers responsibility to communicate to who's using it and saying, hey, we just fixed this. I think commenting from us might provide overhead and maybe miscommunications between multiple parties. But it is something that we've been kind of trying to figure out like, yeah, we're going to do a fix, but we also don't want scare the consumer before it's actually fixed. And there is a process afterwards that once it's fixed that the maintainer should be communicating properly to it. We are targeting and one of our objectives is for a CVE to come out of this at the end, which requires that communication downstream. Good questions. We got one in the back. All right, let's, let's, there we go. So I work in JavaScript mostly. So, you know, dependencies are much deeper there. What you're describing with Omega stuff and this like automated patching sounds like another way to add like a second dependent bot basically, which, you know, I talked to GitHub and give them feedback about the kind of bot. What are you doing to like, you know, when patches are going out in PRs? What are you doing to like try to help like with balancing maintainer burnout and like reducing the burden on maintainers in addition to, or is that like consideration at all? Yes, so a few things. One, you can opt out. So if you don't want to know about no more quote unquote bots, you're welcome to opt out, but that does stop us from sending you any communications. We will fork your project and provide a fix for it as a secondary repository saying so and so, you know, this project has opt out, but we're creating a fix for this specific vulnerability so that it's available for the public. We're also making sure that we're communicating with. So we're not just going to ad hoc, just send out millions of poor quest and we've been working closely with some of maintainers that are like, I want one poor quest for that one vulnerability. Please let me know ahead of time in case I'm on vacation and because once we send that out, there's a clock ticking, um, but I'm really pushing for communication. So, hey, we're about to, you know, hey, maintainer X, we're about to go ahead and just send this out. We've identified it to you. You're going to get this. It starts the clock. Please work with us to make sure that it eases your burden because it could be a lot. Yes. Usually in the security.md file or even in there, they mentioned which method they want. They may not want private vulnerability report. A common way is like email and JIRA. We're not going to support JIRA. That's right. There's JIRA just traumatizing me. It's just I hear it and then traumatized. I wrote an API around JIRA to do security events and that's the end of that. But we need to work with them in some form or fashion. So it's going to be email private, private issue saying we've identified something. Please enable public issue. Please enable private point of view reporting in that issue. The maintainer can comment, but like, Oh, send me an email, send me a JIRA and we'll just start that communication to make sure that we're notifying them that what it is and trying to send the information as secure as possible. And then I saw a question in the back. So two questions. One, have you run into instances where people have wanted to opt out of the process? Yes. And how do you handle it? So this is mostly the work of Jonathan for the vulnerability more on the engineer. He essentially has done a robot.txt file that just he adds into it. No trace basically. Yeah. Yeah. It's like, all right, you walked out, but I'm just going to create a fork of your project, provide the fix and that way, at least if somebody finds it, they get a clean version. Second question. How are you? So I see a lot of cool tools there that have potentially like overlap with other open SSF projects. Are you collaborating with the maintainers there across the working groups to make sure that there's not duplicative effort? Trying to. There's so many meetings and only two of us. So I'm hoping during these conversations, folks could reach out to me and be like, Hey, we already did this. And I'll be like, sweet. I don't have to do it. Definitely. I'll find you after work towards. Yes. So right now, good question, which languages are we retargeting open rewrite, which is the rendering client is primary focused on Java. I know they're putting support for other languages. I'm not sure what the languages are. The analyzer supports Python, go and NPM. I would like to go for Python next. I feel like I'm not going to say it might cause controversy. Go, go might be a little okay, but you know, but looking, I know from the list, Python and NPM have a larger span across the ecosystem. So it would be identifying the list, talking to them and seeing who wants to work with us. So definitely working mostly with Java because it already has a system in place for us to do our POC. We've been able to, well, Jonathan's been able to support and show the automated scaling. I don't know the number. I'm going to throw it a random number out there that I think it is. I'm just randomly generating 35,000 pull requests. I think he did. If you saw his talk yesterday, he went into the number. But using that as the proof of concept for this research. And yes, we do have the restrictions on open rewrite with just Java. It's something that we're looking to overcome in the next couple of months to figure out how do we get Python, how we get Go, and how do we get NPM because that's where our identification system can work on. You're welcome. I got a question. What's for lunch? Where's our good food here? I haven't found a good player. The question on force positives. So for example, dependent part likes to open these pull requests to update the dependencies for generating checker pages. But most of those are actually security vulnerabilities due to how the package is used. So the package may have a security vulnerability, but the context in which it is used doesn't have a security vulnerability. So how do you handle force positives in these cases? So that would be a communication with us. This is where I would hope the developer advocate will come in and either the maintainer reaches out to us directly, reaches out to through the comments saying, hey, I don't think this is right. We value your opinion and you know your system way better than we do. So being able to say, this isn't a security vulnerability for us. We'll have that conversation. We'll make sure that we're both in line, that it's not. We close it if it's not. And then with the assertion framework, you could add a policy to make sure that, hey, you can avoid this. And if you've noted to us, we do need kind of like an opt out vulnerability piece to it. Just from conversations that I've had this week is something else that we've talked about for this situation in case as well is to make sure it's like, but we don't want to exclude it completely because it could appear later on the future, right? There could be multiple languages in that project and just maybe the documentation that won't exclude not the entire project. Yeah, good point. The other one is that we've also found them in test. So we are excluding test unless it's a dire situation, but very valid. Any other questions? Going once, going twice? I released you for lunch.