good afternoon thank you for joining us today koft technology would like to welcome you to our service now webinar integrating sbm and vulnerability response for enhanced resilience joining us today from service now we have Jason Bean Federal solution sales executive and Pete white senior advisory solution consultant and security before we get started I would like to quickly go over a few housekeeping items please note that all lines have been muted to reduce any kind of background noise during the presentation if you you have any questions throughout the webinar please use the Q&A feature on the bottom of your screen and we'll do our best to answer by the end of the presentation or follow up with you offline this webinar is being recorded and a copy will be emailed to you just to tell you a little bit about koft we are a trusted government IT solutions provider supporting public sector organizations across federal state and local government agencies including education and Healthcare markets at this time I'd like to hand hand the floor over to our speakers Jason the floor is all yours thank you Sarah and thank you everybody for joining today uh today Pete and I will be discussing s bombs and how they are an important part of reducing the risk agencies face in this everchanging cyber security landscape next slide this presentation may contain forward looking statements that reflect the current beliefs of service now and are based on current information available these forward-looking statements should not be relied on on making self purchase interesting decisions next slide so the agenda for today will be you know what is an sbom why s bombs matter the regulations around s bombs how do s bombs and software development relate throughout this conversation Pete will be showing some slides and going into a live environment so that's going to be the demo portion of uh the conversation today and then we'll wrap up with questions and answers next slide so what is an sbom simply put an sbom is a machine readable list of package dependencies files licenses and other assets together making up a piece of software think of it almost like an ingredient list but for software and software consumers have increasingly depended on external thirdparty software components to perform critical functions with little to no visibility into the code of these products the lack of transparency is the core issue that promp did the need for ES bombs and component vulnerabilities are a prime source of cyber risk in the supply chain es bombs are designed to identify these risks allowing better visibility and Swift mitigation next slide please so es boms aren't a new undertaking their history go back well over 10 years but recent events including solar winds and log for J have shown how es bomb can be a vital tool used to understand what what software is in your environment next slide please over the past couple of years White House has released several memorandums including m228 and the updated M 2316 enhancing the security of software supply chain through secure software development practices even to the point where sisa released guidance earlier this week on software transparency in SAS environments and they're looking for agency adoption for bringing in s bombs from your SAS vendors next slide please so challenges we see when we hear when we talk with customers really around how do we store s bombs that I'm getting from our software vendors and internal development teams if you think of the magnitude of s bombs and agency should be collecting from all of their software vendors including dot releases multiple versions of their software how do we manage it and access it um how do we search the contents of a machine learnable or readable file that's a that's going to be a challenge and then can we match the content inside es bombs with known vulnerabilities and how do we turn those vulnerabilities if we find them into actionable items so this is where you can go from having a more of a compliance-based sbom storage program to actually have an actionable way to be able to read s bombs and then determine whether or not there's vulnerabilities in there and take action on those and we'll talk about that today too next slide please so esbon management so really non-relational databases they're going to be a lot more flexible however it makes management incredibly overwhelming so if you look you know it's it's just f store and how do you find things that are not index and catalog we're service now we're a relational database we organize the data in inter related tables making it much easier for an organization to manage data for Effective use and be able to use those S bombs in effective manner next slide and then service now has developed esom capabilities into our latest version of vulnerability response this is to help agencies not just meet but exceed the required ments of m228 by making s bombs actionable now I'll hand it off to Pete and he'll be going through some of the technical and the demo screens yeah uh so when we start looking at software in the modern Digital World out here most modern software is built using packages from a number different sources uh it's not all homegrown from the the groundup type of development anymore you're pulling packages from you know some cases these packages might come from some questionable locations or in you know more concerning have a limited support uh for the package that's being done and this example in this little cartoon here is you have a very critical piece of the this particular application that's being designed or being maintained by this person in Nebraska not there's anything wrong with development in Nebraska by any means uh but you know building an entire piece of your critical infrastructure on something that if something is wrong with it or you need an enhancement to it and you know depending on that one person to to fit that into their schedule uh you know is a lot of risk that you're bringing into the environment what we saw is there was actually a report done by synopsis last year where they went through and looked at over 1,700 different uh code bases that they could do the analysis on and they found that 96% of them contained uh packages that were from open source Solutions so this is not something that is you know uh a a a minuscule problem in the in the industry this is essentially everything that's being developed today has some kind of an open- Source uh package that's being included in it and then within those there was a they found that uh a very large 91% of them actually contained abandoned or outdated components and the definition of abandoned can vary from from location to location we have one for our Technologies we'll talk about it here shortly but anyway it's something that has been you know was uh something that had not been addressed or been been developed on or released a new version in a a a long time let's put it for that way for for this this discussion here and when you start looking at uh supply chain and uh software Supply chains the the effects that a a an issue has can have very you know can have astronomical effects on the organization something that you think about like a browser obviously there's lots of uh browser something we use every day and you may have assumed that you know Microsoft developed you know their browser Edge entirely on their own and and it didn't really have anything back there but you look at it in reality you start backing back in the the its history it has chromium and same as Google Chrome is all based upon that and then they have development pieces beyond that in the in the mix along their way and other dependencies that brow into this so a one simple you know kind of one application here there may be you know 10 20 30 different Upstream effects or Upstream pieces of that supply chain that you need to be aware about aware of and understand the effect that's going to have on there so something simple as a an issue with maybe the blink rendering engine uh you know a couple levels back up essentially means you're going to have to cause an update to the entire your entire environment around your your browser to address that vulnerability and so uh it these kind of simple things like if we learned you know anything from like log 4J you know not to keep kicking that that horse but it's that you know some a vulnerability way up in the supply chain can have dramatic effects uh previous slide there talked about the number of hours and dollars that spent government agencies found you know spent on on addressing those vulnerabilities within the organization and this one is just an example of a browser it could have that same kind of effect and probably even bigger because it affects more of the organization and before we dig into the actual s-bomb itself I think there's some foundational pieces that we need to discuss so we start talking about vulnerabilities there are multiple types of vulnerabilities that are within an organization the most common you'll see and ones we're most familiar with are what we call infrastructure vulnerabilities these are the ones that are located by your vulnerability scanner whether table excuse me tenable qualus rapid 7 whatever the the solution of your your organization is using to those vulnerability scans uh those are normally handled by the asset owner if it's a Windows device a Windows Server the windows team is responsible for getting those patched and generally speaking there's a pretty defined process for getting the vulnerability information to the right teams and getting those patched it may not be the most efficient it may involve you know Excel spreadsheets and email and we have solutions that can help you with that uh we'd love to talk to you about if that's something that you're you're concerned about but we you know there there's a it's a pretty well-defined and easily you know documented way of doing that the next kind of vulnerabilities that you walk run into are really misconfigured asset vulnerabilities you know you may have the most up-to-date patched uh system out there but if the password policy on that server is pass password is you know doesn't have one or doesn't require any kind of a complex password well it it's just as vulnerable as if it had a ton of vulnerabilities in there maybe even less you know even less e more easily uh exploitable because of that and so you you have those configuration scans you're looking for those policies uh for those policies like password policy I mentioned and things like that you know normally whenever a new software a new a new server is rolled out to an Enterprise it normally has a kind of a gold standard that is was applied to it whenever it was first rolled out but over time we see these these these drift in the those configurations and so doing these configuration scans looking for those that drift and making sure those are applied once again it's generally the asset owners that are the ones that are responsible for getting those done if if a password policy needs to be changed on the Windows Server the windows team or maybe the active director team or someone is usually the ones that are taking care of that when you start looking in the last area which is application vulnerabilities there's a different process that that follows to that uh it's it's using a different scanner it doesn't use the same infrastructure scanners there are specially scanners that are designed for doing these application scans because it's a different type of of of of codebase or different type of environment you're working with there and what's unique about this is that the person who's responsible for getting those patch particularly for internally developed application is your development team uh it's not the infrastructure team it's not the windows team it's the development and you have to make your systems in these this processes fit with their continuous integration continuous development tools that they're used to working with uh they have a process for developing and putting uh software patches into Sprints you need to work with those and make sure that's that you are working in those environment as well so the way that these application vulnerabilities are are determined are usually there's kind of three different uh technologies that are used for uh these types of vulnerability scans uh Dynamic application security testing or uh is running it in is doing the V the the vulnerability scanning while the system is running uh usually in a Dev environment it could be production depending on what you're doing in your in your world but uh it's it's running it in it's testing it while it's running on a server it's uh it has internet connectivity you know all the standard stuff that like a user would be interacting with it uh the second type is static analysis or static application security testing sometimes referred to as reverse engine engineering as well where you take the actual binaries or executables or packages and run them through a reverse engine airing engine uh that will take and and tear the pieces apart and do the evaluation on the individual pieces looking for vulnerabilities that way uh sometimes called white box testing as well the third type is software composition analysis and this is actually taking a look at the code base and term vulnerabilities there and this is where s bom bits is in this software composition analysis area so we are taking and looking at all the components the the licensing the all the these things and looking for those individual vulnerabilities and exploits so let's actually dig into the to our our solution here so the first step in the process is to ingest bring in those S bombs uh instead of having them out on some file share that Jason about uh that you really don't have anything out there and you're just kind of a click uh you know clickbox compliance or whatever or checkbox compliance we want them to have actionable information so we bring them into our system uh and allow them to to get additional make them so it's it's readable by the by by a human that way there's a couple different ways that can happen uh we have an uh there's automated apis available that you can push them to uh the the workspace and allow them to be addressed that way way or we can do a manual upload within the the the the the API stuff that's we're designed to work with those cicd uh tools uh such as Jenkin for example uh so whenever a new version of a software is built uh that s bomb is automatically generated and gets pushed up to the workspace and for evaluation to look for uh the the the various different uh items we're looking for here uh we have integration with bar code as well that's a vulnerability scanner uh they can generate s bombs and we can get them from there those as well if you're uh depending on how you're you're doing your development that way uh like I said the most common way is going to be a manual upload uh some vendors are making their s bombs available through their portals and so you would simply go out there download it to your local machine and upload it and then walk through uh uploading it to the the workspace and I'll show you what that looks like here in a second uh the bombs themselves support the most common methodologies out there the Cyclone DX and spdx uh so uh we have full supported that and would allow those to to get uploaded so let's take a look at the actual uh console itself so we have a purpose-built uh workspace called sbom workspace uh within service now we've started coming out with a number of these different workspaces within the the tool they are designed to be used by the different person personas that would be utilizing these different uh different pieces of the of the of the organization and within the applications here so within here we have a what we call a bomb queue and this is where we're going to uh upload these bombs in in the mix here so it's simply if you have a file you click on upload bomb uh it's going to go out here and it's going to say okay I need to select the file in question go out to your local machine wherever it is uh select the the bomb that needs to be uploaded uh click on open and upload and it's going to uh stage it for for processing and so I've already I've already done this so I don't need to do it again but i' simply click on upload and it would go through and process those files uh You' see here in the the statuses those come up here that we go through processing and eventually processed so once we have the the application processed the the result of that is that we get a much more easily understandable view of the of the contents that that were contained inside of that that that sbom file uh the first one is the components all the different pieces that went into this particular application uh this case the application was a Java application excuse me uh it had a number of components out there within the individual components you can see the type of the classifier within the esom that's defined as a library the ver information the licensing information you know Apache MIT open source whatever and then most importantly or one of the most important things is this package URL or Pearl uh location essentially this is the the kind of a unique uh way of showing it but is essentially is the the URL to where you downloaded or where they got this particular package for including in the application uh once we actually see this information we can dig into the actual components and learn more about them as well so in this case here I can open up one that was in that that listing here and I can see that the state here is vulnerable we'll talk more about that here shortly and how that became about but I can see the version information we kind of knew that already from the 145 but not all uh components will list the the version right there so you may need to know that information we can also see the latest published information here and then how far back we are from the latest one so if we're using us this software in our environment here and your 22 versions behind that's probably not quite ideal and you can get over here on the right hand side you can see all the versions this is the version we're on here and here's all the versions that have happened uh since then and up to the latest and greatest version available for this particular component in here the next thing we can look at here is the dependency graph so in this case here this particular component is actually something that is used and dependent upon depends upon or is depended upon by these two other components down here and this is kind of a simple example here but some of these graphs can be can be very large that we have something here that's something that that's used used by this that's used by this by used by this and so it can go down here and having that full view of the effect that a a vulnerability in a particular component would have is something that is is generally very hard to come about and that's something that would be very difficult to understand or or deduce from that Json file that that the vendor gave you along the way here uh we have hash information you know if you need to go verify that you're using you know the right one that information is there this is information that's uh contained in the es bomb as well uh and then we can see and it's actually a little easier to see here is the number of actual bombs that we have uploaded that actually had this this particular component in here now in this case here we only have a I've only got a handful of of bombs that I have I have uploaded so only these are all component only available in one but if you think back once again to that log 4J understanding and knowing that you know log 4J was in you know 20 or 30 different uh components or different applications in your organization by simply looking at this that process much much easier to work with and and easier to develop with okay so now that we have the information in there we can the next step in the process is to determine and access and assess our risk within the within the organization so we can bring in open- source security intelligence uh National vulnerability database uh things like that and oops wrong way come on there we go uh and understand do we have components that are contained in this uh these this application that have a known vulnerability to them so we can see does a cve exist for that uh we we bring in sis Kev information as well and so if there's a Sev record for this particular component that needs to be concerned and addressed as well uh we have Integrations with sync it's another uh uh vulnerability scanner out there that allows us to uh bring in additional information particularly from cloud-based applications uh that you know as things change that may not been have been an initial bomb they can find stuff and they can bring it in there as well uh so that's an additional Integrations we have we have a lot of Integrations to our our products uh to enhance and and bring additional value to the to the process here so looking back at our our screen here so now that we have brought the data in the next thing we're going to do is that do that vulnerability so I can click on and we have that vulnerability listing here and so I can see that the component in question the vulnerability that was determined for that that particular version the cve information uh a summary of that vulnerability and like I said in case there is a a sisv value for it or not uh we see that that information here true or false and then if it is true the actual sisa Kev the sisa due date for that to be addressed uh and so you have that information very easily addressable and quickly do it this would be something that would be very difficult to do manually to go through all the components that are contained in those S bombs and manually check them against the cisv uh or the excuse me the the cve information from the national vulnerability database so it'd be very hard to to pull that information together in in a in a somewhat readable format in a in a very in a quick manner if something was to to happen here so now that we have the the components that brought in we've looked at the vulnerabilities we can take and look at the environment at a much higher view as well so in this case here I've only uploaded a few of them but you can see the number of components is is quite large uh 1,700 different components in in just a small number of applications so the number of components that are involved in your organization can get very large very quickly and could be quickly hard to to understand here but what's important is that I can get some statistics about this I I can see the the number of these components that are stale and our definition of stale is something that had that the version that's being used is at least two major versions behind the most current version uh so what whatever version if you're using version 1.1 that there is a there's at least the the product is at version three for instance uh so we're we're we're a couple version major versions behind is is they're using a stale version of that uh the more bigger concerned one is an abandoned uh component this is something that hasn't been our definition of abandon is something that hasn't been touched or updated in more than two years so if there's a vulnerability in that particular uh component getting something pached for it getting that vulnerability resolved is probably going to be pretty pretty hard if not even impossible depending on you know who who was doing those the the maintenance of that and keeping that up to date and we actually can build out some of these high-risk combinations here so in this case here we have an abandoned uh component that has a high or critical vulnerability so this is ones that are the vulnerabilities are higher criticals and we could dig into those and see which ones they are and then you know but the hopefully the number is you know this the abandon vulnerable is actually completely fixable is actually equal to that so with these completely fixable ones these are ones that a a later or newer version of the component would address all known vulnerabilities out there with that component so uh these are ones that we can just by by utilizing a more recent version of the software we can address uh those those vulnerabilities entirely okay so now we can we've seen that we've got the data that's come into the environment we've been we've gone through and compared it to the known vulnerabilities that are out there and of course this is an ongoing process I mean you upload it it may not be a vulnerability today but tomorrow one comes out so we're always keeping this date up to date and we will uh you know that will that that those statistics will change from day to day but now the question is if you have a vulnerability what's the next step in the process is to get that to the right team and this is where we get the response piece here so this builds this is building on our application vulnerability response uh solution which is part of the the vulnerability resp vulnerability response uh product within service now and we're going to the first step into that is to prioritize the risk figure out which ones need to be addressed first uh create finding essentially let the create a a tracking mechanism for determining uh for for tracking these these these vulnerabilities throughout their life cycle till they get patched uh getting the triage work flows getting them figured out who needs to be responsible for getting these these systems patched uh getting it to those teams and then once that uh package has been updated that software that that uh application is is now an updated one we need to update the S bombs and get those put back into the system again and once again go through this whole process again because every new version of a of a software package needs a new esom because something has changed uh it's not just a you know every major release needs an esom if you've made any change to the environment you need to update the esom and so once again as as things happen in our Ever Changing always new development world uh keeping track of all those ESP boms is is and making sure you're you're utilizing the latest one uh is definitely something that a lot of our our customers are are concerned and and uh have an issue with and so how's that process go as far as prioritizing those vulnerabilities well some of it depends upon the exploit data itself I mean is it something that's simply exploitable uh very trivial exploit that's going to drive the risk factor with that uh information in cdb you you run your this application runs upon the service now platform it has a cmdb built into it we know information about uh that application the criticality of that application the upstream and downstream effects that application has within the organization and that will drive and prioritize that information as well so we can and then that will drive the development team to to address these vulnerabilities and of course I mean obviously there may be regulations that you're dealing with as well such as CIS Kev that you have to meet uh as well in the process here so how does that work let's go back over here and look at our our console here so we went over here and we were looking at the I go back over here to my uh my Cube my shopping cart here we had our vulnerabilities in here the next thing in the process is we're going to create uh Avis or avit uh application vulnerable items uh if you're a service now customer you may be familiar with the idea of of a vit uh on the the infrastructure uh uh infrastructure vulnerability side these are application vulnerable items and so we are going to create one for based upon your your your definition of of things that need to be addressed in the criticality for them uh what we do is we create a an avit come on move my thing there there avit creation rules so in this case here I've got a couple that were created this one here I'm looking for some components I'm looking for uh log 4J I'm looking for dcom I'm looking for whatever it is out there and if I find any of those I want to create an avit for it and things like that the more common ones is you're going to be looking at it based upon uh a critical or high vulnerabilities that are impacting the the application so we're going to create an avit if there's a critical or high well I'm going to actually create a new one here and kind of show you what it looks like is we're going to do one based upon Aisa cev uh finding so uh we got Aisa cev B vulnerability ability execution order just deps which ones happens which one runs first so if this is the one I want to be the first one to run uh based upon that then I would change this down to you know a lower number than the other ones for now it doesn't really matter uh this one here I'm going to do vulnerabilities uh that have a sisa Kev record and so now I'm going to go down here and my conditions what things am I looking for to determine the creation of these aits the first one here I'm going to go here the vulnerability and I can see that I have Assist Kev and if this true then we're going to create an AIT based upon that information I would simply click on submit and we're going to uh go back over here to the things and now I have this sisv in place here and it would start running and creating aits because based upon uh cisab findings in there and we can look in the actual uh AVS themselves uh we can go over here and click on one dig into them and this would have you know risk scores associated with them uh that's part of the application vulnerability response application is to assign the risk score the risk rating uh the remediation Target we have remediation rules as far as how how quickly these these systems need to get patched uh so you can track and you know it's not just something you throw over the the fence and and wait for the the development team to get around it they have you know slas or or targets out there that they're trying to meet based upon uh you know like I said regulations and stuff in place here uh you know where it is in status and the vulnerability here but I can open up one and take a look at it and we can see that uh once again some of the same information we've seen before the licensing information the the version information here uh the application but what's really important here is the fixed versions so we have we know the version of that software that would have would that that fixes those vulnerabilities and so they just need to start using that one they need to put out the uh the the utilize that for their next version of the software so we we provide this information this information would is get passed over the development teams and allow them to to start getting these systems patched so so with that I'll turn it back over to Jason to kind of review and uh we'll go from there so we covered you know how do you store s bombs and really the best way is in that relational database um how do we search the content of a machine learnable sbom uh so we covered that and then how do we match the content inside the sbom with known vulnerabilities we covered that and then how do we turn vulnerabilities into actionable items we so we covered all four of those areas I see there's some questions in the um Q&A so I don't know if Sarah you want to read those off and we'll run through those sounds good all right uh first one I have is how can I validate I have es bombs for all of the software inversions in our environment thanks Sarah that that's actually a really good question and the the challenge is you know there could be thousands of different versions of software in an agency depending on the size different dot releases so the vulnerability response solution does not do that but we have software Asset Management so with software Asset Management you can go out and be able to pring bring back all of the licenses in your environment it's not just for security purposes you could do license rationalizations things like that but the the key is being able to bring those licenses in and then compare those to the es bombs right now it's a manual process there's a road map item where that will do the matching for you but it's a it's a start where you can start seeing these are all the versions of software I have I've got you know maybe 999 different versions and I've got 800 S bombs we know we're missing some So eventually it will get there where will will match those together but it's still a little ways off but this is a good start okay and then the next one how do you define licensing policies to align the usage with the legal department guidance for example identify licenses that are not supposed to be in use because they're breaking the license agreement I think that goes back to the software Asset Management because it it would do dual purpose so uh leveraging software Asset Management you able to bring that in you can compare that to the licensing agreement you have with said vendor and then um I think that helps there but then also helps with the sbom correlation and making sure that you've got the S bombs for that uh software okay um Can the S can the system augment the security Risk by getting results from other SCA tools like black duck and dependency check Pete can you answer that one yeah if I understand the question the answer is yes yeah we can bring in additional uh sources of data to within the the es bomb to to help with that we talked about you know like sync and some of these other ones out there I I'm not I'd have to go back and look and see what we have as far as black duck uh integration I think there is one or on it's it's definitely you know something we've talked to uh about coming out with one uh uh so it's it's in it's I think it's in flight but uh if it's not there but yeah so the ability to bring in additional information from other sources uh that's part of the the the idea behind this is that uh you can you can bring those in and utilize them as needed as additional threaten additional sources of information for determining risk and and methodologies for addressing that so yeah okay um I have another one that just how is this licensed so it's licensed with our traditional VR uh vulnerability response licensing so it's it's a component with inside our vulnerability response um for the versions of professional and Enterprise um has the ability to to bring in es bombs um we're more than happy to get on a call and discuss that with the with the person who asked the question so feel free to reach out to us and we'd love to talk to you about that um do you need to rescan to get new cve impacting those components no the cve information gets uploaded automatically we we're pulling that stuff down that information down from uh National vulnerability database automatically uh we utilize it in multiple places within the platform and so as new vulnerabilities come down uh then we compare that to existing information we already have and we'll update that based upon uh new information so no it's it it's uh it's automatic uh you know part of the the process okay and then we have one in the chat um can you use attack surface management tools to find out if the same software vulnerabilities that exist in your SCA tool match the ones you see in your attack surface I'm not sure exactly what you're asking can you be a little bit when you say attack surface tool what are you what are you referring to if you can if you can security scorecard uh let's see here can you attack can you use attack so I'm not quite sure exactly what you're going with but I'll I'll I'll address it this way is that uh we within the with with service now has a a similar tool I think what you're trying to get to is there is a we have a a newly released product called security posture management that will uh that will take information from the that we're getting from our various different service graph connectors into the CMB and allow you to search and say okay I need to know what version of you know this application is running and things like that and then you know if it's not running the latest version or it's missing that endpoint product on there whatever the case may be to result in a finding so we have that integration there uh the the integration or the the speaking of of S the security posture management and uh sbom there's not anything there today uh but there you know we're always looking for additional ways that uh products can talk together and and make a better story together connected tissues so uh I'm not saying there's not something in the on the road map I just haven't we haven't got that today but the the ability to do some of that stuff seems like it would be something that would that would make sense and could you know something that we definitely for feedback to our product management team for sure okay and then another in the chat pod licenses do not necessarily include version information especially if they are for a peral license um do you have any other helpful solutions for that so Perpetual licenses should have different version numbers uh based off of the dot releases so anytime you you've got maybe it's uh Microsoft Office and there's always going to be a DOT release for that or you you name it adobe's going to have a different version as the software gets upgraded and that they there should be sending es bombs for every single dot release or anytime the software does change um hopefully that answered the question I don't know if there was more okay um and then we have one more does es bomb give Bad actors the information they need to find vulnerabilities in our software so this is a this is a question that that that has been around since the beginning of the as bomb uh discussions and and the answer is no it really doesn't uh a bad guy is or you know a bad actor is going to find the information around software if they want to uh the FBI released a reverse engineering software several you know a couple years ago that allows for for to to do this same kind of work we talked about you know with the Assassin Das before uh so there is there's a number of tools out there that if the the the bad actor has access to the executable uh thing and and then they can you know they'll have access to Ability tear it apart and understanding it uh so this is not opening up any additional vulnerabilities in the environment you're not losing your intellectual property you're just simply saying that you know very similar to you know your food you need to know what's in your food we need to now figure out what's in our software uh you know the there's been too many major breaches out there that that people didn't understand what was what was going on to their software and and this is just a a reaction to that same reason they put in the the the food requirements you know the fdda did for buing out what's in our food we need to know what's in our software and so uh this is really designed to allow that to happen and allow us to allow you as a as a as a vendor or as an application uh purchaser to know what's going on there and be able to handle and address you know vulnerabilities that come up because we know they're going to happen and so we don't want the the the fire drill in at Christmas like we had with log 4J a few years ago we want to know what's there and be able to to handle it appropriately Jason any other comments that yeah no I mean I think that's spot on you know and even we had um Dr Alan fredman from sisa speak at our fed forum and he addressed this subject uh matter of factly and you know very similar you the Bad actors they'll be able to reverse engineer your software but if you understand what's in your software it gives you an advantage to see where the weak points are or where there is abandoned software today without bomb you're really relying on uh somebody be able to understand that and you leave leaves you at risk for zero day type of attack so having that ingredients list is going to be vitally important it's m it's one of those things that they're requiring software vendors to provide to agencies so leverage it you know you know it can be something that you store and just have or it can be something that can increase your security posture so we hope that a lot of agencies adopt it and they start using this to increase their security posture as a [Music] whole okay well I'm not seeing any more questions come through not sure if anyone has any more I want to thank you for your time and uh attendance uh if you have any questions please fre to reach out to us we're happy to discuss and do an more in-depth demo if you'd like to but uh I appreciate your time Jason yeah absolutely thank you so much for attending uh there'll be uh some information that gets sent out post this Tech talk they'll have a little bit more information on ESP bomb with our contact information if you have any questions on licensing or some things that we didn't address in the Q&A or didn't come up feel free to reach out to us be happy to have a conversation with you thank you Jason I'd like to thank all of our participants as well as our speakers for being with us today we hope the information you received during this webinar has been helpful if you have any further questions or would like to request more information please feel free to reach out thank you again and have a great day