Welcome to the documentation of Ketryx Platform, a system to build validated software, supporting FDA software compliance and compliance with standards like: ISO 13485, IEC 62304, and ISO 14971.

This documentation is structured as follows:

• Manuals provide a high-level description of different areas of Ketryx Platform.

• Work Instructions provide detailed, step-by-step guidance for how to perform certain tasks in Ketryx Platform.

• Integrations provide instructions for how to set up and work with connections to various other systems.

• Reference provides in-depth technical information.

• API documents how to access Ketryx Platform programmatically, for integration with other tools and systems.

1. Introduction

Threat modeling is a structured approach to identifying and addressing potential threats to a system. This manual provides guidance on how to document your threat model using Ketryx with custom item types.

1.1. Purpose

The purpose of this manual is to instruct users on how to use Ketryx for documenting threat models, focusing on the STRIDE methodology.

1.2. Scope

This manual describes how to use Ketryx to document threat models in a system. It is intended for users who are responsible for identifying and mitigating threats to a system.

1.3. Regulatory Context

• AAMI TIR57: 2016/(R)2019: Principles for medical device security – Risk management

2. Terms and definitions

3. Project setup

To use threat modeling, you need to have a project set up in Ketryx Software Supply Chain Management. If you don't have a project set up, follow the instructions in MAN-03, section 3.

Additionally, you need to have the following item types set up in your Jira project and map them to the custom item types in Ketryx: Threat, Asset, Threat Source, Threat Surface, and Trust Boundary.

Once you have a project set up, you can start using threat modeling. The following sections describe how to set up the custom item types and map them to the Jira item types.

3.1. Advanced configuration

First, you need to activate the threat modeling feature in Ketryx and configure it to map the custom item types to the ones created in Jira. This can be done using the Advanced Settings called Custom item types, Item fields and Issue mapping.

To activate the threat modeling feature, go the Advanced Settings in your project or organization, and enable the Enable threat modeling setting.

Then, copy the configuration below and paste it into the corresponding fields in the advanced settings:

{
  "Asset": {
    "addedFields": ["exposedByThreatSurface", "impactedThreats", "risks"]
  },
  "Threat": {
    "addedFields": ["risks"]
  },
  "Threat Source": {
    "addedFields": ["initiatedThreats"]
  },
  "Threat Surface": {
    "addedFields": ["containedInTrustBoundary", "exploitedByThreats"]
  }
}

[
  {
    "name": "Threat",
    "lifecycle": "LONG_LIVED",
    "shortName": "THR"
  },
  {
    "name": "Threat Surface",
    "lifecycle": "LONG_LIVED",
    "shortName": "THRSURF"
  },
  {
    "name": "Threat Source",
    "lifecycle": "LONG_LIVED",
    "shortName": "THRSRC"
  },
  {
    "name": "Asset",
    "lifecycle": "LONG_LIVED",
    "shortName": "ASSET"
  },
  {
    "name": "Trust Boundary",
    "lifecycle": "LONG_LIVED",
    "shortName": "TB"
  }
]

[
  {
    "itemType": "CUSTOM",
    "issueType": "Asset",
    "itemTypeName": "Asset"
  },
  {
    "itemType": "CUSTOM",
    "issueType": "Threat",
    "itemTypeName": "Threat"
  },
  {
    "itemType": "CUSTOM",
    "issueType": "Threat Source",
    "itemTypeName": "Threat Source"
  },
  {
    "itemType": "CUSTOM",
    "issueType": "Threat Surface",
    "itemTypeName": "Threat Surface"
  },
  {
    "itemType": "CUSTOM",
    "issueType": "Trust Boundary",
    "itemTypeName": "Trust Boundary"
  }
]

3.2. Custom item types for threat modeling

The custom item types used for threat modeling are as follows:

• Asset: Represents an asset in the system.

• Threat: Represents a threat to the system.

• Threat Source: Represents a source of a threat.

• Threat Surface: Represents a part of the system that is vulnerable to a threat.

• Trust Boundary: Represents a boundary that separates the system from external entities.

When configuring the custom item types in Jira by following the Jira configuration guide, make sure to add the following fields (and any other you might require) when configuring the Screens:

For all item types, to make them so-called long-lived items, add the following fields:

• Introduced in version: The first version this item is effective in. If empty, the item is considered effective from the start of the project.

• Obsolete in version: The version in which the item is no longer relevant. If empty, the item is considered effective in all versions starting with its introducing version.

For the Asset item type, add the following fields:

• Introduced risks: The risks introduced by the asset.

• Impacted threats: The threats impacted by the asset.

• Exposed by threat surface: The threat surfaces that expose the asset.

For the Threat item type, add the following fields:

• Introduced risks: The risks introduced by the threat.

For the Threat Source item type, add the following fields:

• Initiated threats: The threats initiated by the source.

For the Threat Surface item type, add the following fields:

• Contained in trust boundary: The trust boundary that contains the threat surface.

3.3. Approval rules

By default, custom item types come with no approval rules configured. To do this go to Settings > Approval rules in the project you are setting up and add the necessary rules for the item types you have created.

4. Item types and relationships

The image below provides a visual representation of the relationships between key elements in the threat modeling process. It starts with vulnerabilities, which are weaknesses or flaws that can originate from components listed in the Software Bill of Materials (SBOM). These vulnerabilities are a starting point for potential security threats. For more information, please see the vulnerability management manual.

Once a vulnerability is identified in an SBOM component, it can be exploited by a threat. A threat represents a potential danger that can take advantage of a vulnerability to cause harm. This threat can then impact the software, specifically targeting the threat surface, which is the area or aspect of the system where vulnerabilities can be exploited. For more information about the SBOM module, please see MAN-03 Supply Chain Management: Software Dependencies.

The threat surface directly exposes assets—resources or valuable elements within the system that could be compromised. When a threat successfully exploits a vulnerability through the threat surface, it introduces a safety or cybersecurity risk. This risk represents the potential negative impact on the asset due to the exploited vulnerability. For more information on how to perform risk assessment for both safety and cybersecurity risks, please see MAN-08 Risk Management.

To manage and mitigate these risks, risk controls, or mitigations, are implemented. Risk controls are measures or safeguards put in place to reduce the likelihood or impact of the risk. Finally, these risk controls need to be validated to ensure their effectiveness, which is done through testing. Testing verifies that the implemented risk controls work as intended, thereby securing the assets from potential threats. For more information about test management, please see MAN-06 Test Management.

Not depicted in the diagram are the trust boundary and the threat source, two key concepts in threat modeling. The threat source refers to the origin of potential threats, such as external attackers, malware, or even internal actors that could exploit vulnerabilities in your system. While the diagram doesn't explicitly show the threat source, it is conceptually positioned outside or adjacent to the Threat element, indicating where these threats originate and how they begin to interact with your system.

The trust boundary is the line that separates different areas of trust within your system. It delineates the point where data or control passes from one trust level to another—typically from a more trusted to a less trusted zone or vice versa. In the context of the diagram, the trust boundary would be situated around the Threat Surface. This is because the threat surface represents the areas of the system that are exposed to interactions from outside the trusted boundary, where threats can exploit vulnerabilities.

The trust boundary is crucial because it defines where the system's security controls shift or where different security assumptions apply. External threats, crossing this boundary at the threat surface, pose a risk to the assets inside the system, and this is where the vulnerabilities are most likely to be exploited. Understanding the placement of the trust boundary helps in identifying the specific points where additional security measures may be needed to protect against threats originating from less trusted sources.

Within Ketryx, vulnerabilities can be linked to threats. In Jira, all the other item types can be linked to each other.

1. Introduction

1.1. Purpose

The purpose of this manual is to define the activities that will be performed as part of the release of a product (the Product) managed with Ketryx Lifecycle Management.

1.2. Scope

This document defines tasks, activities, procedures, resources, responsibilities, and deliverables related to software releases of the Product.

1.3. Field of application

This plan was developed to support the creation, release, and maintenance of the Product.

1.4. Compliance

This plan was developed in compliance with ISO 13485, IEC 62304, ISO 14971, and 21 CFR Part 820.

1.5. Tools

Tools used to develop and release a product with Ketryx Lifecycle Management are provided in MAN-01 Ketryx Lifecycle Management.

2. Terms and definitions

For the purposes of this document, the terms and definitions given in U.S. QSR (CFR 21 Part 820), ISO 13485, and IEC 62304:2006-AMD1 apply. Where contradictory, IEC 62304 and ISO 13485 prevail.

3. Process activities

To release a new version of the Product to the production environment, the following activities are performed.

3.1. Activity 1: Design controls

All design controls relevant to the version to be released are put in a controlled state (i.e., verified and fully approved by their respective approval steps, as per the Work Instructions WI-01 Requirement, WI-02 Software Item Spec, WI-04 Test Case).

3.2. Activity 2: Risk (control) management

Given a set of risks in your project, verify that all the risks for the relevant version are acceptable and in a controlled state. If not acceptable, verify that a benefit-risk analysis has been set.

If risk controls exist, ensure that all of its controls are in a positive state, including the presence of a Test Case with a passing Test Execution.

3.3. Activity 3: Test Plan

A specific Test Plan for the version is defined and approved by the relevant approval steps. Only the default Test Plan of executing all Test Cases does not need explicit approval.

See also MAN-06 Test Management.

3.4. Activity 4: Deploying a Release Candidate

A Release Candidate (RC) is deployed to the testing environment. This is done by an R&D Lead.

The build artifacts for each Release Candidate are uploaded to the Ketryx EDMS by an R&D Lead.

3.5. Activity 5: Start of Verification and Validation (V&V)

Once a final Release Candidate is deployed, formal Verification & Validation (V&V) is started.

3.6. Activity 6: Executing tests

Test Executions for all Test Cases contained in the Test Plan are created and executed as per the Work Instruction WI-05 Test Execution.

3.7. Activity 7: Anomalies

Anomalies found during V&V are reported as per Work Instruction WI-06 Anomaly.

Non-critical Anomalies can be deferred by setting a Rationale for deferring resolution. Such deferrals and their rationale are approved collectively by the relevant approval steps of the Unresolved anomalies release document (see Activity 10 Release approval).

If critical Anomalies are found, they are fixed by code or configuration changes, resulting in a new Release Candidate. Quality Managers decide which tests need to be re-executed due to such changes. Activities 1 through 5 in this manual are re-executed as necessary.

3.8. Activity 8: Verifying traceability

The traceability of all requirements and specs to respective (passing or excluded) tests according to the test plan is verified by Quality Managers using the Traceability view for the version to be released.

Based on the configured traceability mode, the traceability matrix will enforce relevant item relations to exist (e.g. Requirement requires at least one specification, requires at least one Validation test case) and makes sure that all verification and validation tests are conducted according to the given version's test plan.

More details on how to use the Traceability page can be found in MAN-07 Traceability.

3.9. Activity 9: Generating and approving release documents

Release documents are generated for the version to be released and approved by the relevant approval groups. This includes the following deliverables:

• Authority matrix

• Change request verification report

• Change management file

• Cloud configuration report

• Code review report

• Cyber risk management file

• Problem report (Default)

• Release notes (Default)

• Risk management file (Default)

• Risk control matrix

• Risk matrix

• System architecture chart (Default)

• System requirements specification (Default)

• System design specification (Default)

• System design structure matrix

• SBoM – SOUP – software configuration report (Default)

• Training status report (Default)

• Test plan (Default)

• Testing report (Default)

• Traceability matrix (Default)

• Unresolved anomalies

Only the documents listed with the keyword default will show up in a new project. The list of release documents can be modified in a project in the Advanced settings page with the Omitted documents field under Document configuration.

If any release documents need customizations, they are downloaded, edited, and uploaded to the Ketryx EDMS.

3.10. Activity 10: Release approval

Once all design controls, dependencies, test executions, test plan, traceability matrix, release documents and optionally milestones are in a controlled state and fully approved by the relevant approval steps, the version is finally approved for release.

There shall be a release meeting with the relevant stakeholders to sign off on the release and the specific release plan for the released version and its production push.

3.11. Activity 11: Production push

The version approved for release is pushed to the production environment by an R&D Lead.

Quality Managers and Quality Control verify a successful deployment with certain tests on the production environment.

In case of an unsuccessful deployment, the deployment shall be reverted.

3.12. Activity 12: Post-marked vulnerability surveillance

As a project evolves over time, multiple iterations of the product are often released and in use in parallel. It is essential to stay informed about any vulnerabilities that could impact the released versions of your product. To receive vulnerability notifications for the dependencies in a release, mark the monitoring option as active on the corresponding settings page, as described in Monitoring.

1. Introduction

Vulnerability management is the process of identifying, evaluating, treating, and reporting on security vulnerabilities in systems and the software that runs on them. The process is a continuous cycle of discovery, prioritization, and remediation. Vulnerability management is integral to computer security and network security.

When developing medical devices following IEC 62304, vulnerability management becomes even more crucial. Medical devices often rely on Software of Unknown Provenance (SOUP) and Off-the-shelf (OTS) software components and dependencies, making them vulnerable to security risks. Proper vulnerability management ensures that potential vulnerabilities are identified and addressed, reducing the risk of security breaches and ensuring the safety and effectiveness of the medical devices.

Ketryx Software Supply Chain Management offers a vulnerability management module designed to assist users in monitoring vulnerabilities within their software supply chain. This module presents a centralized view of all vulnerabilities in the software supply chain, aiding users in prioritizing and remedying them.

1.1. Purpose

The purpose of this document instruct users on how to use the Vulnerability management module in Ketryx Software Supply Chain Management to manage vulnerabilities in the software supply chain.

1.2. Scope

This document describes the features and functionality of the Vulnerability management module in Ketryx Software Supply Chain Management.

2. Terms and definitions

The definitions of this document conform to the ones of ISO/IEC 27001, ANSI/AAMI SW96:2023, and AAMI TIR57:2016/(R)2019.

3. Project setup

To use the Vulnerability management module, you need to have a project set up in Ketryx Software Supply Chain Management. If you don't have a project set up, follow the instructions in MAN-03, section 3.

Once you have a project set up, you can start using the Vulnerability management module. The module is available in the SBOM > Vulnerabilities section of the project.

4. Manage vulnerabilities

The Manage vulnerabilities (available in the SBOM > Vulnerabilities section of the project) screen displays a list of all identified vulnerabilities in the software supply chain of the project. It is also possible to create, edit, and manage vulnerability impact assessments on this screen, as well as to create, edit, and manage manual vulnerabilities.

If the project contains transitive dependencies, the vulnerabilities of the transitive dependencies are also displayed. The vulnerabilities of the transitive dependencies can be expanded to view more information. For transitive dependency support, please refer to MAN-03, section 12, as well as the manual on Working with SPDX or Working with CycloneDX.

The vulnerabilities list displays the following information for each identified vulnerability:

1. Title: The title of the vulnerability. Below the title, the vulnerable SOUP or OTS component is displayed. Clicking on the SOUP/OTS component will take you to the detail screen, where you can view more information about the component.

2. Reported on: The date the vulnerability was reported.

3. Severity: The severity of the vulnerability and its score.

4. Risks: The number of risks associated with the vulnerability, if any.

5. Mitigations: The number of mitigations associated with the vulnerability, if any.

6. Resolution: The resolution status of the vulnerability impact assessment.

7. Status: The status of the vulnerability.

8. Expand: Clicking on the expand icon will display more information about the vulnerability, such as the description, the affected version, etc. and if available, the vulnerability impact assessment.

5. Manual vulnerabilities

For many ecosystems, Ketryx can automatically detect vulnerabilities by leveraging the GHSA (GitHub Security Advisory). However, for the product itself or certain OTS (Off-The-Shelf) software, Ketryx allows users to create and manage their own vulnerabilities.

5.1. Creating a manual vulnerability

To create a manual vulnerability, click on the Add vulnerability button on the manage vulnerabilities screen above the table.

Clicking on the Add vulnerability button opens the manual vulnerability dialog.

Manual vulnerabilities can be created by populating the vulnerability details and then clicking the Add vulnerability button. The following fields are available:

• Title

• Introduced in Version

• Obsolete in Version

• Description

• CVE ID

• External URL

• Reported On

• Severity (Severity level and/or Severity CVSS Vector string)

• Additional fields for assessing the vulnerability impact (see section 6)

5.1.1. Manual vulnerability severity

Manual vulnerability severity is set by a severity level dropdown with an option to assess severity using a CVSS vector string. Currently, CVSS vectors of version 3.0, 3.1, and 4.0 are supported.

5.2. Editing a manual vulnerability

To edit a manual vulnerability, select a vulnerability from the Vulnerabilities list and click on the Edit vulnerability impact assessment button.

This will open the Edit item page where you can edit the manual vulnerability fields alongside its impact assessment. Clicking the Save changes button saves the new version.

6. Vulnerability impact assessment

The Vulnerability impact assessment is a detailed analysis of the impact of a vulnerability on the product. It includes information about the affected components, the potential risks, and the mitigations that can be taken to reduce the impact of the vulnerability.

It is available for each identified vulnerability (including manual vulnerabilities). To view the Vulnerability impact assessment, click on the expand icon in the Vulnerabilities list.

6.1. Creating a vulnerability impact assessment

To create a vulnerability impact assessment, select one or more vulnerabilities from the Vulnerabilities list and click on the Create impact assessment button. This will open a dialog where you can fill in the details of the impact assessment.

In the dialog, details of the impact assessment, such as rationales, justifications, potential risks, and mitigations that can be taken to reduce the impact of the vulnerability, can be filled in. By default, the following fields are available:

1. Severity: This section can be used to modify the severity of the selected vulnerabilities.

   1. CVSS vectors of version 3.0, 3.1, and 4.0 are supported.

   2. During impact assessment creation, leaving the severity field empty will keep the severity of the vulnerability unchanged.

   3. When creating an impact assessment for multiple vulnerabilities in batch, the modifying severity will be applied to all selected vulnerabilities.

2. Resolution: The resolution status of the vulnerability impact assessment. This field serves to quickly identify the status of the impact assessment, e.g. if a vulnerability is not relevant or exploitable.

3. Justification for resolution: A justification for the resolution status.

4. Introduced risks: A list of risks connected to the vulnerability. New risks can be added by using the Risk management module, see MAN-08 Risk Management.

5. Rationale for connecting risks: A rationale for connecting the risks.

6. Mitigations: A list of mitigations connected to the vulnerability. By default, any item type but the Risk item type are available. The available item types can be changed in the advanced project settings.

7. Rationale for connecting mitigations: A rationale for connecting the mitigations.

6.2. Editing a vulnerability impact assessment

To edit a vulnerability impact assessment, select a vulnerability with an existing assessment in the Vulnerabilities list. Then, click on the Edit vulnerability impact assessment button. This will open the Edit item page where you can edit the details of the impact assessment.

7. Download the vulnerability report

The Vulnerability Report can either be generated and downloaded as a release document (as described in MAN-02 Software Release Process, Section 3.9), or generated on demand for a selected version on the page SBOM > Vulnerabilities. The document will be generated an Excel file and will contain the following data:

1. Title: The title of the vulnerability.

2. Severity: The severity of the vulnerability.

3. Score: The score of the vulnerability.

4. Ecosystem: The ecosystem of the vulnerability.

5. Dependency: The dependency which is affected by the vulnerability.

6. Affected versions: The affected versions of the dependency.

7. Used dependency versions: The versions of the dependency used in the project.

8. Introduced in version (applicable only for manual vulnerabilities, empty otherwise): The first version of the product this vulnerability is effective in. If empty, the vulnerability is considered effective from the initial version of the product.

9. Obsolete in version (applicable only for manual vulnerabilities, empty otherwise): The version of the product the vulnerability is becoming obsolete in, i.e., the first version for which this vulnerability is not effective anymore.

10. Reported on: The date the vulnerability was reported.

11. CVE ID: The Common Vulnerabilities and Exposures (CVE) ID of the vulnerability.

12. Description: The description of the vulnerability.

13. URLs: The URLs related to the vulnerability.

14. Status: The status of the vulnerability.

15. Connected risks: URLs to the connected risks.

16. Connected mitigations: URLs to the connected mitigations.

17. Resolution: The resolution status of the vulnerability impact assessment.

18. Justification for resolution: A justification for the resolution status.

19. Rationale for connecting risks: A rationale for connecting the risks.

20. Rationale for connecting mitigations: A rationale for connecting the mitigations.

8. Vulnerability management of an individual SOUP/OTS component/dependency

To manage the vulnerabilities of an individual SOUP/OTS component/dependency, navigate to the SBOM page of the project and click the dependency you want to manage. On its details page, click on the Vulnerabilities tab. There, the same functionality as on the Vulnerabilities page is available, but only for the selected dependency, listing only the vulnerabilities of the selected dependency.

Similarly, on the page SBOM > Vulnerabilities, the dependency details page can be reached by clicking on the dependency name below the vulnerability title in the Vulnerabilities list.

9. Vulnerability notifications

New vulnerabilities are discovered daily. To keep you informed about the latest vulnerabilities in your project, Ketryx sends daily and weekly vulnerability notifications via email. Daily notifications include vulnerabilities of critical severity, while weekly notifications cover all new vulnerabilities regardless of the severity level. You will receive notifications for all dependencies in your current version and all active releases (as described in Monitoring). Notifications are sent to all users configured in the approval rules for dependencies, according to MAN-11 Approval Rules.

Ketryx updates its vulnerability database periodically and scans all your dependencies for known vulnerabilities. This includes dependencies reported via dependency manifest files, as well as CycloneDX or SPDX files using the Builds API.

1. Introduction

This manual assumes you have access to Ketryx Software Supply Chain Configuration Management, and have created an Organization with Members and Groups.

1.1. Purpose

The purpose of this manual is to instruct users on how to use Ketryx Software Supply Chain Configuration Management to manage software dependencies.

1.2. Scope

This manual describes how to use Ketryx Software Supply Chain Configuration Management to manage software dependencies including open-source software, and other Software of Unknown Provenance (SOUP).

2. Terms and definitions

The definitions of this document conform to the ones of ISO/IEC 62304.

3. Project setup

3. 1. Optionally, the user can specify the main branch or tag to analyze. Otherwise, the default HEAD branch (usually called main or master) will be used.

   2. In addition, the user can specify a release ref pattern, informing how a branch or tag corresponding to each project version is determined. By default, this will be set to refs/tags/v#. The placeholder # is replaced by (a part of) the version number of a given version until a match is found; e.g., for a version with the full name App v1.0 (which implies a version number 1.0.0), the tag names v1.0.0, v1.0, v1 would be searched; if the tag v1.0.0 does not exist but v1.0 exists, that tag v1.0 would be associated with the version.

   3. Ketryx will scan the repository for:

      • All files named requirements.txt in the server/ directory and all its subdirectories

      • All supported dependency manifest files (including locked dependency manifest files) in the wwwroot/ directory and all its subdirectories

      • Omit all files in the tests/ directory and all its subdirectories

4. The dependency screen

The dependency Name column is derived from the dependency files. Note that Java dependencies are specified in the format organizationId:artifactId.

The Used version(s) column is derived from the dependency files. When no locked version can be detected, the used version(s) will show a declared version only.

The Status column shows the current acceptance status of each dependency. Besides the empty state which indicates that a dependency has not yet been worked on, there are six states a dependency can be in. Namely:

• Draft ✔ means that changes have been made to this dependency and once fully approved and moved into a controlled state, it would result in this dependency being accepted, indicated by the checkmark icon on the right.

• Draft 𝗫 means that changes have been made to this dependency and once fully approved and moved into a controlled state, it would result in this dependency being rejected, indicated by the X icon on the right.

• Accepted ✔ means that a dependency has been fully approved and moved into a controlled state and its usage being accepted.

• Rejected 𝗫 means that a dependency has been fully approved and moved into a controlled state and its usage being rejected.

• Changed ✔ means that a dependency has been edited after being in a controlled state and the changes would result in this dependency being accepted, indicated by the checkmark icon on the right.

• Changed 𝗫 means that a dependency has been edited after being in a controlled state and the changes would result in this dependency being rejected, indicated by the X icon on the right.

Hovering over the status will show information about which groups have already approved a dependency:

5. Approval flow

Ketryx Platform allows users to mark individual direct dependencies as “approved”, enforcing user-specified approval steps and enabling security and usage metadata to be customized for each dependency.

To approve a dependency, the user must first set up approval steps, as detailed in the Ketryx Installation Guide.

5.1. Batch approval

6. Manual dependencies

6.1. Creation

This will open a new page where at least a name for the manual dependency has to be declared. All other inputs are optional.

By default, all versions of the dependency will be set as accepted since there is no source of truth to match against in this case. Custom versions can still be declared to indicate that a certain version of a dependency is accepted or rejected.