WI-12 Managing Vulnerability Impact Assessments with Variants and Versions
Work Instruction for managing vulnerability impact assessments across versions.
1. Introduction
1.1. Purpose
This Work Instruction provides a guide on how to manage vulnerability impact assessments for different versions of your product using Ketryx's versioning and variant management capabilities.
1.2. Scope
This document covers the fundamental concepts and procedures for creating and managing variants of vulnerability impact assessments across multiple product versions.
1.3. Key Concepts
To effectively manage vulnerability impact assessments across versions, it is important to understand the following terms:
Version: Each version has a specific version number, which is extracted from the version name by default. Different versions might have the same effective version number, depending on your naming scheme and the configuration of Version number pattern.
Vulnerability Impact Assessment (VIA): A configuration item that documents the impact, severity, and mitigations for a vulnerability. In Ketryx, these are long-lived items.
Variant: When the impact of a vulnerability changes in a new version, you can create a new VIA as a variant of the original one. This allows you to have distinct assessments for the same vulnerability that are specific to each version.
Base Assessment: The original impact assessment from which a variant is created.
Effective Assessment: For any given version, only one impact assessment is considered effective. By default, Ketryx uses the most recently created assessment that is applicable to that version based on its Introduced in version and Obsolete in version fields. If an impact assessment has a variant, the variant will be considered the effective assessment.
1.4. Responsibilities
Product Security Team: Responsible for assessing vulnerabilities and creating or updating impact assessments for each product version.
R&D Lead / Engineering Lead: Responsible for ensuring that development teams are aware of the effective vulnerability impact assessments for the versions they are working on.
Team Members: Can create variants of impact assessments when working on new product versions.
2. Prerequisites
Before you can manage vulnerability impact assessments, you must have vulnerabilities in your project. Vulnerabilities are typically introduced by:
Connecting a source code repository from systems like GitHub, GitLab, or Bitbucket. For more details, see Source Code Integrations.
3. Procedure description
The following sections describe how to manage vulnerability impact assessments (VIAs) when a vulnerability affects multiple versions of a product.
3.1. Step 1: Create the initial version
To create an impact assessment for a version, the version must first exist in Ketryx. While versions can be synchronized from connected systems like Jira, you can also create them directly in Ketryx.
Navigate to the Releases page in your project.
Click the Create version button.
In the dialog that appears, enter a name for your new version (e.g., 1.0.0).
Click Create.
The new version will now appear on the Releases page and can be selected throughout Ketryx.
3.2. Step 2: Create the first impact assessment
When a vulnerability is identified, you create an initial impact assessment.
Navigate to the SBOM > Vulnerabilities page in your project.
Select the vulnerability you want to assess.
Click the Create impact assessment button.
Fill in the details for the assessment, such as severity, resolution, and rationale.
In the Introduced in version field, select the version where this assessment first becomes effective (e.g., 1.0.0).
Leave the Obsolete in version field empty. This ensures the assessment remains effective for all subsequent versions until a new variant is created.
Save the assessment.
This first assessment now applies to version 1.0.0 and all future versions.
3.3. Step 3: Create a new version from an existing one
Before you create a variant for a new version, the version itself must exist in Ketryx.
Navigate to the Releases page.
From an existing version (e.g., 1.0.0), click the Create new version from baseline button.
A dialog appears where you can configure the new version.
Enter a name for the new version. It is strongly recommended to use a unique and higher version number (e.g., 1.0.1 or 2.0.0). If you use the same version number as an existing, unreleased version, Ketryx treats them as equivalent, which can lead to unexpected behavior with variants.
Select the Lock records from this version checkbox. This is important for stability. It ensures your new version starts with all items in the exact state they were in version 1.0.0, and later changes to version 1.0.0 will not affect your new version.
Click Create new version.
The new version is now created and inherits the items from the version it was created from.
Important: While locking records provides a stable base, a variant item will always take precedence. If you create a variant of a locked item, the variant will be the effective item in the new version, not the locked base item.
3.4. Step 4: Create a variant for a new version
Suppose you are working on version 2.0.0, and the impact of the same vulnerability is different. You now need a new assessment. Instead of starting from scratch, you can create a variant of the existing assessment.
From the Vulnerabilities page, select version 2.0.0 from the version picker.
Select the same vulnerability. You will see the existing assessment from version 1.0.0 is currently effective.
You will be presented with an option to Create variant for the existing impact assessment.
Clicking this will open a new assessment form, pre-populated with the information from the original assessment.
The Introduced in version field will be automatically set to 2.0.0.
Update the fields to reflect the new assessment for version 2.0.0.
Save the new assessment.
You have now created a new variant of the impact assessment.
3.5. Step 5: View and understand effective assessments
Ketryx makes it easy to see which assessment is effective for each version, and to compare assessments.
Navigate to the SBOM > Vulnerabilities page.
Use the version picker above the table to switch between versions. The table updates to show the effective impact assessment for each vulnerability in the selected version.
Click the expand icon on the right of a vulnerability's row to expand its detail panel.
The panel shows the details of the effective assessment for the version you selected.
In the impact assessment dropdown menu, you can see a list of all impact assessments for this vulnerability (both base and variants). Select any assessment to view its details. This selection does not change the version shown on the main page, but allows you to easily compare information between variants and their base assessment and how they change over time.
To view the history of a specific impact assessment configuration item, click the Record details link in the detail panel. This will take you to the records details page where you can see the complete history of records for that assessment.
4. Advanced scenarios
4.1. Making an assessment obsolete
If you want an impact assessment to stop being effective after a certain version, you can edit it and set the Obsolete in version field.
For example, if you set the Obsolete in version of the assessment for 1.0.0 to 2.0.0, it will no longer apply to 2.0.0 or any later versions. If no other assessment is created for 2.0.0, the vulnerability will have no effective assessment in that version.
4.2. Re-using assessments across versions
If an impact assessment is created for version 1.0.0 with an empty Obsolete in version field, it will automatically be the effective assessment for versions 1.1.0, 2.0.0, and so on, as long as no new variant is created for those versions. This allows you to reuse an assessment without creating unnecessary variants.
Last updated
Was this helpful?