 Perfect. Hi everyone and welcome to our LFX security webinar. This is the second of our LFX tools series and we're really glad that you could join us today. We're going to be introducing you to LFX security and sharing a bit about how our tool is enabling projects to make security part of the development process. So first we're going to give a bit of context around the Linux Foundation's security initiatives, then we're going to dive into a demo, which is I'm sure what everyone is here for. We're going to cover the capabilities of LFX security including vulnerability detection and fixed recommendations, license compliance management and more. Feel free at any point in time to ask your questions on chat or in the Q&A feature here on the Zoom webinar. We want to make this as engaging and relevant a session as possible for you so please do ask away. We have a number of moderators here to field your questions and we will also have plenty of time at the end during a Q&A session to ask, you know, any other questions and go over your questions in detail. Finally, this webinar will be recorded. So if you want to revisit this or if you have any colleagues that would like to hear about LFX security as well, we will be posting this on our Linux Foundation YouTube channel. So you'll be able to access that pretty soon. We'll send the link to you after today's webinar. So we'll be able to get that up and running pretty quickly and you'll be able to reference this as often as you like. I would like to start us off by introducing our speakers. So, Shubra, Kar, our CTO and general manager of products here at the Linux Foundation will be driving our presentation and demo today. We're joined by our partners at SNCC. The CTO of Global Alliances gave us Solomonovich, as well as a number of moderators here from the Linux Foundation side and from SNCC. With that, I will turn things over to Shubra and he is going to get started. Great. Thanks, Stephanie. Alright, welcome folks to this webinar. The key goal that we're going to talk about is like how do we build more sustainable open source projects. And the word sustainable is very important because for most open source projects sustainable actually means it's more secure. Again, driving enterprise adoption and whatnot. Right. So, you know, how can we actually help these projects succeed right we were looking at different areas of challenges for open source projects and the world runs on open source right and critical projects that are basically important you depend on day to day. They need much more than just a source control system or a version control system to scale. And as you look into the ecosystem, the projects must have a finger on the pulse of the entire community. And, you know, with tools that you know you're tailored for key stakeholders because you know not everybody is just a developer or a contributor you have maintainers you have community managers you have outreach people market years and many more documentation writers. So, over the number of years right the Linux Foundation has been around. Most of these projects have evolved a proven methodology, how to you know help address these challenges, and they started small, and then you know they transformed into these from fledging projects into these category leaders like the Kubernetes and the node jays of the world. So, what we did is we have tried to operationalize this approach and we came up with a tool chain, and that tool chain is called LFX. Now, LFX think about it as a toolkit, you know it adds value at every aspect of open source development is built by the Linux Foundation engineers and the community, and various tools in the kitty, you know, primarily things like insights for you know monitoring the project, the developer activity, everything from code commits to the ecosystem activity in terms of you know your outreach whatnot. Security that's the product we're going to focus in detail today challenges around vulnerability detection, you know, IP management and whatnot. We have other tools in there for tools like easy CLA, which address the challenges of productivity for developers, particularly for projects which have, you know, CLA requirements contribute to license agreement requirements for, you know, which need to be signed up for companies as well as individuals. And we also have tools there which, you know, aid you to grow the community by hiring mentees getting a lot of mentors and we have thousands of community members who are actively involved in these projects post timers. This service really helps them. We also have a crowdfunding service, you know, helps projects to raise the funds when you're just kicking off and, you know, going on to become larger projects they have infrastructure costs and whatnot. Similarly, we have community events like you know you're doing your own branded events across different cities. We have a training portal if the project wants to enhance its skills in the community they can launch courses. We have a project control center where you can, you know, manage all your IT needs, all your legal agreements and whatnot. So it's an entire toolkit. Today we're going to focus more on the security part of it, but feel free to, you know, check out the other tools in the chain. The website for that is just LFX.dev. That's where you can find all these tools. So, again, improving open source security is not something that's been new to us like we have been, it's been a key objective for us for many years. And to face the problem we said hey you know what to get started we need to answer three very simple questions. First of all, what is the most important shared software in the world, right? Now can we index them by packaging, package version numbers, by industry and sector, by criticality score, who is using it. But more than the usage, it's also who wrote it. Who are the maintainers? Who are the developers? What is the project health? Like is it growing healthy? Is it getting steady state? Is it trending downwards? Are they getting contributions? But more importantly, how can we also make it secure along with keeping it healthy? Are there tools for contributors to look at or these project governance committees to look at to ensure that security is not an afterthought, but it's part of the development process, right? So, to answer these questions, the Linux Foundation started a few years back on initiatives like CII, the core infrastructure initiative, which was more around the best practices and we encourage people to submit proper audits, make sure there is a lot of best practices that are documented. And we put badging, and we also asked them to scan their projects, upload those reports, do proper bug bashes and whatnot. And we started giving these badges, which were passing gold, silver, platinum, and we had like huge adoption or about 3,600 projects that were using the industry CII badge. And then as we started evolving, we started getting more projects with defined frameworks for IP management, in particularly licensing, like SPDX is a great framework. We had a 2-2 group where a lot of communities were engaging and sharing security best practices. We recently formed a project called OpenSSF. Again, cross-industry collaboration, but looking to define what are the global standards for security, and this now also includes standards. But again, just best practices weren't enough. They needed to be tooling that are easily accessible to our community. So we had a few earlier, particularly with projects like Phosology and then Kregit, which was more like measuring code attribution. We had a special project stood up called Red Team. Again, different areas, some of them were around encryption, some of them were hardware security, code packaged on embedded software. So a lot of initiatives, but then we started building a comprehensive tool chain, and that was in LFX. And we have launched security and insights. Insights basically gives you the whole idea of the ecosystem and metrics that you can look at, and security actually gets you deep dive into really the security parameters that you're measuring your projects against. And we are looking to integrate these tools with the best practices. It's not a small endeavor. It's going to take a long time. But also we started initiatives with like the laboratory for innovators at Harvard. It was called the LISH initiative, and we did a big census. CII had a census one and then we did a census two. I won't have time to go into deep into all of these, but these materials are available. I would highly encourage you to check these out around these different initiatives. But net-net, we need a multi-dimensional approach. Just one tooling or a best practice or a census isn't going to solve security, open source security. It has to be a combination of these three working in symphony. So talking about LFX security, the tool itself, right? So again, as we kind of started talking with community members, we said like, what are the key areas that you are worried about? Or like if you were to use security tools, what do you worry about in terms of exposure, risk exposure? So key areas we got was like, first of all, like, you know, if you put these metrics out, the hackers might actually know about these vulnerabilities and they're going to exploit our code. But it's kind of counter logic because, you know, hackers don't need our tools to exploit our code base. They'll figure it the way out. They probably know about it much earlier than us. So we need that visibility to quickly identify and fix these vulnerabilities. Many projects, you know, they just wondered we are not getting enterprise adoption. And maybe, you know, maybe a great momentum in the community. But when a large enterprise starts to use an open source project, the project fails to, you know, pass the security scans, stringent security scans. And that becomes a, you know, gate to, you know, getting enterprise adoption. Exposure to IP risk was another top priority. Like people didn't quite know like the licensing schema and software is now written in a sandwich. It's not just your native code. You are dependent on a number of upstream libraries and packages. And if you have a particular licensing scheme in your open source project, you do want to ensure that, you know, you don't have that IP risk exposure. Right. And then, but overall, you know, there needs to be trust, right. The more transparent we are, the better the community trusts us, right. And then users trust us. So we basically started with this project, we ran our tools and we scanned more than 10,000 repositories across, you know, close to 400 Linux foundation projects. And we did discover a lot of vulnerabilities. We know close to quarter million of them. And a lot of them had like low hanging fixes, which could be simply done by an upgrading a dependent library version. And some of these vulnerabilities did get fixed, right. But still there is a big backlog. So we are trying to get our communities to, you know, step up, look at these in details and take action, right, so that we can improve as a global community. Now, for these tooling, my team didn't really have a lot of stuff built out. And we spoke with the snake and like give a my friend is here, and he and his co co founder CEO. They said, Hey, this is slam dunk, like we should really join hands and you know work together for improving the health of the open source community. So we developed this tool in partnership with the snake. And the first version of this tool focuses primarily on vulnerability detection. And we'll, we are also collaborating with other industry players where we will diversify into different areas of you know, software bill of materials into static code analysis and whatnot right but this is a very strategic partnership and big shout out to snake for collaborating with us on this. You know, who can use this tool and why would they use this tool right so we have three primary personas right if you think about it that way, obviously the project maintainers and contributors. That's probably like the biggest bang for the buck is that that group. And, and then end of the day, like you know, you always struggle between functionality and security. You want to get functionality out there quicker, and you don't really have the time or resources to do research. And even if there are bugs out there, you know there isn't a verified bug backlog. And, you know, what we are providing with this tooling is that verification. Is that trusted, you know, source of data and we'll talk about it more how we actually verify that these bugs are not false positives, but essentially the more secure and trusted projects get that option and you can really scale your community efforts right with community driven fixes right like it's not just one maintainer has to fix it. Now for many Linux Foundation open source projects there are governance groups right and these governance groups there are special interest groups we call them as six, they have been set up to focus on security best practices from day one of the development life cycle. Badging, right. How do we know like what's the maturity of a stage of a project projects go from all the way from sandboxes to incubation to graduation, the digital badging, particularly around security, definitely helps define maturity. And obviously proper IP management and licensing we talked about this you really want to have a very seamless and smooth software bill of materials policy which is transparent to all your end users as well as your contributors. And then all our projects we know like you know they are funded by these member companies and our corporate sponsors. And for them and many of them are actually end users or adopters of the project. So how do they, you know protect their open source investments, many companies have commercial products built on these products on on these open source projects. You know, so you really need to guard against you know, security risk, you need to guard against IP risk, make sure these are enterprise ready and sustainable, right. This is who we build the tool for now there are a lot of features and not walk through all of those but in a nutshell, you know it's not a repo, it's not a single developer or a maintainer looking at their piece of the puzzle. But from a global governance standpoint, we build that we build centralized project dashboards. Now obviously developers can look at the slides of their data to the project they are contributing. But that aggregated project context is very important and a project could be 10 repose it could be 100 repose it could be 1000s of repose right. And you see that aggregated picture. Obviously, we scan automatically, you know, every day, we have evidences from trusted sources which help us validate that the bugs that we find are real, they are reproducible. There's a vulnerability database that you know on the back end snake updates with their security experts as well. Look at the entire upstream dependency tree so that it's not just your native code, you know, 80% of your code is borrowed from other open source projects. So you need to look at the entire chain, how secure that, you know, supply chain is, and there are fixed recommendations. So you know some of them are easy fixes some of them are not, but we do scan for licenses so that you can start doing you know effective license compliance. We also start plotting visually the releases that are happening when these, you know code releases so that you can see okay well maybe did we actually inject a lot of bugs with this particular release. And net net we built it neutral to source control systems right you could be on gate you can be using it GitHub get it get lab we don't really care. You know it has to be a trusted agnostic solution. With that being said, I'll turn it over for more deep dive to my friend give a here, who can talk about the engine that is powering the solution. Thank you. Thanks for the introduction thanks for having me here today. And thanks for going over this great initiative in LFX security helping make the the entire community more secure bring security in a more transparent way to the to the ecosystem, and ultimately raise the confidence of the end consumers of all these great open source projects. And so what one of the things they really like here about this collaboration between sneak and LFX security is, is their ability to bring two key areas of the sneak into LFX security to make it very, very effective. One is the ability of a sneak to detect the right open source packages, and then to the leveraging of our vulnerability databases, as you mentioned, and both pieces are important. The detection piece is important because when you're looking at your overall security stature you want to make sure that you're actually accurately and correctly mapping all the open source. packages you're using, including the upstream ones as you mentioned, and put them in this context of a full dependency tree as as articulated here on the slide on the left. This really helps understand where vulnerabilities are coming in into your application and what type of fixes and version upgrades you need to do to fix them. The deep detection which includes also those transit of the dependencies actually does allow you correctly to map your license compliance so is there one of these nested and transitive dependencies which including a type of license that's not compatible with the license you're trying to go out to market with your open source package. And so overall there's an incongruence of the, let's call it the legal compliance framework for for using your open source. So these are the types of things with the deep detection were able to flag and the sneak until database, not only flags, all the great vulnerabilities actually allows us to tell you whether the right upgrades to take the actions to fix the vulnerabilities you're fixing so it's not only about the detection and visibility it's actually goes much deeper in terms of action ability and what you can do to improve your security posture. So if you can go to the next slide here, just a few words about our vulnerability database and so when we look at it there's all these different dimensions where which you can use to qualify what a good vulnerability that database is all about. First in the top most wonders on the comprehensiveness of it so here we try to cover all the other ecosystems all the programming languages from a Java to JavaScript to go to rust and and even even the smaller more more esoteric ones and and not only the breadth but also the depth and each one of them having more vulnerabilities and having the deeper vulnerabilities those that are harder to harder to to find in in other public databases. And the second main dimension here is a timeliness. And so over time yes vulnerabilities propagate between different databases in different places but one of the things we really tried to do and our security team does a great job of is finding those vulnerabilities earlier and codifying them putting them in the database so we can communicate them back to our to our users so they can take the action faster. And so, under the consideration that the hackers know about these vulnerabilities earlier, the earlier the good guys know about them the more time you have to fix them before the, before the hackers have opportunity to take leverage. And so, in a bigger perspective, sneak is working closely with a lot of with a lot of the community members so the LF is one of our biggest partners of course and the LFX security is, is this amazing initiative but we also try to help bring vulnerabilities to the to the CV database sneak is a CV numbering authority we help maintainers and like a lot of the folks here actually disclose vulnerabilities and and responsible disclosure and stuff like that. And overall other than the community, our database is already true and tested also by the industry we have amazing amazing partners, which are leveraging the sneak vulnerability database to make open source security available through their own products companies like data dog like IBM like Docker and like rapid seven. Next slide. So, how is it that we're able to build this amazing vulnerability database just a few of the things that go inside one of course we track all the public vulnerability databases which are out there, every community has one Java has one go has one PHP has one, but also there's a peer led vulnerability database patch does a good job. And for example and so at the basic level sneak tracks all these in aggregates all them for for your benefit, and not only are we aggregating we're also enriching the data, providing developer friendly curated advisory so something you want to read something you're able to read and is, and is informative for you. We made that with our own proprietary research so sneak security experts do open up open source projects, look for big vulnerabilities we have a few big branded discoveries and a few zero days we discovered over over the years. All those getting incorporated of course automatically into the vulnerability database you don't need to worry about that. So this kind of most sophisticated thing we do is set up these threat intelligence systems which are listening to open source chatter across the web. Anywhere people are talking about open source vulnerabilities might be a jury board might be some GitHub commits might be a GitHub issue where vulnerability may be discussed, but if it's not disclosed and it's not package and it's not put in a in a database for the everybody then that type of insight gets gets lost. And so our thread missile intelligence systems capture all that chatter. Our security team review every single one of them to make sure there's no false positives and those ultimately end up in our database for for the entire benefit of everybody. And saying all that, we still can do everything by ourselves so sneak has a great community relationship we frequently get contributions from maintainers from other researchers from from from bug bounties people just looking and finding open source vulnerabilities all around. We do help with the responsible disclosure. And we do help with writing up the content. And ultimately, we do help by propagating the discovery to to our users. And last, last piece here is our collaboration with academia where we have outstanding relationships with the PhD labs like in Berkeley and Virginia Tech and Waterloo where our security team exchange with them methods data discoveries. And often they do these very deep, very deep type of researchers and they do find a lot of vulnerabilities. Again, we help them with the disclosure, and we bring all those findings to the community in a massive way through our database and through partnerships like this with LFX. Back to you. Thank you, Giver. All right, so let's, we'll do a quick demo and we'll again this is openly accessible to everyone. The easiest way to get there is. Again, I'm going to type in the URL is just security dot LFX dot dev. And you can see here we have already on boarded. Almost all of the Linux Foundation projects like you know there are cards where you know we have groups of projects like if you think about a project like CNCF. It's probably close to 75 projects under here. Right. So, how do you read the data. So, the vulnerabilities are broken down by severities, you know, high, medium, low and these are stack ranked based on CVSS scores. You know, essentially risk index. And, you know, we are aggregating all these vulnerabilities numbers and how many issues are open how many of them are fixable how many are fixed. How many languages, you know, these packages, these projects use how many upstream dependencies you have and unique type of licenses we find. Now, if I have to go and look into a particular project, let's take the use case of Kubernetes. As soon as I log in, I actually start looking at overtime. And again, if you're looking, you know, you can look into various time filters right like you can look into, you know, years months weeks whatnot. But you can see there are certain spikes in this, in this chart where you know you see a lot of these vulnerabilities coming in. Now, vulnerabilities directly don't depend on the release and like, you know, when you look at version control systems, like, you know, Kubernetes has hundreds of repos. And every repo, this is kind of the main repo, but every repo could have like, you know, n number of versions that they're pushing out on GitHub. But for the main ones what you want to filter down and see like, okay, was there a particular version that was released when this spike actually happened helps you start doing the visual correlation and if you find a lot of bugs into that particular GitHub repo, you are able to do the mental math. We do break this down into the languages and obviously this is, you know, preaching to the choir we pretty much know that most of the code base in Kubernetes is written in Golang. But there are other languages there as well. And you have the complete history of the tracking. But now if you start getting into the actual issues, the bugs that were detected. These are global numbers, but then we have a repo by repo breakdown. So let's take a look at a couple right so again this is kind of a plugin for Kubernetes in terms of like cloud provider. And you can start looking at the different types of issues and you can also see like some of them actually have a weakness integration or a actual CVE record associated with them in the national vulnerability database. And some of them don't right it might just be a weakness. It's not yet identified as a vulnerability and we indicate like if it is, is there a easy fix available to or not right so if I have to expand on this. Let's take the case of this one so again there's credit provided to the person who reported it. You know, this one looks simple. It's probably in a dependent library called tar and remediation here is like upgrading tar to a version 2.x or higher that fixes this vulnerability and the vulnerability is essentially a file arbitrary file overwrite. But if I want to essentially know much more about what this vulnerability or this weakness really is, we have the details of like you know that vulnerability, along with the references that were found in various GitHub commits or you know, sometimes security advisories that are logged in the national vulnerability database in this in case if it is a weakness in immigration you similarly have the full detail of how this is logged. Now if there was a hacker report, you might even get a reference to how to reproduce those. So here for example, I have a GitHub commit. To where that vulnerability was injected. I actually have a security advisory that you know npm, the package manager sent out, particularly referencing this vulnerability, and there's even a hacker one report. And this is where the collaboration in the community comes together, because you know you start looking at the steps how you know what's the detail how could somebody reproduce this right and is this the same pattern that I'm seeing in my code. If you really want to learn more about this, you know, we obviously have more details and other CVS scores and you know, we take you into the sneak console there. But, and many of them, you know, are look totally different like if I look another bug here. Similarly, this is probably the same type but let's look at the cross scripting error, right, and this cross scripting error. Again, this is an easy fix, and you know there are. There is even a pull request, which actually shows how to fix it. But like if you really wanted to create a GitHub issue you can click this and actually log a GitHub issue against your project. We are now tying up working more closely with snake where we will be able to do remediation automatically generate the pull request for actually fixing this particular issue in the database right. We also look at the entire dependency chain. So this is like by default the dependency chain of like how the sausage made in the sausage factory, but if you're really tagging them into filtering just the vulnerable packages in your upstream. And you look into like, okay, let's traverse to the tree. What in the upstream is actually has an issue. So if you start looking at these these point out where those which packages do have those issues. Okay, and you also look at the associated license type. Now talking about licenses. This is where the software bill of material starts to kick in play, because we do scan for all available license types in the code base and also in the upstream. And if you're using particular packages and again those packages could be in and one to N number repositories. If you find a non permissive or, you know, a license that's not like matching your licensing schema, you can actually start flagging these right now. Now, on the granularity side or the false positive side by default we are scanning develop dev dependencies as well. But this is a setting that you know you can turn on or off where you know you might say like hey maybe you know in production I do like if you look at JavaScript node. JS or other projects, you might be using a number of unit testing tools or whatnot in the in the dev system. And in production, you know, you don't want to track those dev dependencies they might still be in your package. But we essentially inspect the manifests, pull down all the dependencies from the package managers and then do the entire analysis of the sandwich stack. So you can check out more and there's more functionality coming here, but getting back to where we are headed with this right. So there are more items we are working on as we evolve this solution. We have started working on a code secrets detection project as well. And I'll show you like what that looks like. One of the big items in security is the signal to noise ratio right like there could be false positives now. I think sneak does a great job in eliminating most of the false positives but as we are expanding the solution. You know we really want to and we say like okay we start detecting code secrets you really want to weed out like well you know maybe this is a markdown file or this is a read me file. I don't really care if there's a you know demo API key in there. So how do you effectively, you know, start to remove these false positives at scale. We are targeting much richer integration with snake, particularly around automated remediation. Currently, we have the reporting, but we don't have the automated remediation turned on this will actually be very powerful. We are also looking at integrating it with the workflow, the developer workflow. And again, this could be written in terms of a GitHub action where you know the developer can actually take or the maintainer can take action against that from their own repository but the report also flows into that governance view. We are also looking to add support for container scanning CI systems. Now, beyond now integrating about we talked about like best practices platforms like CI so that's in our h2 roadmap to create a comprehensive security badge software bill of materials. We talked about licensing but how can you effectively start doing policy management on that right support for CC plus plus the kernel essentially is all see and if you look at like it's a root package it doesn't really have upstream dependencies. Those are rare, but we do need to, you know, start tracking vulnerabilities there so we might need static code analysis there because it doesn't really have dependencies. And then you know how do we start collaborating with we have started talking with the groups in physiology and open SSF trying to make this as a this tool platform this comprehensive tool platform. Kind of the tool of choice right for these communities to go and run there whether it's an academic exercise whether it's a real quality improvement have them use this as the as the reference implementation. So, this is a sneak peek into what we are working next on code secret detection so essentially we are scanning more than 50 secret types, you know, including passwords tokens and more and trying to create a repo level risk score. And obviously as I said like we have to squash all those false positives. So everything from you know an AWS key to my private PEM file out there to maybe a password assignment or maybe you know I have, you know, Pcap files floating over the network, where you know people might use that for a demo scenario, or maybe there's stuff in I committed in a dev environment, and then when I went to production I said okay I'm going to delete those keys. Instead of using a password like a key manager that Walt I hardcore did it, I deleted it in when I pushed the PR to production but it still stays in the get commit history. So we'll be adding this functionality fairly soon. And again as I talked about with deeper integration with sneak. The workflow is probably the most important one to really like have a bottoms up momentum behind this so that developers can also start getting immediate value along with the governance committees. We talked about the automated pull request. So if you actually get like a suggested fix, then you can issue the PR and obviously on container security give a do you want to add anything on this one. I think you covered a lot of it but just on this right more portion here so as as a maintainer as you're looking at your your security holistically there's many different things which go into it. Open source security and license compliance are two big ones and we started with those use cases but other aspects of your application and security is a containerization of it and so the container is a different risk surface that has different open source components compared to the operating system. If if your project is typically deployed with Terraform or with other IAC type of infrastructures code type of solutions and okay what goes into those scripts or recommended best practices. If you're deploying it securely or do you have misconfigurations and also over over time will probably add the ability to scan the proprietary code so the static analysis component and top of all of this. So through this partnership you you'll be able to get comprehensive security on your on your projects all embedded into into the tool coming on to your GitHub workflows and ultimately with automated fixes, namely with the pull request which go directly back into your repo with the recommended fixes. Perfect. All right so I'll open it up for questions but let me tackle some of the basic ones that I know like how do you get access so for all the and again like I'll talk about insights a little bit as well but like if you're on security like. And you need access but I have a super admin so I have access but generally you will see like request you have to log in with an LFID like that's our global single sign on for all Linux foundation projects. And then if you hit request access by default anybody who is a maintainer anybody who is a contributor to the project. They will get access if you are part of a governance group or the special interest group focusing on security, all our technical committees you know tax and all, they will be getting access all you need to do is click and just request access and will give you access to that project. Again, we need to respect the privacy, you know, disclosure policies that's why like it's not just open all to the internet right now, right. So let me pause there and see if there are more questions. Stephanie, can you see. Yeah, there's been some great ones coming through here. Steve Taylor actually asked a question here that relates to just this general how to get started. Specifically he's asking about the status of his request and secure my project. So it's hoping maybe she broke you could just talk through a little bit of what that process looks like in, you know as a project requests, getting there, getting added here and kind of what that flow looks like and working with our team to get set up. Yeah, absolutely. That's a great question. So when you click secure a project to essentially get this application for right. And we have this data and it comes to us for approval as soon as we approve the project gets on board it now for projects that are already on the Linux Foundation, you know list we have like close to 400 projects, you don't really need to request us to onboard, they will get on board it automatically. But for projects which are coming from outside the way you know there is a little bit of an approval process. So what we need is a little bit more context. So what I would highly encourage you if this you know, if your project has not been approved for some time is essentially just log the ticket with us in our Gira system, because what happens is like, you know, there is a cost to running the security in terms of infrastructures and all but if your project is really critical for the open source community we don't want to you know open this up to a million open source project we are focusing on the most impactful critical open source projects, which are big impact for the community. Right. So, like, when those kind of requests come in for projects that are not within the Linux Foundation, we run it by our technical committee, and as long as they feel yeah this is actually a very important project we go ahead and onboard them. Right. So, I think in this case your request, we will definitely follow up on this request. I don't know why it's stuck. You don't need to log a separate ticket for this one we already got your request. But that would be the process right like if you are coming and your project is not already a Linux Foundation project. Awesome. Thanks you breath. Another one of relating and kind of relating to how to get started. Steve Gary asks, are we proactively scanning all Linux Foundation projects or do projects need to request you to do so. No, we are proactively scanning all Linux one we are actually trying to reach out so many times what happens some of these projects have a dedicated community manager or a project manager. So if you're not seeing the project on that list, do drop us a Jira ticket because sometimes it's very hard to find who the maintainer or the governance person for that Linux Foundation project is, but our initiative is to proactively scan all so we already have the repository of Linux Foundation and everything for most of our projects but if you're missing you, please feel free to you know log like all you need to do is you know go here and just log the ticket. It goes into a Jira queue, but yeah it's proactive. Great. So here that I'm seeing and please, if there's any other questions that you have feel free to ask them in the chat or the Q&A. Got another one here around, you know, is the automated fix pull request available now. No, but we are already have are starting the development on that we should be, we are aiming to release it in a very short timeframe. Hopefully in the next four to five seconds. Awesome. And quick plug there for the LFX newsletter, you know, definitely log in and join us if you want to get kind of proactive communication around those types of releases, we will be sending that out, you know, on to that newsletter channel. Yeah. Yeah, Stephanie, I think the newsletters were important. I think that that support is essentially our Jira desk that my engineering team monitors daily. Obviously, you know, if you have questions feel free to drop those in. You know, big again big shout out to our key strategic partner here's Nick. And as I said, like we are also working on other open source only projects out there which want to you know contribute to this initiative and be part of the stack right because we are not like, it takes a village to be honest. No single solution solves the breadth of the security challenges. It could be around badging, it could be around code, it could be around, you know, secrets, it could be around static analysis. It could be around IP compliance. So we are really looking for partners as well to help in this initiative. Awesome. Thank you. More questions in there. Yeah, so Linux, I assume why Bob, the question is basically like you're referring to the Linux kernel. Now the kernel the kernel is essentially CC++ so that's what we currently don't have support for and we have actively starting work on that. So we actually tried basic static code, you know open source utilities and we found a lot. But the point was like a lot of those were looking at like false positives. So we are actually trying to search for, you know, more mature static analysis solutions out there. But like upstream like the Linux kernel doesn't really have dependencies. So like, you know, our mechanism of manifest infection, you know, deriving the dependencies from manifest and then looking up the package manager that doesn't work for the kernel. Yeah. Stephanie I think he wanted to, is there a way to unmute. Sure, I can, I can unmute here. Just a quick note to everyone we are kind of at time but we will continue taking questions for a few more minutes here by Bob I'm going to go ahead and unmute you real quickly and then I see another great question that came through will address after that. Just give me one second here. Okay. You are, you can go ahead and meet yourself. There we go. All right, hello, am I audible. Yeah, I guess you are. Okay, so I think this is the first time I am actually on a Linux security conference. The idea that I am trying to put across today, when I'm taking two minutes of time of people who have great amount of knowledge about Linux is firstly. So first, I would like to talk about the history of how things have happened. I have read about the person who created unix. So, I forgot his name now for some reason. But I mean, so he created the kernel. Now he's come up with a new update I read about his biography and I was very impressed. But if we look at the legacy of how it later on led to say the creation of Android by Google, which led to creation of hardware by China and the way it has, you know led to creation of now so today you have something called a pine and you know, they claim that if you want to completely, you know, audited hardware in US kind of a phone that's going to cost you $2,000, $3,000. So that kind of speaks about security in terms of hardware, keeping that aside in terms of what open source also has done and not maybe say talk about what happened to Edward Snowden or maybe those kind of things like Julian Assange and those kind of controversial topics is the idea that there's always the idea of, you know, even if we create extensive security, there's always the issue that unless somebody can buy something like you know, startling kind of an broadband connection, sorry internet connection. We cannot be able to have real secure internet in the first place. So to have this kind of the idea of creating a secure operating system is always you know like what was this concept created by Godel Escher and Bach kind of a thing that book I read once which is in completeness theorem so you know there's always one way to look out. And I'm not talking about government surveillance or something like that but the idea that anybody can sniff around anyway by way of say sniffing on the wire that goes out by the internet or say by way of hardware. And these are glaring issues. I mean, I'm not talking about, you know, maybe a revolution or something but you know this is a big issue. Yeah, that's right. Yeah, that's right. Actually, we did start an initiative I don't have the time to get into that but we started looking at initiative from the silicone up security from the silicone up, right. Whether it's like, you know, not just the hardware like the firmware, you know, the hardware, the software stack running. You know, what's the different levels data encryptions like you know all through across and also on the network right for all the way from you know the layers of the network right so there is a larger project initiative that was started in the digital computing consortium. I think you should check that out that's basically trying to you know stitch these together, like in terms of the entire server stack and the network stack. Okay, but like, obviously, like it's a big ocean to boil. So from the LFX security we originally started more on the application stack and the software stack. You know, that's that's the thing like these communities are so, you know, distributed, you know, this initiative hopefully you know starts connecting those bridges but I would encourage you to look at the confidential computing stack. So I would have a look at that in fact the idea was to kind of conclude on this point with, I mean my point on this that if we really were to look at how technology moved from say the creator of Unix, who now sits with a server alone in a room where there is no one at all, but his own cat. The only thing we can really come up with tangibly in the real world is what Noam Chomsky said the idea of, you know, all those things that he says. And that doesn't really encourage anybody to want to go towards open source yet that is what we are doing now, you know, I mean, I mean Microsoft stocks are going up, but nobody wants to encourage Microsoft and open source on the other is moving rapidly and yet that I mean everybody has a chance to you know so if there's too much diversity. Anybody can exploit also so I mean this is becoming a very dangerous situation as it was say compared to 10 years ago or 20 years ago. And then as compared to say that there is no real globalization. True, no no absolutely and I can actually like even from a lot of the government agencies will be looking at like the expansion of open source. You know the trust trusted neutral bodies like Linux Foundation we have gotten a lot of requests across the industry to actually take the initiative on this. Okay, so anyway I would say like why but I would love to chat more with you like you know you can drop me a note. I think we have one more question if you're okay. Yeah, so there was one question about containers canning give you want to add some. We don't currently have a lecture, but let's answer that question let's spend like one more minute here because I know we are over time. So, yeah, give a kid. I'll answer it quickly so this is a. You can hear me this is a feature that exists already on the sneak side but we haven't yet integrated into LFX and in high level. It's looking at your Docker file it's looking at the different open source components that are being pulled into that container. So, similarly what vulnerabilities they have, and what kind of fixes that you can do, and also points out in terms of improvements you can take like picking better, better, better base images that have less dependencies and less vulnerabilities but are still likely able to run your, your application successfully. Thank you. And for any questions that we didn't get to or any other follow up questions, please, you know, we'll try our best to respond to the ones that we might not have addressed that have come through on this webinar. But if you have any other questions, you know, feel free to drop us a question on LFX dot dev slash questions, and we will get back to you. Thank you all so much for joining us. Thank you, she brought thank you gave us for presenting and thank you all for attending. We'll send the recording and follow up and please join us for our next one that that will be coming up as well. Thank you.