 Good day, John may I please confirm that my microphone is working. Hey, yeah, so I'm good. Thank you Hello, everyone. This is Shubhra. I'm just making sure I'm in the right meeting. This is the CIG CNCF CIG recruiting meeting, right? Correct. Good day, Shubhra. Yes, it's the CNCF CIG security meeting. Perfect. Awesome. Thank you. All good. Hello. Hey, Matthew. Hi, Brendan and the belated happy new year, I guess. I've been off the radar for a couple of months now. And yeah, this is a 22-1 is going by Craig. Oh yeah, thanks so thanks for helping to facilitate today, by the way. No problem. At some point, I might actually get to jump on and do some security stuff in addition to the facilitating. Just as I thought, I had sort of a break. I just had a lot more responsibilities sort of lumped on me at home and at work. So it was just had to budget my time. But I'm going for my PN soon. So there's a plus. Nice, nice, nice. Good luck with that. I hope you get it. Thank you. I hope I earn it. We have a disclaimer, I think now at the beginning, like we remind people this is recorded to YouTube and follow the CNCF policy on how to be nice to each other, right? Or talk professionally, I should say. Yeah. Got it. I'll scribe today. Thank you. I was going to post the data I saw in the email and I was like, cool. I'm off the hook. I'll scribe since I'm here. I should be able to chip in more frequently now. I just had like a big hurdle I had to get over and it just didn't really leave much time for the fun stuff like this or professional development or nothing. So I should be less of an on and off the radar and more consistent, I would say. Awesome. So let's see what do we get planned for today? We just go, there we go. People are born and that's it. Okay. So give it another two, three minutes, do the disclaimer, get it underway and it's recorded if anyone wants to backtrack. I wish I had that mechanism in life. I can just backtrack. Don't we all? Where did you get the container D-shirt from, by the way? Was that a conference? Like swag? Like how we all get the stickers at the... Well, as a CNCF ambassador, I can tell you there's the store, the CNCF store. You can easily go and get this shirt, mind you. And I'm not paid to do this. I just have just everybody, public service announcement. Thank you. No worries. It's actually really super comfortable. I'm not even trying to sell it again. Super comfortable. I think it's somewhat polyester cottony. It's nice. I got a little micro Kubernetes one at a conference a couple years back for my son who's now six. So if he sees me wearing my now worn and old Kubernetes one, he sort of instinctively knows, I don't know what it means, but I'll put on the micro Kubernetes one and stand next to dad. So you get the sort of K and S micro K and S joke going. That's awesome. That's good. Okay, we're a couple of minutes in. I'm just going to double check here. All right. So we'll, I guess, officially get things underway. So before we proceed, good day, everyone. Just a reminder that these meetings are recorded and automatically uploaded afterwards to YouTube. So all members are asked that by taking part in these meetings, they're agreeing to the CNCF security policy on behavior and conversing on this channel. It can all be found in our on our GitHub page in the repo if anyone wants to look at it in depth. And with that said, first and foremost, we'll go for scribes here. See who we can get. So I believe Brandon, we already have you volunteering for that role. And if anyone else wants to pick up a scribe role as well, please feel free to jump in there. And I believe Brandon's already posted the links in the chat to essentially the signup sheet and the document will be going over today. And with that, we shall jump into this. So general standup and check-ins from partner specialist groups and working groups. Is there anyone on the call today from a CIG working group or CNCF that has any topics they'd like to raise or any presentations to cover? Okay. I'm with the next one then. All right. So then from here, the plan is just to go through the general topics we already have on the agenda. And then afterwards we'll open the floor if anyone wants to bring up anything related to specific ticket or pull request in our GitHub instance. And then finally, just general open floor if there's anything anyone wants to bring up in general or if there's any new attendees that would like a chance to introduce themselves. So the first thing I have on... Yeah, Matt, sorry to interrupt. Yeah, this is Shubhra Kaur. I think I had the presentation on the agenda. I see one here just to confirm. Is that the one? Yeah. LFC and CNCF security scanning? Oh, yes. There we are. Sure. By all means, please take the mic. Yeah. Matthew, there's a couple that are popping up that I'm going to copy them into the table and then we can cover them up. Okay. Super. So yeah, do you guys want me to go first? Yes, please. All right. Okay. I'm going to screen share. I have a few slides, but I wanted to actually also go through the actual product that we have been working on. So let me go ahead and share my screen. One quick question. Should all questions be held to the end or can they sort of pop up as we go along? Yeah, we can take it on the fly. Like I didn't come up with a proper webinar agenda, but I wanted to bring this as more of an open discussion. Gotcha. Yeah. All right. So just by means of introduction, my name is Shubrakar. I'm the CTO of the Linux Foundation. And I have a decent engineering team and we've been working on a bunch of tools for all Linux Foundation projects. And many of these tools we've been building from scratch, I wouldn't be able to walk you through all the tooling. I'll focus on security. And for security, what we have done is we cannot build everything because obviously my team is not a group of security experts. So we have partnered and with a lot of SCA vendors and come up with an integrated solution where we can all Linux Foundation projects and sister foundation projects, including CNCF, can gain the benefits. So for security, before we go into that, this whole platform, this LFX platform is a set of digital tool chains. And our goal is to build more sustainable open source projects. And as we are like, how can we help these projects succeed? Obviously, I'll be preaching to the choir here if I tell you how strong our community is and how it's been rapidly growing. But we start hitting issues around scale, we start hitting issues around like how do we manage best practices across the board. Security in particular always becomes kind of an afterthought. It's not embedded right at the development tool chain. So how can we make that process better? So by way of introduction, you can check this out later. There's a website called LFX.dev. And then you can find context around each of these products. By the way, like CNCF is already using many of the products in the tool chain. So if you're looking at like CLA, Kubernetes, GRPC, OpenTelemetry, a lot of those projects use easy CLA. We have the mentorship tool, which most CNCF projects did active mentorships last year. This year, just yesterday, I approved like 30, 40 mentorships in there. Crowdfunding was another one that was used. Landscape actually came out of CNCF. And we have tried to productize it and make it available for other projects to use easily. Community events, like if you go to community.cncf.io, that's basically using this platform. We have a member enrollment, which is essentially for your auto joining. We have a training portal where all your Kubernetes certified administrators, developers, all those trainings and certification exams are running on that platform. Insights is a net new product. CNCF has not been exposed to that yet. Other projects have already started adopting it. In case of CNCF, you had DevStats platform. Now, the same developers are working on insights. And we have expanded the scope of what DevStats could do. So this would be really good for you to check out. And eventually, we want to drive adoption because there's a lot more metrics around the ecosystem, not just code. And today, we're going to deep dive into security. And then there is a solution called an individual profile or an individual dashboard. This is around like your SSO, your credential management, your code attribution, affiliation, trainings, events you are speaking at. It's creating a global community profile for every member of the community. So in security, it's a shared responsibility. We all want to drive that. But again, the key things we were trying to solve from a solution perspective was we had all these projects being worried that hackers will exploit our code. And it's like chicken and egg. If you think that hackers need a tool to find out where our code weaknesses are, then we are kidding ourselves. They already know where these vulnerabilities are. So we have to get ahead of the game and identify these ourselves and identify a way to quickly fix these vulnerabilities. And there are other projects, not the big Kubernetes of the world, but there are 400 projects in the Linux Foundation. And our projects, many of them don't get enterprise adoption because primarily like enterprise adoption, a lot of times that sustainability means security. And some projects fail to pass the stringent security gates because like most of the enterprises do use their own security scanning tools. And many times we fail to pass that gate and we never know about it. And exposure to IP risk. Now, when I talk about security, IP risk is another element. It's not just the code. Licensing plays into that as well. So code is made in a sandwich. It's a stack. It's not just native code like the Linux kernel. You have dependencies. And whenever you're using upstream packages, each of them comes with their own licensing regime and whatnot. So how does the project know what is the software build of materials looking like? And more importantly, our community needs to trust our code base. So it's critical that we provide that transparency. So how can we do it in a more transparent manner? So we put some projects initially. Like we started like a beta process, like this product isn't GA yet. That's why I call it beta. So we started building the first vendor we partnered with was called Snake. But very shortly we have other vendors in the ecosystem who are partnering with us into this common solution. We scanned 10,000 plus repositories. We found almost a quarter million vulnerabilities. And a lot of these vulnerabilities had easy recommended fixes. Those fixes could be in like, hey, upgrade this dependent library. And I'm not saying those vulnerabilities are in the native code base. Those vulnerabilities do include your upstream packages that you're using from other projects. And we found out, even without using our reports, a bunch of these vulnerabilities have been getting fixed. But they have been getting fixed opacally, not because like somebody used a better module or a library upgraded that library version with not security in mind, but maybe with functionality in mind. So we're detecting these patterns. I will walk you through the tools and what we have discovered so far. So primary you have built it for three stakeholders. So if you use most SCA tools as is right from the vendor ecosystem, whether it's GitHub security, whether it's like Snake on its own, or you have like white source, there's so many players, black duct software, synopsis, you name it. A lot of them are like based on a view of defects that are injected or being tracked or responsibility. The accountability lies with an individual developer. None of these tools have been able to give us an overall global view of where that project is. A project could be made up of multiple GitHub orgs, thousands of repos. There's no collective aggregation. There's no collective reporting. And if there is an action to be taken, it's not just one developer working. So can we take collective action? So what we did is we started building these views. Number one is obviously the project maintainers and contributors. And I think the biggest benefit is like saving time on the security research. Because the bugs we are capturing, it goes through a verification process. So in this case, we are partnering with these SCA companies and they have a bunch of research people who are vetting that these are actual bugs. These are not false positives. And then obviously, as you scale, how can you put multiple people working on these fixes before these make it through a gating process? Now, for the governance perspective, talking about gating, can we focus on security best practices for day one from the development? How can we integrate it with the developer workflow? Like with EZCLA, what we had done is like we tied it to your PR process. So whenever you make a commit or you are submitting a PR for upstreaming, that's the point like gating happens around CLHX. Now, can we adopt a similar workflow like in terms of building some GitHub apps? If you are on GitHub, you could be on other sources where there is like a gating process that gets injected to make sure you fix these bugs before the PR can be merged. So there are suggestions. We don't have that gating implemented yet, but we are working on that. Creating badging. So we had this big initiative of CII, core infrastructure initiative from many years back. It was a trust-based system where people were submitting their projects, some best practices, documents, and they were getting passing, failing, in progress, gold, platinum, silver badges. And these badges could be displayed on your GitHub repos and then there is the global view. But can we expand that beyond just best practices and actually make it part of the tool chain? So again, that's very useful from what we heard from as a feedback. And obviously from a governance perspective, you do care about the proper licensing, not just in your native code base, but also like enter the entire upstream. And obviously, members and corporate sponsors, they essentially are giving the money to sustain these projects. And for them, it's important that they protect their investments against the risk of security vulnerabilities. They quickly identify which packages are enterprise ready, which are still not. So earlier when I was talking with some members of the TOC, they were thoughts around like, hey, can we make it part of our graduation process? How does an enterprise know whether this is ready or not? And again, it all comes down to the circle of trust. So there are some features. I'll actually walk you through the tool. But in terms of the features, we have a centralized dashboard for every project. And then we also have aggregation views built across for project groups. So you can look at Kubernetes on its own, but you can also look at CNCF holistically across thousands of depots, right? We have automated vulnerability scanning, these cans run on a daily basis. A lot of evidences, like when the bugs are logged or these issues are logged, there are evidences that are attached. These evidences could be GitHub commit, it could be a security advisory, we have integration with the national vulnerability database. So if you're tagging it with the Mitre database, I don't know how it's actually pronounced. But if you're looking at CVEs and CWEs that are already logged and indexed in the national NVD, you actually have specific evidence that this is a real bug. Many times there could be hacker reports from bug bounty programs or whatever where developers are throwing evidence how to recreate it. So we capture all those evidences and attach it to every bug that we find, right? We scan the entire app structure. Obviously, this needs projects to have manifests so that we can actually scan the dependency chain and present you a view where you can look at the entire dependency tree. But you can also identify along the dependency stack if there are packages that you're using and those have vulnerabilities that you can identify that makes your life easier to either upgrade those packages or swap them out for some other packages or libraries which are not that vulnerable. And we provide a bunch of fixed recommendations. Now these are recommendations. You have to take it with a grain of salt because these are recommendations that we found other people issuing a PR to fix some vulnerability. But you do have to analyze before you go ahead and just implement it. So the owner slides with the maintainers of the project or the contributor of the project. We also have a license discovery and for every module that you are using as well as your upstream, we have also started plotting releases. So for every repo, and again, this is again based on GitHub versioning and whatnot. But if there is a visual correlation that we can establish like saying, hey, this big release happened. And with those, your defect injection rates went up or down or whatever. But net-net, we are trying to build a system which is neutral to any source control system. So whether you are on GitHub today, whether you move to GitLab tomorrow, you are playing Git, we don't really care. We want to build an agnostic platform. So I'll jump right into the demo and then I'll also walk you through what's planned from a roadmap perspective. So here's how you access this tool. So if you go to LFX.dev, you will go and you'll find all these tools. But we have a menu where you can see this is security. So if you just say security.lfx.dev or security.lfx.innexfoundation.all, you get to this console. So this is the global reporting console. And what we have done is we have aggregated projects under project groups. So I'll walk you directly into cloud-native computing. And you can see like these are all Innexfoundation projects, right? And we have 400 of them. So if you go to these projects, we have created these aggregations. Now again, these are from reporting perspective. You can also see there are projects which we were not able to scan fully. These were like partially scanned because a couple of reasons. One is we cannot scan it properly if some of the repos are missing manifest files because the entire technology here is dependent on manifest creation. The other reason could be we simply don't support our language. Now when we partnered with Snake, we know like they have some limitations. And that's why we are expanding the partnership to other vendors as well to get like 100% coverage. But there are certain languages like C, C++ that they don't have support for yet. So we're looking at other ways to get that support. So far you can look at the issues that were captured. These are not like GitHub issues, but think about them as like bugs. Almost like half of them you can see here are actually fixable. And when I say fixable, these are like quick, easy fixes, right? Without doing like massive code change. These could be library upgrades and whatnot. And we found quite a few upstream dependencies and about like 1500 licenses. Now again, these are across projects. Now each project has a project card. So let's say I jump into something like Kubernetes, right? Now again, we haven't been scanning this for a long time. So you can go and look into like a time range, right? Like a relative time range and whatnot. So I'm just going to walk you through here. So you can see here like these are like, you know, these are indexed like in terms of severity, high, medium or low. And that severity is determined by a CVSS score. I'll get into the details if you guys are interested. But along with that, we also start plotting the releases. Now this is a little tricky one because the project might be doing one big release. There are some projects that follow that waterfall model. But many of these versions are simply based on repos, right? So all your major repos might have their own versioning. Now this may not be actionable data, but at least if you're trying to look and filter for a particular repo and you see like a big spike happen when a particular release was cut, it at least give you some visual correlation. We are also scanning all the languages. And on the code base, like, you know, that particular project, let's say, you know, we are doing like 700 repos. What is your language distribution, right? But more interestingly are the issues. So issues are where we have, you know, collected all these vulnerabilities. And obviously you can break them down by individual repos. And I'm going to bring up a couple of examples here. So this one here, Cloud Provider Azure. I'm not picking on anyone, but just as an example, right? Let's say I view these details. I can see, you know, each of this is a bug and it has a type, you know, and you can see the indicator, like some of them have a weakness enumeration number, which is coming out of the NBD. Some of them are actually a vulnerability as well. So and then, you know, you can find out if this is fixable or not. So let's, let's expand one of them. So this is an arbitrary file overwrite. And because we are integrating with Snake, you know, you can even look into further details on the system, but we provide the credit to whoever found that vulnerability in the ecosystem. This one looks like an extreme package, right? And affected versions to this package are vulnerable to arbitrary file overwrite. And when we start looking into what are kind of, you know, evidences. So if you look at a GitHub commit, you know, you can essentially see there was a GitHub commit, which actually identified this. Or if you're looking at like, was there a security advisory for this one? And again, this is for that stream package. Now, in this case, the remediation might be something as simple as, you know, you know, upgrading. So if you upgrade their stream from version to version 1.0.12 or higher, this vulnerability is addressed already, right? So this is the simplest of simplest fixes, right? So we are providing that. Now you can create a GitHub issue, you can click this one, and it will create a GitHub issue for you. Obviously, you have to authenticate with your GitHub credentials. But then you can essentially create a backlog, right? It's not in the system, but it's integrated there. Short term in our roadmap, we are also going to introduce a button which says, fix this issue, and it will auto generate a PR for you. So, but again, as I said, it's a, you have to take it with a grain of salt because you might not want the system to automatically generate the PR code. You might want to do it yourself. But we are giving that option, right? If it makes life easier for the developers. So I'm not going to walk through all of these issues, you know, I'll tell you how to get access so that, you know, you can investigate a lot of those. But I'm just going to pick up another one which looks a little different. Let me go ahead and minimize this. And let me look at like another module here, cluster registry. Let's look at what does that have. And this one is like cross-site scripting. And these are like again, fixable. Now, here you can see there are references, there are a number of blogs that reference this issue and number of GitHub commits, GitHub issues, and there's even a GitHub PR. And when you start looking into, you know, the CVE associated, this is actually an already indexed bug in the national vulnerability database, right? So they actually have all these references, they have like steps how to reproduce it. You also have, again, this is the mid-trade database as we know it. We also have the weakness enumeration before this became a vulnerability. So you have like pretty much all the details that can be helpful in terms of how to resolve this. Okay. So moving on like from a dependency stack perspective, like how is the sausage made in the sausage factory? So what we have here is essentially, this is your entire app dependency tree for every package. So you can look at this is like distributed package by package. And you can look into your upstream as well. And some of them, you know, you've identified there are vulnerabilities and some are clean. But if you wanted just a vulnerability only view, we filtered this whole list so that, you know, you can actually just focus on fixing these, right? And in particular, like which particular library your package has that, okay? We are also determining licenses. So if you look at your license tag, these are the different type of licenses that are currently used in not just your native code base, but also your upstream. And so if I were looking at, let's assume, you know, Apache 2 is pretty permissive, but if I were to pick something else, and again, it's not a question about permissibility or not, but you're trying to find out a license type, which maybe you should not be using, right? And you can look at like, okay, this license type is used by these packages and within these packages are contained in these repositories. So you can essentially create an entire software bill of materials. In our short-term roadmap, there is a policy engine that we are writing. It's kind of a rule-based engine, like if you're saying, hey, if we detect a particular license type and you know, you're not supposed to use it in terms of your application architecture, then flag it or create an issue, right? And finally, if you look at a settings tab here, many times, you know, when you try to weed out false positive, there could be dev dependencies, you know? Like I did a lot of Node.js coding earlier in my career and Java. Many times, what happens is like, you know, you use like dev dependencies to the chains, I'll give you what goes on or off, because, you know, some of the unit testing tools, you might not want to scan those in production because they don't really care for you. Yeah, so like dev dependencies are key, right? Like you are always worried about false positive, but maybe, you know, if it is a production system, you don't want to scan dev dependencies, maybe eliminate like, you know, unit test tools or whatever. So we give these flags, but again, these flags should be maintained by probably a group like you, right? Like, which is the SIG, like, you know, who are setting these best practices, okay? And then you can also selectively say, hey, you know what? This repo is archived, let's not scan it anymore. So you can design these best practices. In some cases, you can see here, we have, you know, errors that we are not able to scan. So you can see here, like, you know, we could not find for this repo, it might be using some language and we are not able to scan it because we don't support it yet. Okay. Now, this is what we have built so far. I'm going to quickly show you a little bit more that we are working, we are adding a net new functionality for code secret scanning. But how do you get access? That's the first thing, right? So, generally for everyone in the community who is a contributor, who is a maintainer, is part of our technical committee or like some kind of a governance body. If you go to projects and like, I have super admin, so I have access, you'll see an request access button and it just pops you a simple form saying, like, okay, I'm maintainer of such and such project, you know, give me access, right? And we open it up. However, you know, we don't want to throw it open for the entire internet, right? So that's why we have this. Now, I'm flexible on this policy. If you guys tell me like, hey, open it up for the entire community, we could go that way. But I'm going to leave that decision on. Okay. So, going back to my deck here. So, I showed you what we have right now running in production. And in this year, as I talked about like an automatic PR creation process, we are working on that. We are already working on a code secret scanning. In this case, we are actually partnering with another vendor where, you know, we can detect some code secrets. And I have a simple report. I might want to be able to pull that up. Some things we have detected. Again, the key there is to read out false positives because, you know, if you have a dev system or if you're putting in AWS keys or your PEM files in there, you know, you know, you don't want to be exposed. Many times coding wise, when somebody is developing it and putting it in a build system, they might use a key. And with the assumption that they're going to take it out when it actually is the master commit or it goes into like, you know, running in production, but Git keeps your history for sure, right? Anybody use scanning to the Git will be able to find your secrets. And there are different best practices around that. But in H1, we are also looking at creating that comprehensive security badging. We have CII today, but we are trying to create a security index and tied to a digital badge. In H2, we are looking at enabling like build system scans, as well as container scanning. And the software bill of materials and policy management I already talked about, which is around the licensing. And, you know, how do you define those policies? One thing we don't have today is CC++. So this is definitely a roadmap item for us. And we have a stretch goal of static code analysis this year. Not sure whether we'll be able to make it, but you know, I'm challenging my engineering team to work on this. Okay. So open it up to questions, but I do want to share one report. I would not be able to send you the link. I'm going to send you a snapshot. So this is around code secrets. So we are actually analyzing whatever we have discovered. You know, we'll put a UI on it, you know, put it into the security interface. But some of these we discovered, I wanted to give you a heads up, like we found everything from, you know, API secrets in some files. Again, you know these ones. Now this might be false positives, but there are other projects we looked at where, you know, passwords are set up in environment files. There are private keys that are like actually committed to GitHub. You know, instead of using some kind of a key manager, you know, let's assume like Walt or whatever, people dropping these right now. It's multiple risk. One is like, you know, in some cases we found hundreds of contributors dropping their, you know, keys in there. And again, those users accounts are at risk. And again, but if you use a proper key management system, or there are, you know, certain things like cryptographic key bundles, we have found evidences of primarily a lot of secrets and keys in packet capture files like pcap files, right? Even somebody replays it, you can easily find that out. There are keys like, you know, does the JKS keys found in the repository itself, there are like, you know, password assignments in JSON files. So a lot of these, we are doing a fact check, working with these projects one by one to identify like, yeah, these are indeed issues, and you should be fixing them. And trying to read out false positives. Many times, you know, you'll have like, hey, this is a markdown file, and you know, you have a key floating out there just as an example. You can't do much about it. It's just an example. Right. And that's not a real one. So we're trying to go through this list. And once we come up with like this actual solution, it will, in the same interface, we will think about like in the same interface, you will probably have like another one here called code secrets, and we'll automatically discover all the secrets for you. Okay. And then it's up to you to, you know, identify what are these are like false positives, what we are trying to design a regex based pattern where you can say, okay, this is kind of a pattern on the regex, and the regex could be your hash commit. Sorry, your commit hash, and you can say, okay, anything with this commit hash, just, you know, ignore it for now. This is maybe not a false positive. Right. So anyway, that was pretty much it. I'll open it up to questions and more feedback. I think as a tool, it looks great. I don't know if you're keeping an eye on this sidebar chat. I think for those of us who have sort of run these scans before and gave them to developers and said, Merry Christmas. The interesting part is how do you, and I understand we're talking about tools, but then the next step here, I think is how do we help those developers actually understand those results that we just threw at them and help them actually process and fix. And I know that some of these more modern tools are starting to have auto fix buttons in them. But have you guys talked about that or run it that long? Yeah, so I think that's actually a good question. So yeah, there are bugs, but what we are also trying to do is like, we had this big initiative. We started at Harvard called the LISH, L-I-S-H initiative where we invited all these SCA vendors and we are actually hiring, like we actually hired a security expert ourselves. His name is David Wheeler. He's director of security for open source and he's providing services across multiple projects. He's also involved very closely in the CII initiative as well as the OpenSSF project framework. Now, what we are trying to do is like, obviously it can't be just written by one person. So there are like evidences that you can find like what those bugs are and whatnot, but in terms of like setting up best practices, we are trying to create at least a pool of subject matter experts who can provide these guidelines. But also what we are trying to do is if the projects can introduce their best practices themselves early in the tool chain saying, hey, you know what, let's make it part of a graduation criteria. Like when I say graduation criteria, maybe it doesn't go from sandbox to incubating unless you are like particularly at this level of vulnerability cleanness. Not sure whether that answers your question though. I think sort of I'm trying to give others a chance to chime in. I think what I was talking about more is not so much, I mean, what you said makes sense again end to end, but I don't know, let's pick, you know, you have staff in there, let's use that as an example. You suddenly set them 50 or 60 issues. They didn't have their own, they might, Red Hat might or that organization might, but how otherwise do they deal with suddenly going, okay, well, what do I do? Am I using the right type of Shaw checks on this example? How do those end orgs, how do we help those end orgs do that? I mean, I saw this, I saw this sort of, to give another example, back at CloudStack days, I brought in Fortify, we had to run SCA scans, we had the results, gave them to the team and they're like, so that's sort of where my thinking is coming from. Got it, got it. No, that's excellent. So today we don't have a hybrid way of like, you know, behind the firewall connecting it and a lot of these enterprises or end users use, you know, run their own security scans. So one thing I'm looking at is like, you know, we might be able to expose APIs now where, you know, they could either use this data, like they can pull this data downstream. Now, these reports that we have, they're all exportable, but an API is definitely more efficient way to scale. And obviously, we have an API gateway that does all the auth and everything, takes care of like the provisioning auth and validation and all. But this is actually a request come in where like, you know, our member company said like, hey, is there a way for us to publish vulnerabilities we found downstream into your global index? Or maybe, you know, if we can even pull down these with essentially a public API, when I say public API is obviously with keys and all, you know, an authenticated API where they can actually consume these, that might be the way to go, right? And again, I don't have a solution out of the gate. But those are some recommendations that came in. So I have a thanks for a great presentation, Subra. Also, I just want to try to understand the scope. So this is a, I mean, what is the availability and the consumption? How do you, is this purpose built for the Linux foundation? And obviously, it's got a lot of the, those projects and all the associated projects. You know, but what is the, how do you get more adopters? What does that framework like? Yeah, so to answer your question, yes, we purpose built it for the Linux foundation projects. However, it's more of a, so we have some operational costs because, you know, we are spinning up like hundreds and hundreds of containers and scanning and aggregating these results and whatnot. So, so far, we have limited the scope to any Linux foundation project, you get this service, right? So that's how we built it to scale. However, onboarding a project is fairly simple. You know, there's an app, like I'll show you the app itself through this window here. If you wanted to bring in a project which is not under the Linux foundation and, you know, you say, okay, hey, secure my app. And, you know, you have like this thing like, okay, sign up. And then when you're signing up your project, you know, you give the project name, a category and elevator page, why should we be scanning it? You provide us the repos. Now this could be a repo URL, it could be an org URL. And, you know, if you have a CIID, we want to encourage those best practices. And who would be the key contributors who need access to this data? So if you get a request, it puts stuff in our queue. And at that point, we take a call because from an operational standpoint, my team does, you know, take the infrastructure called we are eating it as part of the Linux foundation global effort. But I think we are open, right? As long as, you know, that's not a project that, you know, just some enterprises trying to bypass like, you know, their security spend, you know, we are not a tool provider end of the day, right? And so we are open to, you know, onboard projects which need this. And, you know, they are not able to, you know, they don't have the either the budgets or, you know, they are more aligned with like the open source ecosystem, they may not yet be part of the Linux foundation. But yeah, we are open to offering it. I'm just being watchful of the cost element in this. So in those cases, many projects have like, you know, they're raising money through crowdfunding. And if they are able to, you know, pay chain and like maybe just cover the pass through infrastructure cost, I think we are more than willing to entertain that. But the way we structured it earlier, we just had like flat projects. But then when we started aggregating those, we said, okay, there could be one project, there could be projects within projects. And we are trying to create these global views. And then like the access control of this, you know, like there is a profile, you know, you can basically get your profile, every developer contributor needs to have a profile that manages the access control. So we have tightly integrated it. But yeah, it is pretty much at this point, you know, tailored for Linux foundation projects. But we are open, right? Like technically, it's absolutely doable. It's more of a governance and business question, if you ask me that way. I got it. Thank you so much. I appreciate that. I wanted to bring up, we have about 20 minutes left and a couple more presentations and a ticket to bring up. Shubra, I wanted to thank you for this. And B, I wanted to ask if there was a way that people could address additional questions your way, like an email link, or if we should open a ticket in our GitHub page, I can issue there and people can post there for Q&A. What's the best way to follow up with you? Yeah, so we have a support channel. This is essentially a Jira desk for us, service desk for us. We have a questions form as well. And you have my email. It's just skar at linuxfoundation.org. I'll be more than happy if you send me questions directly on that channel. And, you know, all these dev questions and support questions, these are just Jira tickets. They fall into our queue. So I think that would be the most efficient way. And right now, as we get to MVP and basically open this up beyond beta, we're just going to publish it on GitHub. So issues would be a great way to collaborate. I just want to kind of quickly mention one point I think that we should follow up on from a security perspective. When I saw this, the first thing I thought about was the security evaluations and the CNCF TLC process. I think this is something we should definitely think up on. And maybe somehow we can get access for maybe the co-chairs and technical leads for security. We can also help with some of that work. What do you think about that? Do you think that this is something that you're kind of seeing? And I know there was some, you had some plans to have after the first half to have some badging system. Although I think that there's a lot of discussion within that of what that would look like because of the more complexity that brings a bit. So I think just on this front about including this in the CNCF project process, how should we go about to engage on that? Yeah, absolutely. So I am already part of your SIG Group Slack channel. So, you know, if we have a discussion going on, I would definitely like to include both myself and David Wheeler. Like if you have like a governance committee call on this process, I would like to definitely participate and bring my input from a roadmap perspective or from an engineering perspective. And we'll also share upfront, like as we are starting to design those, we'll be pretty transparent. We'll be openly sharing how we are designing it, how the architecture works. So yeah, feel free if you want to invite us to one of those, you know, discussions more than willing to join. This is such a value for any project coming in. It should be marketed as such. I mean, I had no idea about like if there was a cliff note of some sort that any project coming in, this should be a selling point for the CNCF for projects. Like this is so much work that you all put into it and all of that. And the various tiers that are there. And I'm sorry, Matthew for bow guarding and meeting, but just like it's this is fantastic. This is a fantastic presentation. Thank you. I really appreciate sorry, I was muted as saying, awesome. Thank you again. What I'm going to do then is quickly go through what we have on our list for today. And if anything runs over, it's just a few minutes we'll keep it going if it's going to be significantly longer than we may have to shelve it. So I'll try and push through as quickly as I can. All right. So the next thing I have up here is from Pushkar. And if I ever mispronounce anyone's name, please feel free to chime in and correct me there. And then GitHub issue number 480 Pushkar. Do you want to grab the mic? Yes. Can you hear me coming through five by five? All right. Okay. So yeah, I'll be quick. I know Mark and John have other items as well. So basically the issue is about trying to build a process so that we'll have a sustainable way to continue to update the cloud native security white paper. We have had some good feedback over the holidays. And now that I'm back, I wanted to start that process again. So basically, we have a meeting set up for it as a starter meeting on a week from now, nine o'clock Pacific, just before the security landscape slash geography meeting and before our usual security meeting. So that set up to discuss more on what needs to be done, discuss some of the comments we have. If you want to be involved in that, I would request you to send me your email address of your choice on Slack. DM me, my Slack handle just PJ like the pajamas. So from there, I'll send you an invite and then we can get started next week. All right, I'm done here. Thank you. All right, on to the next one we have on the list here we have Mark Underwood. Mark, would you like to grab the mic? Sure. Hi guys. This would be really short. I just wanted to give you heads up about a couple of NIST things that are ongoing in the last week or so. One is the DevSecOps and Zero Trust architecture presentation. There was a fee to join this 15 bucks US. Some really good content there. Represented some of the Air Force DevSecOps frameworks. But some new stuff I was not aware of on next generation access, micro segmentation, different flavor of that. But NIST is pushing pretty hard on a new way of looking at service mesh as a way of kind of reframing the access problem in a way that's more scalable. So that was pretty interesting and yeah, I think you can probably grab the artifacts from that without having to do the whole replay. Also, today they're running the second day of their workshop on OSCAL. I'm not too knowledgeable about that, but there's some, those of us in the compliance industries, if you want to call on that, that's some use to us because we got a produced documentation about our security plans and there's an attempt to automate some of that that's going on. There's a link to both of those in the scribe section of the notes. That's it. Thank you, Mark. All right, scribe section of the notes. A quick question, Mark. The seminar you were mentioning there, I think it was like had like a $15 entrance fee. I can't see it in the notes here. Maybe it's not updated with the latest scribe notes. It's at the top. It's under 10. Ah, thank you. Okay, if there's any questions for Mark, I'll move on to the next one. Yeah, since you gave me another 10 seconds, I also attended over the weekend in COSY. This is a professional society of systems engineers. They have a security working group and I frankly don't know what's in there yet, but if anybody's in that group, I'd be interested in connecting with you. Great. And last but not least, we have a final presentation from John. John, do you want to grab the mic? Yeah, sure. Thanks. Just want to give a quick update. So a few of us responded out to the SIG, I keep screwing up their name, SIG application group. So excuse me, SIG app delivery to help them with their white paper for operators. So we're starting to help them with that. I think Cameron and I are in there. Hopefully we'll go get one or two more. We've got about six weeks to rough in some of the concepts for that and we'll keep showing on that. Anyone wants to help? Happy to take more helpers. Awesome. If you would like to open an issue, and then we can kind of share this as well with those that are not on today's call. Thank you, John. Okay. And for the last little bit here before I open the floor, if anyone else wants to throw any more questions that our presenters used the last few minutes we got, are there any new attendees on today that would like to take a few seconds to introduce themselves? Yeah, I don't think I see that here in the list. Okay, I'll take those and oh, we got another 10 minutes if anyone wants to throw any more Q&A at our presenters and otherwise we'll call it a day. Yeah, I think just to read out, I think there were some questions about the SBOM model. So currently, we have a couple of people in our legal slash project governance team who use the SPDX model. And that has actually been working very well with us. So again, we do that manually. So one of the goals is actually automate on top of SPDX as a minimal viable product. But we'll be also open to like if there are other standards that come around. But we are initial MVP, we are trying to do with the SPDX. And like even if you look at some of those license files that we detect in our security tool, those are all actually linking back to the SPDX references. Yeah, good to know. I asked that because, oh God, OMG, I think it's trying to stand up a new standard on that. But I don't know how far that's gotten. I have one question and this is probably something that still needs to be fleshed out because it's a very broad one. But on the topic of badges earlier, from my perspective, if I understood it right, those were from a sort of team or project perspective rather than say individual user. Would those eventually break down in granularity so that maybe you have one or two, for lack of better term, reportees or lieutenants or however you want to put it per project? Like let's say non-ideal use case, angry sysadmin sort of thing. And maybe a company is still reputable, but an individual bad faith actor that fortunately no longer has access to that, embarrassed them or did something they shouldn't. Does the roadmap have something sort of along the lines of this vendor is still trusted, but this individual is not or this vendor is temporarily entrusted till they get stuff back together and then we'll give them back their badge status. Is that sort of in the rough roadmap? Not at that level of detail. We definitely have thought about projects. Yes, Lambda, we already have that structure. We are looking at like contributing organization or a contributing individual. But we haven't like broken down the rules, as you mentioned, like this person has left the company or like they are kind of a rogue player. So we don't have those details yet, but we have looked at like an individual company and a project. Those are the three structure we are thinking of from a badging perspective. It does. My follow-up was going to be and I'll defer this, but was having each individual contributor have like say a trusted signing key for all their commits and contributions, like really tie an author to a contribution, but I'll show that for later. Yeah. So if we have one minute, I want to show you a little bit something here. So if you look at security or like even if you look at insights, this is another one I should ask you guys to check out because we are collecting all the developer contributions. And if I have to just pick any random project here, this is an academy software. I'm just going to pick up this one. I'm probably not a common one. It's not a good one. Let me pick up just Kubernetes. If you look at all this data that we have and you start looking at all the individual contributors and the companies who are making these commits and if I start looking these up, this is actually your data is on insights. Eventually, like we are building much more where DevStats++ think about DevStats++ and you have all these commits by companies, commits by all the individuals as well and which line they are adding, how many lines they are adding and all that kind of stuff. And then if you look at a person's individual profile, this is my global profile. And you can see we have this concept of digital badges. Right now, we are pulling these badges for speaker badges, you have badges for training, you have badges for certifications and whatnot. This is where we are looking to also not just at the repo level, but also at the individual profile level like pull those badges. Now, the project's badges will be obviously within GitHub as well as on this reporting console. But we are trying to try that digital badge for an individual in terms of like a security index badge. Think about it that way. Just to give you the concept of how we are looking at this. Thank you. That shows more thought than I've given credit to put into this. That's awesome. Again, something that could be marketed. Hey, wow, I'm a certified, you know, secure developer. I'm sorry, I'm not thinking with like a sales tab, but I'm thinking in general, it's like a total good way to have people get involvement, understand, and all that fun stuff. It's really cool. Are the certifications in there, I guess, do they all come from a single training or authorization entity? Like could people throw in stuff from say Linux Academy, Cloud Guru, or even throw in something like if they have a PNG or RPE designation or stuff like that. What's the sort of source of truth for these badges? Yeah, so today our source of truth is the Linux Foundation runs a certification platform and a training platform. So we track the course completion and exam attempts and all that, and those digital badges are generated there. So that's what we are pulling from currently. And then like all our events, right? If you're speaking at KubeCon or whatever, we do give out these digital badges for speakers or like program committee members. So we are using credly as kind of, you know, that system for badging and like we pull from there, right? And we have integrated our training in events. Now, this is all tied to identity, by the way. So this actually has come up like because we build this entire thing as a Linux Foundation global identity. But for us to go and reach out to badging from let's say Oracle, Red Hat, or maybe, you know, not a corporate, but like an organization that's providing, we need a distributed identity system. And OAuth2, which is the original implementation, like there is management overhead and not everybody is OAuth2 friendly. If they were OAuth2 friendly, you know, we can, we have federation capabilities where we can integrate and pull those badges because you need to tie it back to an ID, right? Now, there's a larger conversation happening where, you know, there is a distributed identity project based on like, think about like blockchain technologies like Indy, where, you know, if we are to implement that distributed framework and everybody else, like it's a specification, and everybody else does their implementation in that framework, then, you know, we can neutrally pull this together, right? I think the neutrality is key here because we don't want one company in the space to provide, like, manage what the global identity is. Linux Foundation, interestingly, is in the unique space of that neutral body. So this is actually, we are getting some requirements even globally, even from the government, to start working on something around our distributed identity model. But short-term, if they are on OAuth2, I think we have the federation capabilities to pull that in. We just haven't marketed it enough. Let's put it that way to have like, you know, these people come to us and say, hey, let's let's integrate with you guys. And if you are able to, you know, pull your badges, we had some conversations going, but we have not globally marketed this yet. Anyone want to grab the last question or comment? All right, then it looks like that's a wrap today. Thank you to all of our presenters and thank you for everyone joining today. And this will be up on YouTube shortly. In the meantime, have a great week.