--- title: "Building an Audit-Ready Secure SDLC" type: webinar-transcript publisher: Ketryx source: "https://fast.wistia.net/embed/iframe/jdjrhjpik7" content: auto-caption transcript, proper-noun corrected --- # Building an Audit-Ready Secure SDLC *Ketryx webinar — transcript of the recorded session.* [▶ Watch the recording](https://fast.wistia.net/embed/iframe/jdjrhjpik7) --- Alright. like, we've got most of the poll responses coming in right now. If you haven't done that yet, there's still a little bit of time to do that. But I wanna go ahead and before we start, just cover a few administrative notes here. This webinar is being recorded and and will be sent out along with the slides following the conclusion of today's discussion. We'll also share other resources in the chat window during the webinar, so make sure you're taking a look there, for anything that we post. If you have any questions, for us at any time, feel free to use the q and a feature in Zoom to post them. We have several colleagues on the line, Isken and Charlie, who, will be servicing your questions from the chat to us throughout the presentation, and we'll do our best to answer as many as we can live. But we also have a a team full of subject matter experts that are staffing our chat to answer any questions that we can't get to on the air. If at any point you have to leave, please feel free to drop off. On your way out, you will see a survey. We'd really appreciate if you could, take the time to complete that and give us feedback on the webinar today. Looking at the results as as they came in, you know, I think as as we look across the board, we asked a couple of questions about cost and effort to complete a patch release, and we see sort of the the bulk of folks say that there's at least some budget consideration required for those patch releases, and and, several as well indicating a high cost factor to that. Really, I think, you know, there's some hidden cost as well as we as we look into the effort required for your team to complete a patch release. Many folks here are talking about sort of the significant planning and approvals required to complete this and sort of all of the coordination required across the board. And so, that's not uncommon. We hear that a lot from from many of our clients, when they come to Ketryx, and we'll talk about some ways to sort of streamline some of those processes as we move in to the discussion and the demo today. Before we do that, a quick background on, your host today. My name is David Semko. I'm the head of implementation here at Ketryx. I started my career in the US Navy where I was a nuclear engineer responsible for maintenance, operation, training, and auditing of nuclear power plants onboard US aircraft carriers in the Pacific fleet. After the navy, I attended MIT where I got my master's of science in systems engineering as well as an MBA. I then spent, many years with Amazon where I I had roles both as a principal in network engineering and a site leader for several operational sites. And now at Ketryx, as the head of implementation, I'm responsible for the onboarding of all of our clients, from the this the post sales process through operational within the platform and really get a chance to sort of experience many of the pain points that that, are you out there are experiencing, and and help our clients sort of achieve the success they're looking for and, within Ketryx. And I'll pass the mic over to Gabriel to introduce himself as well. Thanks, David. Absolutely. Hello, everyone. I'm Gabriel Pasquale. I run the solutions engineering group here at Ketryx. Prior to Ketryx, I started my career at the MITRE Corporation as an embedded system security researcher. I sat down the hall and and worked with the folks that that developed the ATT and CK framework that maintain the common vulnerability or enumeration or the CVE database, as well as other resources leveraged by the medical device industry, such as the MITRE CVSS Rubrik, and a number of the other papers that have come out, recently from MITRE, specifically focused on SBOM normalization, something we'll talk about today. After MITRE, I went on to do a master's in computer science and an MBA at MIT, and then spent time at Amgen focused on applying AI in the manufacturing space for quality and reliability. Ran into a lot of the challenges of developing validated software, particularly software or AI that needs to be updated at a rapid pace. And that led me to Ketryx, where I've been spending the last two years helping folks understand, the solution that we have to offer and, implement that. So looking forward to this conversation today, and, I'll pass it back to David. Thanks, Gabriel. So today's conversation is is really sort of up against the backdrop of medical practices and individual patients suffering from significant cybersecurity attacks. The lawsuits related to the divulgence of patients' information, including images, video, diagnostics, they're they're costing our health care system significantly, and and follow on indemnification action can result in costly legal settlements for settlements for medical device manufacturers. This cybersecurity, you know, it's a it's a complex issue, and it's exacerbated by the legacy IT infrastructure, lack of specialized cybersecurity talent, and increasingly complex cloud enabled devices. You know, on the slide here, we see, on average, over six exploitable vulnerabilities per med device, and a large majority of the attacks over seventy five percent are exploiting vulnerabilities that have existed for more than two years. And this is leading to sort of many medical devices at the end of life with little to no security patches or upgrades. We'll do a deep dive into sort of building a secure SDLC and identify some of the common challenges that product security compliance presents and why it's difficult to do it specifically at speed and at scale. Yep. This webinar should give you the tools and questions to help evaluate your organization's process and technology to identify gaps, reduce manual documentation, and release safer and more secure software faster. For our agenda today, we're gonna go over a a few things. And, you know, we'll we'll we'll talk about what it means to be audit ready for common audit questions. We'll take a look at what a secure SDLC looks like and a typical risk management workflow as well. And then I think the most exciting part of the webinar, Gabriel will take us into the product itself, and we'll talk about some strategies to to unify your security tools for an auto ready secure SDLC. The complexity of building medical device software is growing rapidly, and that's caused by a lot of things as we mentioned a couple slides ago. The increased connectivity of the Internet, increased use of OTS software. And this challenge is only getting harder as AI and ML enabled products are accelerating this trend. Generating the documentation that's required, is really hard to keep up to date, and some of these audits are happening, as we know, in between product releases. The bottleneck in the process is often trying to take sort of all of these items on the left of this slide and push them through your vulnerability and cyber risk management process to generate the artifacts of compliance that are required. What we all want at the end here is a consistent set of documents for each release to manage the post market patching of vulnerabilities for those devices quickly, but a lot of the current processes that we have are manual and make that extremely difficult. And now not only do organizations have to cope with that complexity, but they also have to comply. They have to comply with section five two four b of the FD and C Act, which has legal requirements for cyber cybersecurity. While while this primarily applies to premarket submissions, it also has postmarket implications as manufacturers must ensure ongoing monitoring, patching, and vulnerability disclosures after after the device is on the open market. The medical device manufacturers and other organizations, as guidance applies to, must track, recognize, and mitigate post market cybersecurity exploits and vulnerabilities, design, develop, and maintain processes to ensure the device and related systems are cybersecure, Make post market updates and patches to the device and associate systems available to address two cases. One, known unacceptable vulnerabilities on a justifiable regular cycle, but also critical vulnerabilities as soon as possible out of cycle. And then provide a software bill of materials or SBOM, including commercial, open source, and off the shelf software components. So as you think about this, what what might an auditor ask your organization to make sure you are complying with all of these requirements? Here's a sampling of a few questions we have seen internally working with some of our clients. One, how do you perform traceability across your verification activities? How do you track and manage third party components in your SBOM? How do you secure your medical device software against cyber threats? And how do you keep your software life cycle compliant with changes in FDA and EU MDR regulations? So what does it mean to be audit ready? Well, the increased complexity makes answering these questions and maintaining audit readiness more challenging. To answer those earlier questions and be audit ready, organizations must have an up to date SBOM to ensure visibility into all software components, be able to walk a traceability link end to end at a moment's notice, and stay aligned with regulations, which are, as we know, evolving frequently. Achieving these goals was already difficult and is only getting harder. Before I pass the mic over to Gabriel now, we'd like to understand a little bit more about how your organization is handling audits today to help inform the rest of our conversation. Yeah. And I think the big challenge we'll we'll talk about, you know, particularly over in, the demo and in the next few slides is is that what we see from many organizations is when they go through a release, they do have an opportunity to kinda fully update that final cyber risk assessment. But when it comes to an audit that might fall in between releases, that file is typically out of date, and it requires folks to kind of go through different systems, Jira, a requirements management tool, Azure DevOps, all of these tools to collect, evidence to present to the auditor. And it's a similar problem in terms of doing risk assessment of vulnerabilities in that you also are collecting information when you are identifying risk inputs. For your risk analysis, you're often looking through different systems. You might have your threat modeling system. You might have Jira today where your bugs are tracked, etcetera. And so we'll we'll talk a little bit or maybe the majority of the bit on how to link all this information together to accelerate that process. Looks like we have some poll answers coming in. So handling audits is through through documents, through system of work, so that makes sense. And that aligns, you know, very well with what I just described there of a combination of documents producing evidence. And then in the case that, you know, information hasn't hasn't made its way into evidence documents, you know, needing to go into the systems of work. So that makes sense. Alright. So with that, we'll share those share those poll results so everyone can see them. Really the main focus is on kind of, focus on manually with documents supporting audits as well as the the systems of work. So that makes a lot of sense. Share those results and then we'll get started. So let's jump in and talk a little bit about the a little bit more about the problem and a little bit more about the solution. So what we see in the industry today is a transition through a set of problems that are being solved. The first set of problems was focused around how to generate an accurate SBOM. Many different platforms, many different technologies that are used to develop devices. Mobile, web, iOS, Android, all of these different platforms and languages require a heterogeneous set of tools to produce an accurate SBOM. Producing a c plus plus SBOM is gonna require a slightly different tool than that of, that doing for a web language. The second problem that was faced and is still currently faced by the industry is this challenge of normalizing our SBOMs to ensure that all of the dependencies and vulnerabilities that we've identified are properly matched together. And in addition to that, that all of the evidence metadata that we collect is integrated into that SBOM so that we can have, I guess, a compliant SBOM with section five twenty four B and guidances from the FDA. And so the challenge here really that we'll focus on is this gap between the tools that we have acquired to create accurate SBOMs and all of the evidence that we need to produce at the end of the day. A cyber risk assessment, our vulnerability report, documentation on compensating controls, risk transfer documentation. All of these evidence that, elements that need to go into our our DHF and and be present for an auditor. Now how we split up these two sections is one, on taking this standard SBOM, this SBOM that comes out of your existing SBOM and SCA tools and enriching that SBOM with information like the level of support, end of life, internal metadata such as whether this dependency has been approved for use in a different product of a similar risk class, and any additional analysis, for example, existing analysis that's been done on the same vulnerabilities for different products. The second phase and a focus of today will be how do you bring this SBOM, the components in that SBOM, and the vulnerabilities that have been reported against those components through your cyber risk management process, allowing you to tie the information in the SBOM into your threat model, transfer cyber risks that are identified into the safety risk management process where applicable, and then ultimately collect all of the vulnerability assessments and remediation documentation so that it's present in downstream evidence available for an audit or for a submission. Now I I think that we all agree that going through this process once is is quite challenging. But the real, future problem is that our device is gonna be on the market for many years. And our requirements to do post market vulnerability management will only compound the cost of any inefficiency in the process of evaluating vulnerabilities and conducting risk management on them. Now this particular diagram is as I'm sure many folks in the crowd here believe is a bit of an oversimplification of what a vulnerability in a cyber risk management process really looks like. And so if we go on to the next slide, we have a bit more of an expanded view of what a security risk assessment or vulnerability and cyber risk management workflow looks like. On the top left, we have a place in which we are collecting security signals. This could be from operational monitoring. We'll focus mostly on SCA and vulnerability detection tools that are identifying vulnerabilities that have been reported in the field and associating them with components of your SBOM. Following identification of these signals, we go through a vulnerability analysis. And that involves collecting a set of risk inputs that are related to that vulnerability. Where within the architecture of the product is does this vulnerability live? What aspects of our threat model might inform this vulnerability? Or even what existing security risk controls might be controlling this this, vulnerability or this risk? And where might we have gaps? In the case that this vulnerability needs to go into remediation process, you might kick off, defect management process in Jira or your CAPA management process in your CAPA system. Ultimately, you need to bring this vulnerability and its associated kind of issue or ticket through a cyber risk evaluation, identification of additional security risk controls to implement, implementation of those risk controls and verification of their effectiveness, and then finally a risk management review at the end to evaluate all this evidence and formally produce the evidence documents that you would include in the submission or present to an auditor. And the main challenge that we'll highlight today is that there are many systems involved in coordinating this process. All the way from SCA and SBOM tools like JFrog, SonarQube, dependency track, to spreadsheet, tools like Google Sheets, Microsoft Excel, and ticket management systems like ServiceNow and Jira. So those are all of the systems that are involved in just coordinating the work. And then when it comes to documenting the risk control measures, doing the implementation of the controls and the evaluation of those controls, we have a whole another set of systems. Whether that's a requirements management system or system for doing risk management such as Polarian or Jama, Or for teams that are using Jira for kind of end to end development of design controls, we have Jira. So with that, I think what I wanna highlight before we go into the demo is how is it possible that we can accelerate the vulnerability and cyber risk management process for all of the security signals that we're receiving from the various security tools that we have when the work that we're doing is so fragmented across tools and the only way in which to align all this information is through manual activity. And the three types of manual activity that we see, within our customers before we start working with them are one, manual copying of information from a source system into a document, from a from a source system into another source system. And finally, manual verification of process. Going between systems making sure that the correct order of activity was followed. So with that, we'll talk a little bit about what Ketryx is and then we'll jump into a demonstration environment and go through a particular workflow of identifying a vulnerability and automatically updating all of the downstream documentation. So where Ketryx comes in is the ability to integrate into the set of tools that exist in your software development life cycle all the way from requirements management tools, ticketing and collaboration tools, source control systems, threat intelligence and vulnerability scanning, and then finally SBOM and vulnerability management tools. And what that allows us to do is centralize all of the aspects of the vulnerability and cyber risk management process, and importantly enforce a particular process throughout the tools that are used to manage the vulnerability and the associated risk. Ketryx builds Ketryx and Ketryx. So we, build our software like a class a medical device and produce a medical device like design history file. We're audited by UL each year and can provide certificates for one three four eight five, one four nine seven one, and six two three zero four. So all the claims that we make about the product today during the demonstration, has evidence that support those. So with that, we'll jump into a demonstration of Ketryx. And feel free to please put questions in the chat as we go along. I actually see two questions in here. The first is focused on Dependabot from GitHub. So that's a great a great point. I think there are lots of tools like Dependabot and some of the vulnerability remediation recommendations that come from tools like Snyk, which we did a webinar on, still add a lot of value. And you can still leverage those tools to accelerate the patch development and identification process. Ultimately, the documentation that you need to do still needs to flow through the cyber risk and vulnerability management process. And that's where the work with KepTrix will begin to be involved. So with that, we'll switch into the demonstration environment here and talk a little bit about Ketryx. So here we are in the Ketryx platform in an organization called Ketryx Demo Discovery three. We're looking at four different Ketryx projects. Each of these projects is connected to a corresponding set of systems and projects within those systems. So each Ketryx project here is connected to a Jira project as well as to a code repository where, a set of SBOM components are documented. We're working on two different products here. The first is this monolithic system, which we'll spend most of our time in. And then the second is another product called the irregular rhythm notification. This product is leveraging two subsystems. One is a hardware subsystem and the other is a software subsystem. This type of architecture is for those that have, more complex products in which you may want to release different subsystems independently. What this allows us to do is independently validate a software subsystem and reuse it among different products. Another ability that this particular feature gives you is in the case where you have a subsystem where a vulnerability that has been reported but needs to be mitigated by a different part of the system, we're we're able to share and reassign vulnerabilities from different parts of our architecture to be mitigated by different teams or different components within the overall system. That's a bit more of an advanced use case that our customers leverage Ketryx for, so we won't go into a ton of detail, but know that that's there. If we go into the monolithic system, and let's actually start at the end. We'll start with the resultant cyber risk assessment that we need to produce. So we'll go into the documents area, which is really where the story ends with respect to releasing a patch. And what we'll do is we'll regenerate our cyber risk management file. And what this is doing is it's going out to all of the various systems that we use to coordinate our vulnerability, and cyber risk management process and pulling the latest evidence that we have for this particular product. Now when we open up this cyber risk management file, what we'll see let's see here. What we'll see is this a pretty standard spreadsheet that many of you likely have and are currently documenting your cyber risk assessment in. We have an enumeration of the elements from our threat model, the assets from the threat model, design or system vulnerabilities that we have identified within our threat model, a threat assessment, and then that end to end security risk assessment. Here we can see all the way from the left side, excuse the scroll, a cyber risk flowing through elements of our threat model, impact description, and then complete descriptions of the evaluation of the secured the cyber risk from a pre implementation of security controls through a post implementation of security controls. But this particular document is automatically generated from the systems where we coordinate the work across. Final tab here is just showing our risk control traceability. From any risk control, a requirement specification, a test case that has been marked as controlling a security risk that's been documented in the system. Now what's challenging about building this document, if you're doing it manually today, is that the elements of this document come from many different systems. All the way from a cyber risk that we may document in our in our kind of application life cycle management tool or in Jira, all the way through to our threat model, which might come from a system like iris risk or from manual documents like a Lucid chart or a Miro board. And then finally, all of the security risk control design and implementation and verification that again lives in our source code repositories and our application lifecycle management tool. So with that, we'll go back into the platform and walk through the process of identifying a vulnerability and, producing a patch. And that will allow us then to automatically update our cyber risk assessment file that we had before. Now let me look at one question that just came up around what about different release versions for different GitHub repositories? And that's a great question. I will cover that in just a bit when we talk about the GitHub integration. But the answer is that you can connect multiple Caprix projects to the same repository or multiple repositories to the same Caprix project. And we have features to allow you to manage, multiple releases and multiple GitHub repositories. But that will be clear when we talk a little bit more about the GitHub, the GitHub integration. So we're on the all items screen for this product that we're developing, this insulin delivery system. And what we'll see here is a set of items. The first set of items we see are the dependencies. These are the SBOM components that Ketryx has detected within the connected GitHub repository. We see we see a set of vulnerabilities. These vulnerabilities are associated with dependencies that we have identified within the the code repository. And then if we filter this around, we'll see we have a set of defects that we're managing against this particular product anomalies, as well as some information about our threat model. We've documented a set of assets. And actually if we filter down here, we can look for the threats, threat surfaces, threat sources, and assets along with vulnerabilities that have been documented as a part of our threat model. And what this allows us to do is to do end to end documentation of our cybersecurity life cycle enabling the cyber risk and vulnerability risk management process. Now a better way to see all of this information is through a trace matrix because that helps us understand the relationship between our threat model, identified vulnerabilities, security risk controls and safety risks that may be introduced. And so that brings us to the traceability matrix within Ketryx. Now, there are many ways that you can configure the traceability matrix within Ketryx. This is the one that is often used to give you visibility into, more of a live understanding of your cyber risk assessment. So from the left, we can see design vulnerabilities that were identified through threat modeling, threats and assets that came out of that same threat modeling process, and then security risks and security risk controls that were identified. Finally, we have the control verifications and any related safety risks. So if we need to connect a security risk to a safety risk, this allows us to build that traceability and understand continuity with that. Now the question becomes, where do we start? So we start within the SBOM module and this is where we get a sense of what dependencies are on our product, what vulnerabilities have been reported against them, and how can we bring a vulnerability through full remediation. So going into the SBOM module, we'll see the list of dependencies that have been detected by Ketryx within the connected repository. We'll filter down and look just at the high and critical severity vulnerabilities. And in this case, let's look at the vulnerabilities that have been reported against rdiff web. Going into the dependency for rdiff web, we can see a set of metadata that it's been collected automatically for this dependency. We can see the relations from this dependency which has been automatically identified from the source code repository to places within the software architecture that this dependency is leveraged. So it looks like there's a monitoring and logging module as well as a database that leverages this dependency as well as potential risks that this dependency introduces which we'll see is related to a vulnerability that's been reported against RDFweb. Finally, on the right we see a complete history of changes that we've made to the metadata associated with this dependency. So that might be your level of support that you've documented for a dependency, the end of life date, any type of documentation that you need to do on this particular item can be configured and extended, outside of our kind of sensible out of the box defaults. Now going to the vulnerabilities tab for this dependency, we'll see a list of vulnerabilities that have been either reported to Ketryx via our API or that Ketryx itself has identified from common vulnerability databases like that of the GitHub security advisories. What we'll see if I, just minimize that history tab over there is we see a list of vulnerabilities that have been reported. And what I would like to do is open up this vulnerability called Improper Access Control vulnerability here. This is the one that we're going to remediate through the process. I can check this vulnerability and now go ahead and edit its vulnerability impact assessment. So in the case where a vulnerability doesn't need to connect into a risk in our risk register, if that's part of your process, we could do all of the necessary documentation directly on the vulnerability item in Ketryx. If you wanna connect each vulnerability to a risk in your risk register, we also support that workflow which is what we're looking at here. For this vulnerability, we can go through a rescoring of this vulnerability either through directly through the CVSS vector or by a more course level of selecting a particular severity level. We can assign a resolution either these default values or aligned with the response values from the VEX standard. And then we can connect this vulnerability to risks that we're managing across different systems. In this case, we have a risk item that's currently being documented in Ketryx and Jira. But this could be a risk that lives within Jama or Polarion or another system where you manage risk today. In addition, we can connect this vulnerability to mitigations as well as threats that have been documented in our threat model. So with that, let's actually go into this risk which has been created in order to do a risk assessment or a complete risk assessment on this vulnerability. So here I'll click improper access control in RF web and that will bring us to the risk that we've documented in Ketryx. You can see this risk item goes through a SW ninety six like approach to evaluating the cybersecurity risk and doing all the necessary documentation. And when we scroll down to the bottom, we'll see a very similar traceability widget which shows us all of the risk inputs that need to be considered for this particular risk analysis including the dependency of vulnerability, assets that have been documented in our threat model, as well as threats that have been documented in our threat model. Finally we see a defect that's been created. And this is how we get into the defect or kappa process in order to resolve this the risk that's been introduced by the vulnerability. Now before we go into this particular Jira ticket that documents the defect, I'll also highlight that downstream we can see a risk control measure that's documented in GitHub. So we have a piece of code which has to do with authentication for our device that we are tracing this risk to. And we'll get to that shortly. If I open up this defect, it will bring me into the system where we manage defects. So again, this could be Jira, this might be Azure DevOps. It depends where you manage your defect management process. Or in the case that you use a kappa to manage the resolution process, where you manage that kappa today. In the case of Jira, you'll see that we have a set of configured out of the box fields for managing defects or anomalies where we've documented this particular, this particular anomaly. We see an approvals widget that's been inserted. This allows us to configure a set of approvers that need to come into Jira or maybe they already spend most of their day in Jira and do a sign off. This could either be a click through approval or a part eleven compliant approval on the particular defect. Second, we also see this traceability widget which gives us that same view into what other items this defect is related to. Now the core idea here within Ketryx is to enable you or the majority of people within your organization to spend more time in common development tools like Jira, Azure DevOps, your preferred tools and less time going to a life cycle management system, I'll say even like Ketryx, unless you are doing a particular activity level item. For example, looking at the overall traceability of the system or generating a final evidence document. Our goal is to enable teams to spend more time in their preferred tools while automatically enforcing your quality management system in those tools and automatically collecting evidence of compliance to your security and I guess vulnerability and cyber risk management process. So with that, let's mark this defect as being resolved in the next patch version. So in this case, we'll say it's it's was actually resolved in one point one two. Now if we didn't mark it as obsolete in the next version, we'd have to provide a rationale for deferring resolution. Otherwise, Ketryx will prevent us from releasing the next version of the project, because the vulnerability, or I guess in this case, the defect isn't being removed from the product. And there isn't a rationale for why the defect isn't being removed from the product. So now that we're we're obsoleting it in this version, we can go through an approval process. When I move this ticket into a resolved state, this will send notifications to everyone that needs to approve this this defect to come into either Ketryx or into Jira to do the approval. In this case, I'm a super user, which means that, my approval will will account for for all of them. But you'll see that when I went ahead and approved it, it moved it into a closed state. Now with that, we'll go into this particular record, go back out, and look at the history of this particular item. And we'll see if we compare, from this closed state here back to the closed state, there are features within our history pane which will allow us to see differences between different items across their lifecycle. Okay. So let's go back out to the all items screen and now that we've closed out that defect, let's just look at all of the new changed and removed items in this particular version. So as we're moving towards the next release, one of the very powerful ways, in which a centralization of information across your IT systems enables you is understanding what is going into the patch version, Not only from what dependency might be changing and what vulnerabilities might be being addressed, but in addition, the changes to the particular software and the test cases that verify those changes. And so this leads me to speak a little bit about how we integrate directly into a tool like GitHub, GitLab or Bitbucket. What we find is that many times teams want to get their documentation closer to the source code. What this allows you to do is leverage, the Git version management, baselining, and keep documentation closer to the code. So two examples here. The first is with a software item specification. If I open up this item, it will bring me directly into where the software item is being documented above the description of the module that implements this specification. By annotating this particular method, we can not only include metadata like the title, a description, but we can also build traceability to other, things within the system such as parent specifications, requirements that this software specification might fulfill, and even dependencies that this item leverages. And this is the type of traceability that then gives us down the line a better understanding around what are the risk inputs into our vulnerability and cyber risk management process. The second way in which customers use our GitHub integration is by directly integrating test cases into the source code. So if we open up this test case item, we'll see that in addition to documenting part of our software design in the source code, we're also directly documenting test cases in the source code. So no need to copy an automated test description from your source code and paste it into a ticket in Jira or paste it into a document. All you do is tag the test within the source code, provide a level of traceability. So what does this particular test test within the system? And then Ketryx handles the rest of maintaining that traceability automatically and allowing you to go through an approval workflow in Ketryx. Once those test cases are executed in your build pipeline, Ketryx will connect collect those automated test results and then present them in a few different places within the platform. One is within the test module. So this is a full test management module allowing you to enforce a specific test plan, enforce that all of your security and cyber security and safety risk controls are tested before release. And the other, which is probably an easier place to see traceability, is this in the trace matrix itself. So we'll look at a slightly different view now that we're moving towards a particular release on the trace matrix. So we just updated that view to include defects and to show a more traditional design verification view from use cases through verification and validation. And what we see is a set of tests that have been collected from GitHub along with their automated test execution results. What this allows us to do is automate a substantial amount of our verification testing to allow us to patch faster and automatically generate our test plan and testing report. Now with that, we'll go back into the releases area and regenerate that cyber risk assessment file. In order to do that, we'll go into the patch release that we're working on one point one two, and we'll see a summary of all of the items that are going into this release. In this case, we're still missing approvals on nine of the items that might exist across different systems. We have one new item which is going to be that risk that were documented associated with the vulnerability, seven changed items which will include the changes to our test cases as well as our software item specification that controls this new risk, and one obsolete item which will be the defect that's obsolete in this version. Any of these are all clickable. So if I wanna see what were the changed items in this version, it'll immediately bring, bring you to the all items screen and show all of the changes that are occurring between the version. Finally, on the right, we see a release checklist. So this release checklist is configurable to your process. So you might have an additional step that you may wanna add that Ketryx will enforce before a release is allowed to occur. And then finally, we have a set of milestones. These milestones at the top allow us to enforce a phase gate or toll gate approach within our release process. In this case, we have milestones that are aligned with the cyber risk assessment process from vulnerability analysis through the cyber risk management review. And each of these milestones can be configured to require that a particular document is approved, a particular set of items across different systems have gone through an approval, and that particular a particular meeting has occurred and notes from that meeting have been uploaded. In addition, these milestones can be configured to align with the particular type of release that you're doing. So we can have different activity gates depending if you're doing a full release, a maintenance release, a patch release or a hotfix. So this gives us flexibility in enforcing that specific process that you need for the type of change that you're making to the software. Finally, when we go back into the documents area and prepare for our patch release, we can hit generate documents. Generating documents will go ahead and pull all of the latest information from all systems that Catcher is connected to to generate those final deliverables for evidence. And all we need to do in the case that we are asked questions during an audit around traceability from cyber risk through verification, through how we're documenting components of our SBOM and vulnerabilities that have been reported against it. We always have an up to date evidence document with the information from the systems in which our teams are working. So no longer do you have to race between systems to collect evidence to support that audit. We can just go ahead and download the necessary documents that we wanna review. For example, let's download the cyber risk management file, the SIP report, the vulnerability report, and maybe the risk management file. And now we can open these up, easily and review them with the team. So let's choose the risk management file, which will look familiar to everyone, the one that we looked at at the beginning of the webinar. We might pull down our cyber risk management file or sorry, our our risk management file, which includes all of our safety risk information. The safety risk information which could come from, Jira like we looked at or it could come from another system if you use Jama or Polarion for managing those risk items. So here we have our risk management file with all of the matrices that have been embedded automatically. Now with that, we'll go back to the slides here and and, stay around for any additional q and a. And then before we do that, I guess maybe David, did you wanna introduce the I guess I can introduce the next webinar, and then we will stick around for q and a for the last five minutes. Sure, Gabriel. I think, maybe, you know, if you wanna go to that next slide here. I I know some of this can feel abstract. Maybe this will prompt some questions, to the from the group here. One final resource we wanted to leave you with is is a real world success story. Nutrino is a company we've been working with for quite some time now. They came to us. They're an AI powered diabetes nutrition app that's actually owned by Medtronic. And they came to us with some of the same pain points that many of you sort of hinted at in in the initial poll that we had. Burdensome manual documentation and then having documentation that they could trust sort of in that audit environment to sort of prove, the evidence of compliance that they needed. They came to us, worked with us, were able to sort of use Ketryx to simplify their supply chain, had an intuitive integration with risk management as as Gabriel sort of demonstrated here, and then we're able to sort of manage that in an ongoing way and sustainable way with sort of automated vulnerability notification. Overall, we're able to reduce our SBOM documentation time by about ninety percent, and really sort of were able to sort of reap the benefits from that moving forward. And so I think, you know, sometimes, a lot of this can feel abstract when you're not in it. I think this is a really sort of great case study of of how folks have been able to sort of use Ketryx to achieve real world benefits for them. And just to close out here in our last few minutes, we're doing a our next webinar on April first. And here we'll be focused on Azure DevOps specifically. Today's demo was focused, more on on Jira as a ticketing system, and, we have support for Azure DevOps. Many teams out there that use Azure DevOps today that might be struggling with how to generate documentation that conforms to your organizational templates, how to build robust and comprehensive traceability reports out of ADO, and then finally, back to this enforcement piece, how do you ensure that processes that are executed in Azure DevOps are aligned with your quality management system? So looking forward to to this webinar. We'll we'll go into a bit more depth, holistically on the software development cycle focused on Azure DevOps. everybody. Well, we are right at the top of the hour. It's been our pleasure to sort of, speak to you today about webinar for, you know, building an audit ready secure SDLC. We hope you found this beneficial and helpful. We are available, for questions, through all the contact information that we provided at this point. We will be sending recording of this. Hope everybody has a great day, and thank you so much for your time.