 Good morning. Good afternoon. Good evening wherever you're healing from. Welcome to the series premiere of DevSecOps is the way This is going to be an awesome show the one that I will Thoroughly enjoy producing and hosting on a monthly basis Dave Do you want to take it over and maybe explain the whole program how you've got everything set up right now? Yeah. Yeah, thanks Chris. Um So DevSecOps is the way It's I'm used to I'm used to hearing that every Friday night in the fall But it we're really excited to bring security to OpenShift TV every month every monthly cadence. We've actually organized a bit of activities Around a monthly cadence of security information from Red Hat and and our ecosystem partners I'm a global solution architect focused on our security ICDs So I get the pleasure of working with a lot of great partners and understanding the security landscape and being able to Build out a point of view with with some of my colleagues at Red Hat around DevSecOps So we decided to have this monthly new series DevSecOps is the way To showcase a certain security topic every month So let and and I'll talk about that a little bit and then we'll talk about this month's Security topic and then we'll introduce our esteemed guests here who are next to me but let me just share my screen here and Show you all what we're planning So you can see here we have a monthly cadence starting this month in March all the way till December With different topics and oh by the way those different topics are specific categories that we have worked with the industry and with our partners to form a taxonomy around DevSecOps and the security methods and functions That you would need to think about when you're implementing DevSecOps So every month you can see that topic if you want more information You can see on the left hand side there. There's a URL a shortened red hat URL red dot ht DevSecOps and by the way The D and the S and the O do need to be capitalized Don't ask me why but if they're not capitalized you'll get a 404 Or you can email us and that doesn't need to be capitalized at DevSecOps help at redhat.com So this month is vulnerability month and We've although vulnerability is not a specific category That we defined in our taxonomy It does belong in what we call application analysis, which we'll be talking about in a handful months Upcoming but vulnerability analysis and scanning has been such a big topic over the last couple years especially around container scanning With our partners with our customers and so we wanted to dedicate the entire first month to vulnerability vulnerability scanning and it sort of duck tails nicely Into a certification program that we'll talk about a little bit later in this program called the red hat vulnerability scanner certification Which we just launched late in February So at a high level I should say we're gonna we're also going to be appearing in another open shift TV Show that we hijacked That's usually going to be in the third week as well this this month. It's in the fifth week of March We also have a set of three podcasts that we're planning to push out Every month and then blogs and white papers along to go with it So a lot of good stuff in 2021 around DevSecOps and security with red hat nice Yes, so I guess with that. I'll I'll let our guests here introduce themselves Jeremy here is from our products at your security team. So why don't you go ahead and introduce yourself Jeremy? Sure? I work with our product security team here at Red Hat. I'm part of our product security incident response team specifically my team Works primarily with our container portfolio Hence why I got pulled in to talk in this particular segment Yeah, glad to have you and of course one of the main things we're doing is bringing in experts to talk about these categories On a monthly basis Jeremy's one of those experts as well as Steve here on the IBM side. So Steve, please introduce yourself Absolutely. Hi, I'm Steve Wozepic I am the CTO for IBM's X-Force Red team and our our job We're the offensive security team within within IBM and we work with our clients to figure out how attackers get in So have a lot of good perspective from the field in terms of these container vulnerabilities. We'll be talking about Awesome. Well, I guess Chris if you didn't have anything else, I'll hand it over to that Jeremy to start What we wanted to do was just give you all an introduction into how Red Hat handles security and And I'll let Jeremy do that and then we'll talk about our new certification program and Steve will provide a lot of great insights around real-world, you know customer Situations around vulnerability scanning and his security practices Great. Thanks, Dave. Well, I guess the first place to start is talking a little bit about how Red Hat handles vulnerabilities How we how we analyze them and what we do with them. So Can you see the screen I'm sharing Dave? Yeah, yeah, so this is a nice little graphic We just recently put together to better describe how we do vulnerability assessment internally here at Red Hat We have a process fairly complex process of identifying vulnerabilities out in the market we watch Nailing lists upstream channels various feeds we pull that in we create tasks to take a look at those We do some initial triage on those on those initial tasks to determine You know if the vulnerability actually aligns to our portfolio based on our manifests, right? For products that we ship and build Our analysts then do some some verification along with engineering and kind of move into this triage and coordination phase I'm going to pause here for a second and highlight like one of the differences between how Red Hat operates and how Maybe some other companies operate product security for us is a kind of a hybrid process It's not a we're not a standalone product security team here at Red Hat that does everything from start to finish It's a company-wide effort within our research and development department, right? So When we're doing this triage, we we work very closely with the engineering team Who work very closely with upstream as well? So this is part of what you see here in that red section on that coordination We want to validate and verify what we're seeing with our engineering peers After that verification is done. We we work to remediate these vulnerabilities. So this includes filing bugs and trackers for For every product that is potentially affected So like we have a huge portfolio and and it's Important for us to To track, you know, these vulnerabilities across the entire portfolio and not just look at just a single product So when we get a request that comes in that says, hey, we think this particular component is affected or this particular product is affected You have to drill back down to the to the low level component and figure out which products consume that particular component I mean which version of that component was it was shipped with that I think a big selling point behind the the the methodology the way that red hat does analysis is Because we build our products and this is a key point, right? Because we build our products a certain way and we configure them a certain way And we ship them a certain way It's not always black and white from a from a vulnerability standpoint to say Yeah, you're definitely affected, you know The same way that a researcher may have discovered it right in the way that it was reported up through our national vulnerability database Are we may actually compile out? So the the the questionable code and if that's the case then you know that that particular product isn't isn't affected by that vulnerability Because the code isn't present So it's very important for us to staff analyst and work with engineering so that we could actually do that type of analysis We feel like that's that's a more accurate Process and that it's helping our customers better Determine their risk and whether they're affected The last thing that you'll see here in the green section We we do a lot from a recovery standpoint communicating this this back out We've recently launched security bulletins To improve the level of communication regarding major major incidents We we have a lot of tracking, you know to make sure that we Any of these trackers any of these products that are effective that it gets all rolled up and under our cvpages I think a lot of people out there are probably familiar with the the red hat cvpages It's a a lot of Companies similar to red hat do the same thing and we roll that data up into that cvp page based on All of this tracking and communication efforts. So that's really how we do the vulnerability analysis And how we how we handle these incidents Dave any questions before I go on to something else Uh, I do have a question. So, um How much of this do you think is done by the And I don't want to sound like I'm being mean to to them, but the national vulnerability database Right, uh, because I know that nvd and cdss Are sometimes seen as a standard, but for my for my understanding they just don't have the resources To test vulnerabilities and they don't have the products Obviously that we own to know if they're really affected or not. Is that accurate? statement Yeah, actually a couple of things on that You you mentioned quite a bit there. So I'm going to unpack all of that. First of all, uh in the the nvd Don't actually do the vulnerability assessment themselves, right? They're they're a storage database The communications a coordination kind of company or whatever you want to call it, right? um So it's actually independent researchers companies like red hat Across the world that that submit their information up to nvd And the problem with this is that you take a piece of code like open ssl for instance And it's used by almost every software vendor out there But there are different ways to exploit that code based off of how that software vendor shipping the code or configured the code, right? So the problem the fundamental problem with a single score a single rating out there in nvd is that It it's it's not inclusive of of those many temporal characteristics, right? So I think that's where we where we run into some challenges Sometimes we try to be much more accurate here at red hat with doing our analysis And you know, we may rate something as like a moderate issue because we've not compiled in that that bit of code Whereas if you go look at the nvd score, it may be rated much higher And you know from the flaw perspective itself, that might be true But you always have to take in those character, you know, those temporal characteristics as well The other thing that you said in your statement, and then I promise I'll I'll turn it back over to you You mentioned standards, right? So, uh, this is this is a very important thing for us I probably same thing for it's true for steve at out of idm, right? We leverage ovale cvss Cwe cpe. These are all done by mitre first.org. We work heavily with nist on their nist 800 dash 160 policies, right policies and standards owasp These are all like industry-wide kind of standards that We we adhere to and and we have made part of our part of our process in the terms of how we do analysis And how we just close back to customers No, absolutely. I mean you're bringing up a really good point about how do you figure out the attack surface the actual um You know the way that the packages I think to what you were talking about are by default configured Is that even really attack surface that is going to be focused on you know by the attacker? What have you so uh 100 percent? I think you know on the on the attack side what we're always trying to do Um, and what we what we use intelligence that we gather to do and x-force red is we also look at how much In the same lines of what you're talking about cwe into these others capec You know another mitre standard and mitre attack and we're trying to you know, we We have into intelligence that shows us how much uh attackers are weaponizing those exploits and and Those exploits is so exactly to your point When you have a whole bunch of things that are that are critical or coming out the same score in cvss What do you focus on? Things that have the most attack surface right it's just all of us are trying to get to that same place of measure Yeah, I can imagine steve you you've probably heard more than once a customer say i've got all these critical vulnerabilities You know and then you have to be like well We got it. We got to do a little bit of you know triage or manually really find out if you're affected Absolutely right. I mean that's what we've really built a lot of our services around is is helping clients to do that And what we always advised regardless of if we're working with them in this capacity is is to be is to take into account that context That jeremy was talking about there's what they call the temporal factors that feed into cvss, but also just Are these vulnerabilities really being targeted? Are you hearing about them? Are they kind of like these more wildfire based attacks? Tempering that with the ones that you know are have been bad from years past There's one that's really common. You've heard of you know the shadow brokers ms 17 010 Clients still have that that's that's from several years ago It is absolutely the thing that will get targeted by attackers if it's there And so ensuring that you're not just always chasing the the newest shiny one But focusing on vulnerabilities that you that we know are being heavily targeted by attackers in the past and really You know honing in on those cool Can I can I say one other thing? Yeah, absolutely Um on the on the severity ratings themselves And I'm curious to kind of get Steve's thought on this as well. One of the things we've noticed Was that the industry seems to have kind of over the years kind of incorrectly started using those those severity ratings to kind of gauge risk Right when really like our position on it is that it's supposed to prescribe some kind of order for remediation Right. Absolutely prioritization It's it's a great point and cvss Honestly is a good metric if it's used, right? It's it's it is it is lingua franca of of of our space However, to your point it's being used to measure risk when really as Had a number of cvs that i've written myself and vulnerabilities i've discovered and when You you go out and you use that cvss calculator Everything that you're doing when you create that cvss score is the worst case scenario You're not measuring how much time it takes to make a To make an exploit and frankly You can kind of shoot yourself in the foot as a researcher The calculator because when it gets to that point it says attack complexity It's very easy to sort of pop your collar and say oh, it was very very complex It was very very hard for me to break into this, you know, no mortal could just do this like i'm i'm the one I'm the only person that can do this so you're going to set the attack complexity really high Which is going to bring that value down But think about this if i create a metasploit module for that if i go to exploit db And i show how to do it attack complexity goes out the window, right? You're not talking about that anymore I've just given you the ability to do it by running a script That's the piece that is one of the biggest troubles we have is if you're just using cvss Imagine you're taking cvss 10s that were privately reported that don't have any public exploit code And saying that those are more important than something like ms 17 o and o which is You know, it has has a very high complexity of attack Not that hard if you're downloading the the scripts to to break in right which of course all attackers are doing Yeah, I would say i'm glad you mentioned the calculator. I was going to mention that as well It's right there on the on the nvd site. So they know Um that their scoring is not really You know, it's not potentially risk for you. It's it's a guideline, right? It's a it's a recommendation to prioritize and then You know add in your own environmental and temporal metrics to to figure out if you're really um exposed And frankly, I think it was created originally to Take from the researcher and give to the vendor. I think that's what is primary purposes And then as you know, there's that little bit of negotiation that happens in terms of how how high is this really, you know How high a score is it and of course the researcher is always going to think it's a 10 and the vendor's always going to think it's a three That's somewhere somewhere in the middle. You figure figure it out, right? Yeah Yeah, and so jeremy a lot of times um your red hat Has a different score and they have different severity Categories can you just talk a little bit about? that in terms of how we how we score and Categorize these cds Well, I think you know first thing I'd say there is we don't have a different scoring system. So to speak, right? We we use the same low moderate high critical that the industry uses But we do score things based on the temporal characteristics. We talked about just which is previously We do score things differently than what a researcher might have scored it Um now some of the things that we recognize that you know your customer you're looking at this information It gets very confusing, right? So um, if you look at our cbe pages, we've we're we're trying to to help Kind of pull the curtain off of that that mystery so to speak, right? So we do a comparison of the nvd score versus the red hat score Our team works very closely whatever we feel like, you know, we if we've we've scored something differently I'm talking about scores for a second not the rating, right? But if we've scored something differently Then we have a whole process where we reach back out the nvd and we submit our proposals, right? And and are just our reasons why? Um, not based on just on the red hat specific, you know portfolio But just from a flaw perspective standpoint, we try to do those re-scores to help those the nvd scores become a little bit more accurate as well Um, but you know rating wise that that that's a very uh Score, yeah, sometimes they're going to be a little bit low and so we We uh have statement text in our cbe pages where we try to to Clarify that why I just looked at one the other day. It was like, oh, well, you know, this is why right? We don't include that bit of code. Um, and we felt like that's useful and helpful Did that answer your question Dave? Yeah, absolutely. Yeah, of course all this stuff is pretty publicly accessible um, even sometimes bugzilla cases, right? You could log in and see see what the developers are talking about or how it's being affected So yeah, I usually find those pretty helpful and understanding, you know, the root cause Or why why red hat determined, you know, this category or this score Awesome, how about we jump to uh containers a little bit jeremy? So your perspective if you can give us some insight on what we do with containers The container health index how we grade those how does that all work? Okay, so there's You ask these these questions that are kind of, you know, big big overarching questions So I think the first thing to say with containers is It was a different shift in them in the the industry, right? You used to like a kind of a box product and You know containers represent this bit of like static code that you pull out from, you know, somewhere else, right? and you bundle it up and create an image and How you handle security for that becomes a little bit different And we've written several blogs. I know my uh manager here at red hat has written several blogs out there for the red hat blog Blog space that to kind of explain this a little bit But we took a different approach with our container registry and how we Were scoring, right? So we instead of looking at it from a vulnerability standpoint, we look at it from a time standpoint because containers consume that content from something else that and that those Where where the source on where it pulls that content? That's where that vulnerability technically lives, right? And it's patched there So for instance, if we take a look at our universal base image, right? So our ubi image the pulls heavily from rel, right? The the vulnerability is patched in rel the the rel content then is then pulled into A spin right a rebuild of that ubi image So what we're trying to display with our container health index is we're trying to tell customers How what's the risk from a standpoint of are there unpatched vulnerabilities, right? So if there's a vulnerability that we know is fixed in rel, but it wasn't applied to that container yet Then that's the concern and specifically how long has it gone, right? Because again, it's it's and I think my manager and his blog used this quote. I really liked it. It's like You know, it ages like milk and not wine, right? Wine ages really well milk Turtles sours, right? So the idea with containers is the longer they sit out there the more sour they become The more vulnerable they become and so we're trying to to represent that in the container health index So for example a container. I'm sorry a grade a there is no known Critical or important vulnerabilities that have been Unpatched in that container something that's grade b. You're looking at like a 37 to 30 day time span and We've got these published, right? So I won't repeat all of them, right? But we've got grade b c d e and the whole idea is you can look in a container That's like a grade e or a grade d. There's a significant amount of risk there That container has a lot of unpatched vulnerabilities that are known, right? There's actually a known fix for them Yeah, I think I think that's a great point and something I learned a while ago As well as that the container health index is not You have a container that has these known vulnerabilities, but You have a container that has these known vulnerabilities with known fixes and aren't applied yet, correct? That's correct. Yeah, and so as we'll talk about a little bit later We've got our great partners in scanning and and they see reports They try to compare that to the container health index and it's kind of an apples to oranges report Because you know because the container health index is not showing all the vulnerabilities all the cvs That might be still yet to be patched that affect that container Um Good point. I guess I guess Steve do you see a lot of containers scanning containers? Um dealing with security around containers. Absolutely. You know this topic today is very important because this is the primary issue um, you know before we've had You have that that situation with containers, right? They're sort of the new almost vm images in a way Not really because they're limited, but it's the same concept where you get something that works You know as the developer will all been there. You have this base image. You really like We're gonna, you know, it's got everything you need it has read this or what have you on it and you Is that to run your application in it and you're just you get very Attached to that image because you know it works You know the version that it's at all the underlying pieces are together And it's using all these different libraries that you know are sort of working together and uh, that's static It's a terrible thing that we're like that because It causes us to reuse the base image over and over and over and over again And any time you're doing we do work with clients who are doing container scanning Uh tools, you know like claire that are that are checking um, um, how you know what vulnerabilities lurk in some of these um Uh containers and it's it's always those base images It's always those old versions of libraries that if you were running A rel server and you were just keeping it up to date as you would they would get fixed But the container image the base image it's all sort of married together. It's all kind of dependent on each other And so it's not Something that you think about a lot in a developer context something of course on the security side We always point out and try to push but sometimes there's a fair amount of detangling Underneath let's say in what you said of one of those d or e grade containers You might be responsible for doing all that detangling if you want to keep using it And you fix one thing that's in the base image and then all of a sudden your your redis server doesn't work anymore And you have to figure that out And that's what's great about having the scoring system because you're you're really The the how well maintained it is because it's an ongoing containers are a moving target. They have to be They have to be kept up and and you're in you're being able to grade Is a great thing because then from the day one you can say I'm choosing this because they're going to keep up to date and avoiding that whole problem that's gonna that's going to rear its head pretty quick Yeah, I think it's a it's a good segue into our next topic. I guess before I go into there I haven't been monitoring the chat feed chris. Has there been some questions or uh, no not yet Okay, but it I'll let you know Sounds good. Sounds good. Um, so yeah, I guess What I wanted to go to next is talk about container vulnerability scanning Um, and so let me uh, let me share my slide again here. See where is it? And I guess, um I don't know steve how many of your customers look like that little girl No Well in terms of in terms of when they start or the problems they're inheriting Um, especially when you start getting a scope of it. Yeah, I think that's that's fair So by the way, this is a legal photo that I'm using. It's actually of my one of my daughters And her mom was actually pulling her hair out which by the way is what our customers feel like when they um scan Containers and they see a huge list of vulnerabilities And then they might compare that to red hat and red hat says no no no the container is good And this this is actually it's not tied to one scanner Um, it's not tied to red hat. It's it's sort of an industry issue just because of the challenges of being able to You know identify The the right components inside of a container Being accurate with that understanding if it's something's back ported or not making that match To cvv cve and all the stuff that we've talked about like even though CVSS says it's critical. Is it really critical in your environment? so red hat About six months ago formally started an effort to help resolve this help to provide What we call minimal discrepancies between our partner scan results and And what you see at red hat And i'm happy to say that we have You know, there is a happy ending same same daughter but much happier And there's a happy ending that we now have a certified Vulnerability scanner certification that we launched on february 23rd Um, which was about a six-month effort with our partners to get set up We took a good number of them through a pilot phase In order to understand what they needed and what we needed But there are a set of requirements and you can go out and find all this information online Where our partners needed to meet In order to achieve certification And you know, some of the requirements are that you have to pull from the right feeds That you are showing red hat data in in your ui um, and so we feel like this will really help to Minimize, you know the amount of discrepancies When our partners are scanning red hat supported data and you can see the We announced the certified partners there in the 23rd aqua new vector cystic And you can see the other partners right now that we're working with anchor j frog parallel to sneak And synopsis that are working towards certification. We've got about 20 other partners that we know of that are out there But if you are a partner and you're interested, please feel free to contact us And we can help you through this certification So we really think that you know, this will lessen a lot of customer frustration In in the market and um, and yeah, we're pretty excited about it Um, I guess steve, what do you think about that certification? Do you think that'll help your efforts? You know what I what I see with that is In terms of the the and we work with a lot of those technologies as well from the other side So imagine that we're taking in data and our clients are taking in data from sneak and taking in data from prisma aqua you know these technologies and What causes a lot of the work in terms in the field is When those scanners will maybe look at a container registry Without the maybe because they're just not armed with the context. I think you're providing in some cases to Have um, maybe we'll spot something that is a maybe a problem But it's not as much of a problem because of the specific red hat release train So for some of the you know the context that uh, jeremy was providing earlier Sometimes these vulnerabilities are patched in a way where you're keeping the same version for example of the of the system or of the package That is listed as vulnerable in nvd, but because of certain considerations in the way that configuration, you know configurations done Um, doesn't have the same attack profile. It's not the same thing, right? It's been either It's been either patched by red hat or it's been changed in some way Everything with vulnerability management is about getting rid of those false positives and focusing in on the things that are actually the most important from a risk perspective So the more Context that those that those scanners can have going in the better. They're going to Build that contrast and the the easier it's going to be for the for the consumer for the client Working with those result sets and in turn for us helping them to remediate those vulnerabilities Yeah, Dave. Can I can I say one thing on that like and uh, I suspect steve will completely agree. I hope Containers are are complicated From the standpoint of understanding the software bill of manifest, right the the um, what's in it I think part of the challenge for our scanning vendors over the years has been to identify What's vulnerable and what's not and and we you know back and if you look back at the the early days of rail It was really much easier to kind of scan that and look at a name version release Stream right on a package and say, okay Well, it's newer or it's older right simple math with a with a container these days, especially in The context of you know red hat tries to Provide maintenance for for product versions for as you know as long as you can for for a customer, right? Which means that we end up back porting a lot of patches back to uh, A particular mainline branch of code, right? We have a lot of different branches out there that we maintain and when you're a You're a scanning vendor. How are you supposed to properly identify? Whether that particular branch had the patch or whether it didn't have the branch You can't just simply rely on that name version release string anymore, right? So part of what we did with this uh scanning certification It was like empowering the scanning vendors with more of that context to say, okay We've done a lot of the heavy work for you. We're gonna we're gonna help you figure out how to identify What's actually in in that container and then we're going to give you that context in the in the form of like ovale files, right? So that ovale file has tests. It has information On the rhsa's that fix it what the status is for you know each cde It's about using that context properly, right? So um, I don't feel like we're You know putting all of the vendors on the same playing field so to speak I feel like we're we're giving them all the same information Um, and then letting them run with it No, I Yeah, 100 percent agree and especially about the complexity because you have those, you know you Containers as being just uh a singular thing you have to realize, you know when you're building one There's a big interplay between the base images what you're starting with and then then adding things on to it It's like a lot of for building block Your point if it's not aligned with the rsa rhsa's and that's what a lot of the certification is about obviously It's it's they say it's just not going to have the right context and And you'll spend a lot of time will spend a lot of time working with our clients But our clients we see them spending a lot of time chasing things to ground Only to find let's say after three four hours of research. Oh this version like you said I might have lost Steve there a bit One of our clients having spent that much time, you know chasing those kinds of things so absolutely right Sorry, Steve you you kind of froze up there for uh, oh really? I'm sorry I was just in a long-winded way agreeing with uh with jeremy around um Preventing our clients from having to run around and look to prove out that this this version of something was backported and I think that uh, this this really helps to save us time on that Yeah, I like one of the things you said there is that you have your base image, but then you've got stuff That our customers add into it their own applications, right? Which by the way, this certification doesn't cover because red hat doesn't Care typically or know about the packages you use in those applications That's why we value these scanning partners, right because they have the Intelligence and that's their value to help you understand risk vulnerabilities in your applications outside of red hat scope, right? um The certification though will definitely help to minimize a lot of frustrations just on the base image. I mean you could have Hundreds of cds in the base image And wouldn't it be great not to have to go through all the ones that are critical and high To ensure that, you know, they're you're not vulnerable. So Well, cool. So jeremy you mentioned oval um red hat I don't I don't know if we could still say recently, but um, we moved to a second version of our oval feed This was a couple years ago, right? Would would you mind talking about some of the Enhancements sure. Yeah, I think really enhancements is a better way of describing, right? It's the standard itself doesn't didn't really change. It's not like there's a version one or version two of the oval standard we we Made improvements in terms of how we classify how we structure the oval feed Um, I think originally we were just kind of dumping it all into like single single files And that didn't really work for from a portfolio like organization standpoint. So we actually break up our oval files now based off of The the base images so to speak so rel 8 rel 7 And like if you went into our oval feed right now our v2 oval feed and went into the rel 8 folder You'd see all the products that that are built consume content from rel 8 like open shift, right? We have several files there in that in that oval directory. We have An oval file for uh, that that includes unfixed CVEs We have an oval file that that includes us content and some of the old some of the streams that we maintain for long periods of time And the trick really with these oval files is to figure out which ones like I mentioned previously Which ones to use right depending on what you're scanning If you're scanning a Open shift, you know, you have to use a rel file plus an open shift file, right? Because there's a lot of content from rel that's also consumed Um, and that, you know, otherwise you're you'll end up with not necessarily false positive or false negatives Um, so you want to make sure you're you're looking at the right The right files any specific questions beyond that Dave? No, I think I think that's good. Yeah, um, that was the basis of our certification the main the the main requirement is to consume that um those files and then we actually Uh, you know used Claire and the Claire team was very helpful and um helping us formulate sort of the details on Recommendations we didn't we're not the experts the scanner experts as our partners are but Um, we use the the Claire code as a reference to say, hey How can you parse oval? You know to show red hat data to show the appropriate red hat data We were requesting so of course Claire is open source and you can find all that information You know in github. Um, so no that was good. Um I guess anything else in the certification I showed um a couple slides about the problem and uh and some of the partners Um, anything else Jeremy or steve you want to chat about that? If not, I've got a couple other items to talk about Um, I'll just I'll also mention as well like it's important for us to make sure that we continually evolve All right, so we're we've we consider all of these scanning vendors partners with us And we meet regularly with them to talk through Challenges that are still ongoing in terms of how to better identify the content right or If there are new You know standards so to speak that we should be taking a look at so Yeah, we continue to meet with all these vendors on a regular basis Yeah And I and I'm in a partner team here at red hat. So I talked to them on a weekly basis But yeah, you have that working group, which is really great as well Well, cool. Yeah, so I mentioned, you know, this month is vulnerability analysis. Um, There'll be another open shift tv session in a couple weeks Um, and then we'll be dropping three podcasts as well Now I wanted to share sort of the A byproduct of our efforts around dev sec ops Let me share this screen present it um, so I mentioned the categorization we came up with Uh, nine categories. You can see those categories here on the left hand side And we have 10 months as I mentioned vulnerability sort of bubbles into application analysis Underneath uh, those categories You can see all the different items there. There's 34 different security methods And so we were able to take those methods And work with the industry work with our partners to plot those against a dev ops pipeline like you see here life cycle and um, which serves as a basis To understand and to start communicating and help our customers consume this information a little bit better You know, for example, if if you're starting dev sec ops, or if you have it We can come in with A solution joint solution with red hat or one of our partners and say hey Have you thought about secrets vaults across the entire Life cycle or what about get ops and config management? Um, or are you checking your network policies during build automation? So what we've been able to do in certain situations is work with our partners to map Where they excel at and enhance and extend red hat capability and of course where red hat Has capability as well and red hat as you would imagine has capabilities all throughout the Life cycle here very strong in the platform security side of the house so Things like a secure host rel and And cryo the container platform Isolation and cluster hardening with compliance, which will be one of our monthly topics as well And then december will get into a lot of rel a red hat type information around platform security but I just wanted to Throw this up here to give everybody a basis Of why we're talking about dev sec ops and and sort of how we're bringing this to the market as well awesome Yeah, I guess i'll just leave this up as an ending slide here This month again vulnerability next month compliance So if you're interested, maybe you're in the federal space or Um, you know, you have to worry about c i s benchmarks or pc i We're going to have some experts Join us to talk through compliance as well And then you know, we'll go through the year with these different different categories Fantastic, this is a wonderful lineup of content you have lined up for us here. I really appreciate it yeah We're very excited Yeah, so when is the next show a month from now? Right? No, the next dev sec ops is the way show. Yes is yes usually the third Thursday thursday. Yeah of the month Yeah We're going to have another open shift tv show in two weeks And that's going to be around vulnerability scanning as well right awesome And that's going to be with one of our partners Fantastic All right Well folks Let us know if you have any feedback about the show what you think you can always reach me C short at redhat.com and I can ferry the The information back down and if You Want to follow or ping me on twitter just at chris short on twitter That's for anybody, you know out there that has any questions and wants me to you know Get some information for you always available for that purpose. So thank you everyone for watching. We really appreciate you Yeah