--- title: "SBOM and Beyond - FDA-Compliant Cybersecurity Vulnerability Management" type: webinar-transcript publisher: Ketryx source: "https://fast.wistia.net/embed/iframe/cfgp6b9nj1" content: auto-caption transcript, proper-noun corrected --- # SBOM and Beyond - FDA-Compliant Cybersecurity Vulnerability Management *Ketryx webinar — transcript of the recorded session.* [▶ Watch the recording](https://fast.wistia.net/embed/iframe/cfgp6b9nj1) --- Today, we'll be doing our webinar on SBOM and beyond, FDA compliant cybersecurity vulnerability management. That's the subtitle, but we'll talk about a lot of things relevant to the cybersecurity life cycle that will include not only vulnerability management, but how that ties into cybersecurity risk management, how you transfer that work into your safety risk management process, and all the other documentation that the FDA is recommending through their recent cybersecurity guidance and previous guidances on cybersecurity, as well as the recent, section five twenty four b update to the FD and C. I'm Gabriel Pasquale. I'll be your host. And here we have Anton as well who will be bringing us through a demo of the Ketryx platform and how we can integrate your cybersecurity life cycle. We'll do a little bit more of an intro. But first, before we do that, I wanna talk a little bit about kinda why we're here today, you know, specifically. And that's typically because you are building software for a medical device, and you have a source code repository. Within that source code repository, you not only have application code, but you also have off the shelf software, SEWP, software of an unknown provenance. You know, sometimes we call this altogether third party software. And that third party software for those that have software composition analysis tools is analyzed and monitored, in this phase. During this process, we typically identify software vulnerabilities that we need to manage downstream in the process. In addition to managing the software vulnerabilities, these SCA tools will identify the software components in our application and help us create the SBOM that the FDA is looking for in premarket submissions. Following that, we have a stage that we like to categorize as the catalog store and search phase. This is where we integrate SBOMs from many different parts of your application into one unit, as well as document some of that FDA specific information such as the support level and the end of life date. Now in this phase, if we're working at a large organization, we need to think about how we share information among teams and don't require a burdensome process for each team for categorize categorizing some of this, specialized information. After that, we'll take the vulnerabilities that have been identified. We'll assess those vulnerabilities. In the case that we need to do mitigations, we'll kick off some r and d work, potentially write some compensating controls, or write some documentation for our risk transfer to the end user. Now part of the challenge, you know, comes from the next phase of this, which is everything that's tied very closely to your software development life cycle specific to medical device. So that is risk analysis activities, testing, verification, and validation. Now as we go through and use our existing systems such as PLM systems, ALM systems, or maybe an EQMS, We have a lot of documentation that's done based upon information that's found across these other categories of tools. And so what we often see is manual, you know, copy and pasting, manual process verification across these sets of tools in order to produce the artifacts that the regulators are looking for. At the end of, this documentation phase through release, we need to measure post market metrics. So one of the requirements from the the recent FDA guidance, understanding what is our time, you know, mean time to patching once a vulnerability is identified. These metrics, just like the documentation, need to be collected across a set of tools, such as SCA tools that will do the initial vulnerability identification and potentially the SBOM tools that are recording some of that mitigation information. Now, part of this process, you know, it is a loop. So we are thinking about post market and how we can support post market. But before, we have our premarket submission, which is that initial collection of all of this documentation that we then present to the FDA. And then finally, as I mentioned, the postmarket vulnerability management is something that we'll focus on a lot today. You know, the recent, premarket cybersecurity guidance is titled premarket, but a lot of the things that it talks about and a lot of the challenges it raises, are relevant to post market and how we can continue to do this cycle in real time as new cybersecurity risks emerge once our product is on the market. So first, as we jump into this, I'd like to give an opportunity for Anton to introduce himself. I'll share a little bit about myself, and then we'll switch to the agenda for today's webinar. Thank you, Gabriel. Hello. My name is Anton Ryder. I'm senior developer at Ketryx for over two years now. I got my master's degree at the University of Technology where my main focus was cybersecurity as well as automated testing, after which I joined the company, which developed software for the regulatory compliance on construction sites in the construction industry, eventually becoming their CTO. And during my time there, I also, took on the role of open an open source maintainer for a few packages that we we were using there. And that taught me also valuable lessons about dependency management in an open source project and the all the challenges that come with it. And this experience as a whole, ultimately led me to join Ketryx where I wanted to bring my experience to build software to help others build software more efficiently. Now I'll hand it over back to Gabriel to introduce himself. Thank you. Wonderful. Thanks, Anton. Wonderful. So I'm Gabriel Pasquale. I'm one of the cybersecurity's meetings here at Kedrix. Prior to Kedrix, I was at the MITRE Corporation where I helped, manage their innovation portfolio that focuses on cybersecurity. I also led a research team that, focused on embedded system security. So how do we think about the security of of systems, when they are in other people's hands? After that, I spent some time at Amgen where where I focused on AI for quality and regulatory, and it was during this experience that I ran into some of the challenges around developing regulated software. And that our founder, Erez, and, the rest is history of being off to the races with Ketryx, helping our customers release software faster. Now I just wanna talk a quick agenda. We'll we'll spend about ten or fifteen minutes. We'll do a quick overview of the FDA guidance, and regulation. I think this is important because I wanna pull out a few of the things that, typically customers have a challenge with when managing their cybersecurity life cycle. And these parts will tie in well with the demonstration that we do of of Ketryx that Anton will bring us through. And the three things that, you know, Anton, you know, will mainly focus on is vulnerability management, particularly how do we ingest vulnerabilities from SCA tools such as Snyk and Black Duck, how we do cybersecurity risk management on those vulnerabilities and do the documentation, And then finally, how we can accelerate the SDLC even under the constraints of managing cybersecurity information in order to support out of cycle patches while having as low as possible release overhead. So I like to do this, you know, quick timeline of FDA cybersecurity related guidances, and and just quickly go over them. There actually is an earlier guidance that was focused on off the shelf software. So network off the shelf software, which is not included in here, but has some relevant points. The the first guidance here is our our post market management cybersecurity medical devices. This is one that that hasn't been updated since twenty sixteen, but it has a lot of salient points on how to address cybersecurity throughout the entire total product life cycle. Now the final guidance that was released last June, content of premarket submissions for device software functions, is really the the main cybersecurity guidance. And like I said before, while it focuses specifically on the premarket content, a lot of the discussion in this guidance focuses on, you know, all of the artifacts that we need to maintain throughout the product life cycle once our devices are on the market. And following that, we have the updated off the shelf software use in medical devices guidance. And what's interesting about this one is there aren't many references to cybersecurity. This guidance is is focused mainly on risk. It talks a little bit, about data integrity and authentication and networks, but it's pretty light on cybersecurity cybersecurity relevant material. Following that guidance, we have the, oh, sorry. I got tripped up there slightly. So this is the the final cybersecurity guidance. Before was the, content of premarket submissions, so apologies there. So the final guidance for the cybersecurity, which was released back in September, here is, you know, how we can think about applying cybersecurity risk across the quality system. So to take a step back, we have our our content of premarket submissions guidance from, June twenty twenty three. And this is focused on, mostly referencing other cybersecurity guidances. And then the final guidance, which was released back in September focused on cybersecurity, security, is talking about how we can think about risk across the entire quality system. And what's interesting about this is that while it doesn't explicitly, call out cybersecurity in the OTS guidance and previous guidances, there's now a link between cybersecurity risk and risk in general across the entire quality system. So it's just as cybersecurity has become much more influential across how we think about the medical device development process. And then finally finally, I wanna drop in the select updates for premarket cybersecurity guidance here. The main thing that I'd like to highlight, from this draft guidance is just their emphasis on considering changes in the environment of use. So while we have a device that we need to evaluate, we also need to think about the systems that this device interacts with. So this is a bit of an overview. I wanna quickly go through section five twenty four b of the FD and C Act. You know, the remain basically four points from this amendment, that are relevant for cybersecurity for medical devices. The first is that we need to track, recognize, and mitigate post market cybersecurity exploits and vulnerabilities. The second is that we need to think about designing, developing, maintaining, processes to ensure devices and related systems are cybersecure. So this is, you know, the need to put together additional plans around how we're gonna manage cybersecurity for devices. The ability to make post market updates and patches to the device. So this is not only, supporting a justifiable regular cycle for security patches, but as well, in the case of critical vulnerabilities, supporting out of cycle patches. We'll talk, in in in a fair bit about how you can enable this out of cycle patching and how you can shorten that release time to support cybersecurity patches. And then finally, the the SBOM, which is a a big topic, and we'll, we'll break some of this down today. Now when we talk specifically about open source OTS and soup or OTS and soup more generally, there are four things that I like to highlight from these guidances. The first is that all software, so this includes this third party software, should be assessed for cybersecurity risks. That's pretty natural as we need to understand kind of the provenance of this software, whether it's maintained well, and whether it really supports the needs of our of our application. Second, would be the ability to document plans and managing the life cycle of OTS suit in your device. So the key one here from the FDA is understanding the level of support that's provided for this piece of software and the end of life for this piece of software. Understanding that the software is maintained by a set of contributors, kind of anonymous people, pseudo anonymous people in the world. So we need to have a good process around that. Security risk assessment of unresolved anomalies, anomalies, and introduce security vulnerabilities. And then finally, the software bill of materials, and this will include transitive dependencies. So let's just dive in a little bit on the SBOM and some of the relevant components of of what the FDA is looking for. The first is the set of minimum elements that come from the NTIA's guidance referenced in the final FDA's cybersecurity guidance. Within this, we have the NTIA baseline attributes, which are listed here. I won't go through all of them. I will highlight the the final one, which is the the relationship, and we'll dive into that on the next slide briefly. Before we do that, I just wanna point out that the two other elements that that come from the cybersecurity, the FDA guidance, are are the software support level and end of support date, which we need to, you know, catalog, for each of our dependencies and, provide within our. Now let's talk a little bit about this relationship because I think there are two important points that come out of it. Here on the right, we have kind of a standard dependency tree that's actually pulled from one of these guidances. We have two different applications that depend on three top level dependencies, and those dependencies depend upon one transitive dependency. So the key key part here, to identify is first that you need to not only track transitive dependencies, so the dependencies of your dependencies, as well as vulnerabilities that could emerge from those transitive dependencies. But we also need to provide the relationship to the what they call the primary component. So for dependencies in your system, what application do they relate to? And, potentially, if your, you know, tooling allows it, what part of that application does that dependency relate to? That level of traceability of the relationship between your SBOM components and your application can help significantly in the risk assessment process as we manage vulnerabilities. Three other things from the guidance, and then we'll we'll move on to the demo. The first is the the need to assess safety and security risk of each device within the environment of use. And this looks slightly different, in the premarket versus the postmarket. In the premarket, we are not only identifying software vulnerabilities in our SIP and OTS, but we're also generally identifying security risks in our application. This might be that our device doesn't have a password or might be operating on an unprotected network or maybe patient data isn't encrypted on the system. In this case, you need to assume you know, decide whether you wanna assume worst case exploitability of the security risk. If you don't wanna assume worst cases exploitability, you need to go through and justify kind of why you're making that assessment. It could be that the device is always in a locked room, and there's some other compensating control around that, but you need to have some justification. If you don't, then you need to identify kind of relevant security risks that you have documented, reevaluate those risks, or potentially create a new risk. In the post market, we have vulnerabilities, and in this case, maybe software vulnerabilities that are reported against our application. In this case, we need to evaluate their exploitability, use systems like the common vulnerability scoring system to assess them. And then from there, determine whether they're fall into an exploitable category or unexploitable category. If they're exploitable, we need to identify relevant security risks, re potentially evaluate those security risks we have in our system, or potentially if the vulnerabilities introduce a new security risk, go ahead and document that in our system. And Anton will show you kind of two different workflows that we have, which is, one, the ability to document cybersecurity risks, and two, a lean process for evaluating vulnerabilities and doing impact assessment on the vulnerability items specifically. Now the two other last two things that we'll point out, are focused on on traceability. The first is, you know, the guidance calls out the need to provide traceability between your threat model, cybersecurity risk assessment, SBOM or the components within the SBOM, and testing documentation. Now what does that look like? We have our SBOM component, which might be a a piece of open source software. This piece of open source software might be used by certain aspects of our system, maybe a software item in sixty two three zero four speed. Then for the SBOM component, we have vulnerabilities that originate from it. That vulnerability could be exploited by a threat. This threat would be contained or originate from our threat modeling activities. Included in threat modeling, we might understand a set of threat threat services. So where a particular threat might act on our application, as well as a set of assets. What are we trying to protect? That could be patient data, and so on. And then finally, how does this threat and, therefore, the relevant pieces of our application relate to risk in our system? This could be a cybersecurity risk, or in the case of a of a safety risk, we might transfer that risk to our safety risk management process. And then finally, how does that risk tie into our risk control measures or or mitigations, and finally, testing. The second kind of traceability focused, item that I'd like to focus on in the guidance is the need to conduct security risk assessment on unresolved anomalies. So in the case that an anomaly that's identified during development or testing, has a cybersecurity relation to it, we need to do some documentation and and provide a report. So we might have an anomaly that's been determined, and we've documented it in one of our systems. It might be related to a requirement such as either specifically a cybersecurity requirement or a requirement that just has a cybersecurity context. This requirement itself might relate to a risk in our system, whether that's cyber or safety. And the anomaly, which in itself is now a vulnerability, could be exploited by a threat in our threat model. And finally, flowing through the risk management process, we have our our mitigation for this anomaly. Maybe the mitigation is it's just fixing the anomaly. And then finally, testing to ensure that anomaly is properly implemented. Okay. So now, you know, we kinda did a deep dive on the guidances. I'd like to do a quick poll and understand from the audience, you know, what are your top challenges? We kinda went through what I think some of the the challenges are, and what we what we see in our customers before they start using our platform. So what are those top challenges? Yeah. And so we'll we'll share the the poll results here in a moment. But I'm seeing a lot of, yeah, challenges around just generation of documentation in general. Okay. So I will go ahead and, yeah, share these results. And let's just scroll the through these real quick. We see, yeah, some challenges around documentation in general, some notes on the continuous monitoring of cybersecurity measures. So how can you automate and monitor cybersecurity testing? And then on the reports and documents manually, a lot of vulnerability reports being generated manually. And this is this is pretty typical of seeing a lot of the reports today being generated manually that contain cybersecurity information. Wonderful. So now, you know, now that we've gone over, a bit of a a summary of the guidances and regulations, you know, I wanna hand it over to Anton who will talk a little bit more, about these challenges, and then he'll dive into the product and give us a tour. Wonderful. Thank you, Gabriel. So let me just alright. Thank you. So first, I wanna just briefly go back to this disconnected cybersecurity life cycle that Gabriel talked to in the beginning. And we wanna now go from this abstract to the more concrete and how Ketryx can would help you to do that. So in the beginning of the cycle, we have this analyze and monitor phase. And, typically, some common software composition analysis tools are used like Veracode, Snyk, Black Duck, and others like we've seen in the post. Additionally to that, often either the same tools or additional tools will then perform also vulnerability detection on these third party libraries or super items. The output of these tools can be standard generated SBOMs in formats such as SPDX or PsyclonDX, both of which are supported by Kedrix. Following that in Kedrix itself in this catalog store and search phase, especially if of many product products or projects, you can have a centralized software supply chain where you can add additional information to these super items, like level of support, end of life, the security and reliability impacts, as well as internal metadata, for example, the usage within this product. So so having the centralized software supply chain also helps you manage this shared information in one central place and centralize the super approval workflow throughout all your products instead of having to repeat this process, manually copy pasting information back and forth, etcetera. And using this enriched SBOM, you can then move on to your safety and cybersecurity risk management process, which, as Gabriel just talked to, influence each other. Sometimes you have to reevaluate risks or create new risks. There's the the threat model with threats, vulnerabilities, assets like we've seen in the relationships. And all of this tied together to this compliant SBOM because now, as we've seen, it's not just enough to have this metadata on soup items, but they they all also, perform this vulnerability, assessment and if necessary, have mitigations in place. And then after that, there's the trip distribution phase that even if you found the vulnerability in your own product that you would disclose it, but we wanna focus during this demo on the release artifacts. And we've seen in the poll just that documentation is one of the major pain points right now. And we wanna go through the like, briefly show the cybersecurity risk management file, vulnerability report, etcetera that can be delivered either as human readable, formats such as, Word or Excel as well as more machine reader performance such as SP DX or CycloneDX. And, of course, in the end, we wanna close the cycle with this post market vulnerability management. Having said that, we wanna be come to the next slide where we talk briefly about the validated CICD. We can jump into the demo here, Anton. I think that might, make sense, and then we'll come back and and talk a little bit about how we integrate Snyk deeply. Alright. Let's do that. So first, out of the three workflows that we wanna show, we're gonna start with the cybersecurity and the SPM traceability using, Jira. So we've set set up a demo project, and you can see here you would be able to just create a new project, but we wanna show you a project as we set it up. And we just connected it to one of our Git repositories with a certain analyst branch and the release rep pattern, which, would enable Keltriq to automatically pick up tags or branches and connect them and relate them to versions in Keltriq and Jira. We can also see that we enabled git based items, which we which enables, having items within git pop up and populate in the ALM with relations and everything. And one thing that we will see in the third and last part of the demo is that we, enabled incremental release codes, which is this out of cycle updates for critical vulnerabilities which we wanna demo right now. So let's start. We'll go to the s pom, and we wanna review these, dependencies that Ketryx was able to pick up, on its own. For the for this part of the demo, we wanna switch to version two, and we wanna focus our attention to the ones that have moderate or major risk levers. This is something that, is user defined, and we wanna focus on high and critical severity vulnerabilities. And as we can see, one pops up, r d f web, and we wanna see basically, we want I wanna give you a brief overview of what this is. So you can see our default. There's this automatically from the package, from the package information, we already have the project website and the registry entry, the manufacturers, and the license. In this case, there's also an intended use, which we which which is the description of the library. There's an extra security impact, the justification for it, the reliability impact, its justification, and as well as additional notes. We can also see that the used versions in our project and the accepted versions, which is, something that you can set in Ketryx itself and the risk error. Let's see how that would look like. For example, for the issue tracker, we can fill out missing information. So this is usually for open source projects where the the the bugs would be reported and anomalies. We can also see that right now, everything is empty because this is a pristine project. And down below, we can also see maybe more more interestingly the versions to accept, which is not the versions that you are currently using, perhaps. But you can set a certain version, all of the version of the library because, you don't care or none because you think this library should not be in this project at all. We can also see what we saw on the s pom, table that we already previously set this to be a major risk level. So this is not something that is automatically populated, but by the user. And, we can already connect through the items from Jira or, some other systems, from to our ALM. We can connect these super items to requirements. I could just pick some, items right now just for demonstration purposes. We can connect the risk, of course, and the test cases. Because, again, we're there's also the whole ALM, but this part of the day demo will focus not on the ALM and the risk management. We can also see this test would have the latest execution we would pass. But, again, we're gonna focus on the cybersecurity aspect of the, in this demo. So the s pom page is a subpage called vulnerabilities, and we can see all the vulnerabilities that, Ketryx was able to detect, in the use dependencies. This is automatically supported, sorted by reported on, but now we really wanna focus on the highest severity vulnerabilities in our project. And we can see that some, of these vulnerabilities were already assessed partially at least by someone in in our, organization. You can see the details of this vulnerability with with the description, its CVE ID when it was published, severity, and scoring as well, as well as the affected versions. We can see that part of part of the vulnerability impact assessment was already performed. So it is exploitable, and the justification was, or is that the device is exposed by our network or by its network, interface. So we're gonna go ahead and edit this vulnerability impact assessment to complete it. As you can see, the selected vulnerability on top, the resolution By out of the box, we offer free default values, but this is fully configurable to be as many, or as little values that you that you wish. And now to complete this assessment, we wanna connect the risk. In this case, we wanna use from we can we can see the material ID k d six, the insulin dosage risk. And for the sake of the demo, I will not provide a rationale for now, and we wanna connect the mitigation. And in this case, this would be the infusion limitations. We can see here the infusion limitations is a requirement. So we add this and save the changes. And once saved, we can immediately see the related risks popping up here. So now we did this in CapEx, but now we wanna, shift our focus to Before you jump into into Jira, we just have a question I'd like to answer relevant to the SBOM, and kinda how we connect to systems. So the question was, would the source code be imported onto Ketryx server to do this analysis, or can we have the Ketryx installed on one of our internal systems to scan our source code? And this is a great question. We support both options. We have a native scanner, that can enable the identification of vulnerabilities in common web languages. In the case that you have some specialized analysis software, this ties back to the diagram that that Anton showed. You could run that on your server and then report an SPDX file, a CycloneDX file, one of these machine readable formats to Ketryx. And then Ketryx will enable you to manage all of the documentation around the vulnerability management and and cyber risk management process. So we support both both models. Thanks, Anton. Thank you. So now we wanna shift our focus to Jira and especially this risk. So we're gonna open this risk, and we can see all these details, the insulin dosage risk, the hazard the hazardous situation. We can also see its hazard type, the risk control measures associated with it, the risk assessment methodologies, etcetera, And how all of this can also be done in Ketryx and what the Ketryx app offers, We can see it on the bottom here. First of all, how we make Jira compliant is, first of all, the traceability. So now we can already see that this risk is not just connected, to k d five, the infusion limitations, and the software item authentication system, but also already to our, vulnerability that we just assessed. And on then so traceability is the first part. The approvers are the second part. So we can see that this risk is in a closed and controlled state because all relevant groups, again, this is fully configurable, have applied their digital signature in a party eleven compliant way. And below that is the risk management widget. All of both of these, maybe you could mention the traceability approvers and the risk management widgets that the Ketryx Jira adds to every ticket, to serve to the tickets in Jira. We can see the risk analysis that was formed in it, the initial risk analysis, as well as the residual risk analysis. And now before moving on, I wanna briefly also show that we have this anomaly here. Gabriel touched upon the topic that we you don't just have, threats and vulnerabilities, but you also have anomalies. And in this case, we can see that this anomaly is connected to cybersecurity requirement in our ALM. Right. Before, we move on, Anton, we have a question. And the question is, so the big value of Ketryx is bridging the gap between SBOM and FDA compliance. And I know you're kind of talking about that now, but I think it'd be great to talk about, more generally, you know, kind of how the SDLC can be tied in with, SBOM management. Yeah. Yeah. So first to, you know, preface this question or or I guess the answer is that Ketryx is is not only this SBOM product. Ketryx has a full, what we like to call, connected life cycle management system. It might be most similar to an application life cycle management system where we enable you to to run kind of the whole software development life cycle. That would include requirements management, design output management, pest management, many of your quality activities running CAPA processes, complaints processing. We enable you to run all of these processes across commonly used developer tools, such as Jira as Anton is here. With respect to SBOM and cybersecurity in general, yeah, our key point is, you know, how do we streamline FDA compliance related to cybersecurity? And what this enables, is a broader impact on release time. So in the second part of this demo that Anton goes through, we'll show you what it looks like to make a small change, maybe a cybersecurity update, and go through a full release process with all of the documentation generated, automatically. So stay tuned for that part of the demo because I think that will you'll see where where the value really comes in once we automate the FDA compliance relevant to cybersecurity. Right. Great. Thank you. So we've seen how the traceability works in Jira, but now we wanna go back, and we just edited our our vulnerability and performed this assessment. So now we wanna transition this item to resolved. It is now ready to be reviewed. And now once it's in this resolved state, we can also approve it. And this is the part which is the which is also possible for open items or resolved items in Jira in this approvals widget, which will then say there's a, there would be a button saying that this is now approved this ticket. And we're gonna do the same, just not in Jira, but for this vulnerability, we're gonna do it in CapEx. So we press the approve button. We use biometric authentication. So this is a digital signature that I just applied using biometric authentication. In this case, it was a fingerprint reader. I confirmed that I want to approve this item. I see, of course, before, I do this which items are meant. I press approve, and that will then put this into a chaos or controlled state. Having done that, I also wanna go, to the risks one more time, but this time in in Ketryx itself. So we can see we have the overview of all the risks in our system, at least for this version that we're working on on with this demo version two dot o. And as we scroll down, we can I wanna focus on these two particular, risks, KD thirty nine and KD forty? We see, of course, the hazard, the sequence of events, the hazardous situation. I wanna what I wanna highlight is that for, the first one, a risk assessment, using following ISO one four nine seven one was performed. And for the one below, cybersecurity, risk assessment was performed. So while this this uses and, again, this is fully configurable, the risk matrix as you use, in your product with maybe medium, medium, severity and the probabilities in the cybersecurity risk, we use the CVSS scoring. So the initial probability here would have been, for example, particularly for us or high for the severity. We can see the risk control measures or mitigations that were put into place, And we can also see that this is a software item, but this is also covered by the test itself. And, of course, these tests cannot just be just exist as tickets in in KedX or in Jira, but you can also report automated tests to and connect them from your build to these items directly in CapEx. And moving on, we can see that using these risk controls, the residual risk is now acceptable. And now we have all of these, different things in place. And now we won't gonna go to the releases because now we're in the phase where we wanna have the release artifacts. And in this case, especially the documentation. So we went ahead and already, generated some documents, but we can also just, generate, for example, the s one report, live. Again, this will also then follow the same approval workflow. We would press approve, a dialer would pop up, ask for party level compliant, digital signatures, And there's also release controllers. So if you require up to date and approved documents, the release and the the release or the approval of the version can be gated that way. But everything is fully configurable. So especially during onboarding as you transition to this process, you can, start less strict and be as strict as you want. And now I'm gonna, show you at least, the vulnerability report and also the cyber risk management file. These are the two of the built in reports that Ketryx offers. And let me move the report here that we generated. And you can see this is an Excel file. Every row is one of these vulnerabilities, and we can see that everything is here, the severity, the score, which ecosystem, which are the affected versions, which versions you are using, and as well as the description, the URLs, etcetera. But we also because we talked about enriching these s bombs, in this case, it's the human readable form, not the cyclone d x that it can also be exported, is that here's the connected risks, mitigations, resolution, etcetera. And in this case, because we did not perform, in this demo, the resolution for all the vulnerabilities, I'm gonna scroll down to to this line so you can see this is the one one of the dependencies that, the vulnerabilities that we just assess for risk. So it is exploitable and why. And because there's a few of them, we can also then see for for some of them that we would have full traceability in this document as well where we link to the related risks. I think I'm in the wrong column in this case. Yeah. So Yeah. It's important to note that these, you know, these reports are kind of fully configurable. So we have a templating engine, that that extends not only in in the word templates as Anton will show shortly, but also into Excel templates, enabling you to build and report on any traceability that's in your system. So the common one for cybersecurity would be showing from vulnerabilities to the dependencies, to the software items that those dependencies are related to, potentially into the threat model, where the threats emerge, and so on. Great. Thank you, Gabriel. So that is a very good point to note. These are the built in documents that we offer, but, of course, with using this very powerful templating system, you just supply your own templates with your own branding, own styling. And using this templating engine, we will then populate audit data that is, in Ketryx into these documents. So now I wanna briefly show one of the, Word documents. So this would be the cyber risk management file. And once this is already loaded, we can see in the table of contents that first the risks are listed, then the requirements, and then the dependencies. So we can see all the information for of this risk. It's this unauthorized access. The, we can immediately see this, risk in Ketryx if we wanted to. We see when it was controlled, when it was introduced. Again, all this information that you could see in Chira and in Ketryx is also here. And, of course, the initial risk assessment. And we can also see the risk control measures with links to them, so in which they are. So the infusion limitations and the use of authentication. And then there's a few more risks, but I wanna go to the requirements. So one of these requirements was the infusion limitations that have parent requirements. There's also rationale filled out. We can also see, this is risk controlled for insulin dosage risk and amyloid risk excess and even how how it's tested. So there is a test case. It has a test execution, and it passed. So all in one document, you can see the full traceability from all your, relevant items. And, again, fully configurable. If requirements are something you would not like. You this is pretty configurable to just not be there. If you want software items, this could be included. And just briefly for the last section, here's the dependencies. And if there's vulnerabilities, they would be listed. And I wanna highlight the r d f web one because that's the one we performed the assessment on. So we can see it's a risk level, the declared version in the package manifest file, the locked version, which is, which means that this is the complete version that it was resolved to if this were the first client version range and or it's vulnerabilities. Here, you can own you you can see the the CVE, ID and its, title and score. And, again, this could be then seen in the vulnerability report. You could then look up all these vulnerabilities and how they were assessed. And now for the last part of the demo, I wanna what we what we did here, I wanna show basically how this out of cycle, updates that Gabriel spoke to earlier would work in Ketryx. So for this part, maybe it's good that we briefly look at this slide because what we're gonna do here is, basically, how do we do validated CICD supporting this out of cycle updates? So we will use, Snyk and GitHub as an example, but any other tool that could open automatic pull requests to fix vulnerabilities would also work. We don't Ketryx not only supports GitHub, but also Bitbucket, GitLab, and any other, really, like, Azure DevOps. Pretty much anything that hosts Git is supported. And how do we do validated CICD? So maintaining party eleven compliance, generating these evidence documents that we also just saw, and gating these releases with these required controls. So what we're gonna see is Snyk will open a request fixing a vulnerability. The regular CI and CD builds will, start, for example, your test suit. At the same time, a new incremental release will be open in Ketryx, with the evidence documents that have the electronic signatures applied, the approval that we've just seen, and that will then ungate the request after which it can be merged and then deployed. So we've prepared a little demo here, again, with Snyk. We can see that there are certain package manifest files in our demo repository, and we wanna go to one where we see that there's at least one critical vulnerability. So we can see here and we again, we wanna build the for r d f web because that's the one we are interested in. And, usually, what you would do is you would click this button saying fix vulnerability. You would be, greeted by this screen where you can select one or many vulnerabilities. And once you've done that, on the bottom, you would press this open, fixed PR button. And we did this prior as preparation for this demo, and we can see that this, per request was opened in Kedriks, in Ketryx in GitHub. So we can see this was opened by by Snyk, and we can see that all almost all, CI checks passed except this check p r one. So let's have a look at that. And we can see we could not report this bill to Ketryx because this version and we're gonna see that in a minute in a in a second. The security upgrade out of web was not released. So in Kedwix, we can see that this incremental release, not just our regular versions one and two, are there, but now automatically this incremental release was created. So when we check-in there, we can also see that this is based this version is associated associated with a code change request, number five, and that was the this pull request that we've seen here. So now everything everything that is left for us to release this version and approve it, Hardis reject the dependencies. So now we click on dependencies. The s pon table is filtered to just show this one dependency. We can see that something was changed. So while we, declared that we want version two dot one of Artif web, Snyk has updated it to be more and more newer versions that do not include this vulnerability that is, set out to fix. So what we're gonna do is we're gonna go here. We will edit this dependency info for us to allow these versions that we would now like to see fixed. So we're gonna say custom in this case and to the two versions that are necessary for us, for this, s pom to be accepted again. So we're gonna approve it at this oh, maybe first, I'm gonna show you, that it has changed. It would now be acceptable. So before, there was this cross, and now there's a check mark. So now we can either on the dependency detail page or for any number of dependencies, we could approve this dependency. Again, I'm gonna apply my electronic signature, confirm that I want to approve this, and hit the approve button. So now we can see that it is accepted. And going back to this re to the to the incremental release, we can see that now the release checklist is complete for this version. So, again, I'm applying my electronic signature. Confirm. And this version is now released. And this is now the part that that ungated the merging of this pull request. So we can see once we rerun this job that once this build task, this check PR task is successfully completed, it will just take a second, that now then all the checks are done. We applied our signatures in Ketryx, so there is an approval workflow, r d eleven compliant. We see that this is now, running through. And now every order checks have passed, and now I have conflicts with, with the the target branch, but that is that is what live demos are all about. Let me just quickly check. So, yeah, we would need to resolve this conflict. Let me just quickly do this. This is where it's clear that you're a developer. You're so you're so fast with it. Yeah. I've I've seen this before. Usually, I would not, use the browser for it, but for the sake of So, again, we've just seen that this out of, out of psyche update for vulnerability was on basically, Yeah. First of all, fully traceable because we have this per request that we have as a code change review in Ketryx that I maybe haven't shown you. It made you noticed that for this and, again, just to cut the demo short and because we demonstrated already the documentation part and the generation, that for this incremental release, we did not have to generate documents again, but this is because we deliberately disabled this release gate to speed this up and because we've seen shown it in the in the previous, demo. So now, really, everything's green. We can merge this per request and have this out of cycle, update. And I believe that concludes the demo. Wonderful. Thank you, Anton. And and going through that, you know, the fixed process that we just did, kind of live, you could see a few different stages in that pipeline, which were, one, the testing. So automated testing, those test results are then reported up to Ketryx and associated with their test protocols. Whether those test protocols are defined in your code, such as maybe in a in a Gherkin style cucumber test, or if you wanted to find your test cases in an in another system such as Jira. The other stage that was in there was the creation of the SBOM. And so just to tie this all back to our big diagram here, that create SBOM stage was executing in the build pipeline, which leveraged an external tool, Snyk, to generate that SBOM and then enrich it through the rest of this process within Ketryx. So if there are, you know, kind of three things that I think you should remember, from this webinar, the first is kind of how are you thinking about catalog storing and searching SBOM components once you've enriched them with data, from your teams. So that would include level of support, end of life, security and reliability, and any internal metadata such as how those SBOM components relate to your application. The second is how to tie your SBOM into your risk management process, not only cybersecurity risk management, but also your interconnected but distinct safety risk management process. And then third is how you're gonna generate all the documentation that is created throughout this process. And on the right, we have a list of those release artifacts, and we'll share this presentation after so you can have this diagram.