Skip to content

Rework VulnerabilityResolutionReason for CRA / DORA requirements #10886

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from
Draft

Rework VulnerabilityResolutionReason for CRA / DORA requirements #10886

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
72fa5db
feat(model): Add `FIXED_VULNERABILITY` as a resolution reason
sschuberth Sep 23, 2025
c5bea43
feat(model): Add `RISK_ACCEPTED_VULNERABILITY` as a resolution reason
sschuberth Sep 23, 2025
f9f9338
chore(model): Deprecate `INEFFECTIVE_VULNERABILITY`
sschuberth Sep 23, 2025
59bc685
chore(model): Deprecated `INVALID_MATCH_VULNERABILITY`
sschuberth Sep 23, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 23 additions & 0 deletions model/src/main/kotlin/config/VulnerabilityResolutionReason.kt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -31,16 +31,28 @@
*/
CANT_FIX_VULNERABILITY,

/**
* The finding is not actionable because it is an error, out of scope, or intended behavior.
*/
FALSE_POSITIVE_VULNERABILITY,

Check warning on line 37 in model/src/main/kotlin/config/VulnerabilityResolutionReason.kt

View workflow job for this annotation

GitHub Actions / qodana-scan

Unused symbol 

Class "FALSE_POSITIVE_VULNERABILITY" is never used

/**
* The required fix (e.g. patch, update) has been successfully applied and verified, eliminating the vulnerability.
*/
FIXED_VULNERABILITY,

Check warning on line 42 in model/src/main/kotlin/config/VulnerabilityResolutionReason.kt

View workflow job for this annotation

GitHub Actions / qodana-scan

Unused symbol 

Class "FIXED_VULNERABILITY" is never used
Copy link
Member

@fviernau fviernau Sep 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The semantics described in the commit message IIUC differs from the one in the KDoc.
I believe KDOC should be aligned.

Copy link
Member Author

@sschuberth sschuberth Sep 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please explain where you feel is a mismatch, because I don't see any after re-reading.

For using this enum value the question boils down to "How can a vulnerability actually be fixed if it is reported by an advisor for that package?". And one of the answers is the example mentioned in the commit message: As vulnerabilities are looked up by package coordinates / purls, not by package content, the advisor cannot know anything about patches being applied while keeping coordinates the same.

Copy link
Member

@fviernau fviernau Sep 24, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Basically, the advisor reported a false positive, because the identifier of the package is ambiguous. So, could we instead use the one currently named "false positive" ? Also, invalid match seems to fit.

Please explain where you feel is a mismatch

I found it deviates, because the KDoc does not speak about any package context.
For the use case where one has a third party depenceny with a vulnerability included in a product, I guess there is also the possibility that the "FIX" goes into product code, e.g. ensuring that the vulnerable code path is not used.

Looking at all values existing in this enum right now, it seems there is more overlap inbetween several values. I wonder if the enum elements could be cleaned up a bit, such as merging WORKAROUND_FOR_VULNERABILITY, MITIGATED_VULNERABILIY, INEFFECTIVE_VULNERABILITY, NOT_EXPLOITABLE_VULNERABILITY into just NOT_EXPLOITABLE_VULNERABILITY.
What do you think?


/**
* The code in which the vulnerability was found is neither invoked in the project's code nor indirectly
* via another open source component.
*/
@Deprecated("Use NOT_EXPLOITABLE_VULNERABILITY instead", replaceWith = ReplaceWith("NOT_EXPLOITABLE_VULNERABILITY"))
Copy link
Member

@fviernau fviernau Sep 24, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at 1, I propose to name it NOT_AFFECTED*.

Copy link
Member Author

@sschuberth sschuberth Sep 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@willebra please comment.

Copy link

@willebra willebra Sep 24, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the VEX status document describes primarily vulnerability handling statuses (AFFECTED, UNDER INVESTIGATION), but then has a bit of reasons for why to resolve these (FIXED, NOT AFFECTED). I believe the rationale in VulnerabilityResolutionReason in ORT is about providing a justification for why a vulnerability was resolved. It should not be mixed with handling status. As it provides justifications, and those are valuable parts in proving proper handling of vulnerabilities, this should be more detailed than just on the level of "Fixed" and "Not affected".

As to the NOT_EXPLOITABLE_VULNERABILITY is directly following from EU regulations, where the obligation to address vulnerabilities is tied to the vulnerability being exploitable. Therefore a resolution reason "not_exploitable" clearly ties the decision to these requirements, making it easy for the users to understand what it means, and align in their internal policies with that - since the same docs need to be also aligned with regulations. The EU regulations have not invented this concept, so it is also being used in U.S. CISA's Known Exploited Vulnerabilities and in the Exploit Prediction Scoring System (EPSS). The VEX status document clearly also revolves around the concept of exploitability, so this term is not foreign there either. Possibly NOT_EXPLOITABLE is equal with NOT AFFECTED, but I haven't investigated the VEX status document in detail.

Copy link
Member

@tsteenbe tsteenbe Sep 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fviernau @willebra My first thoughts we similar to Frank to align VulnerabilityResolutionReason closes to VEX enums but as you correctly pointed out VEX is status and our resolution is about the why a vulnerability finding was resolved. This use case is what is vulnerability-analysis's justification in CycloneDX.

Question is do we align with what CycloneDX or CSAF have or do we go our own way? My thinking was that vulnerability resolutions need to be translatable to SBOM so one can in a machine readable standard inform customers why a vulnerability finding / CVE is not applicable. Would like to see a mapping from ORT to CycloneDX/CSAF vulnerability impact justifications.

Copy link

@willebra willebra Sep 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This use case is what is vulnerability-analysis's justification in CycloneDX.

These justifications seem to be for triage-results? I.e. not the final result how the issue was fixed, but the potential result of a triage? All of these seem detailed justifications that fall under NOT_EXPLOITABLE_VULNERABILITY. Logically, these should be exit points from the vulnerability management process, and if none can apply, then actual fixing/remediating should occur? What is missing here are the different flavous of "this should be fixed" or "this was fixed", but that is understandable, it these are just exit-points.

This is why we would need end results when fixing/remediating was necessary: FIXED_VULNERABILITY WORKAROUND_FOR_VULNERABILITY, MITIGATED_VULNERABILITY. (In VulnerabilityResolutionReason we don't follow the statuses, just the end-results, so therefore the "this should be fixed" does not belong here.)

(By the way, the more CRA/ISO27001/WG9 way to say fixed, would be REMEDIATED_VULNERABILITY instead of FIXED_VULNERABILITY.)

I'm following/participating in the work of CEN/CENELEC in JT13, WG9, which is creating the standard for vulnerability handling on the assignment of the EU Comission. That will be the foundational standard for the EU CRA vulnerability handling. The justifications proposed in this PR derive from the CRA, but the standards work is still going forward. It seems to remain at the same high level as the current ORT enums and the proposed ORT enums, so the current PR is okay from this perspective.

The standard text has six steps:

  • preparation (e.g. SECURITY.MD is in place etc)
  • Receipt of vuln information, such as monitoring of vulns databases against SBOMs
  • Verification (assessment of notifications, triage) <-- here are not exploitable outcomes but also such as what type of remediation is required, what is the remediation plan, so these requirements do high-light the nature of the CycloneDX-list that is specific to the triage point.
  • Remediation (fixing)
  • Release
  • Post-release

Anyhow, it would be good to satisfy as many schemes for vulnerability handling as possible, i.e. being CycloneDX "compatible" and CRA "compatible". That can be done in code or in process. We need the highest level at least in code. And then when going to detailed reasons, they can be either code - if reasonable - or comments/process. E.g. the current PR's list of enums could be nicely used with the list from CycloneDX, by applying NOT_EXPLOITABLE_VULNERABILITY, and then writing the more specific CycloneDX-justification there as a comment, possibly using the MITIGATED_VULNERABILITY. The high level in this PR seems therefore already aligned with CycloneDX, and then also the other high-level enums are covered, which the highlighed part of the CycloneDX-doc does not cover (they are likely elsewhere there?).

INEFFECTIVE_VULNERABILITY,

/**
* The vulnerability is irrelevant due to a tooling or database mismatch, e.g., the package version used
* does not match the version for which the vulnerability provider has reported a vulnerability.
*/
@Deprecated("Use FALSE_POSITIVE_VULNERABILITY instead", replaceWith = ReplaceWith("FALSE_POSITIVE_VULNERABILITY"))
INVALID_MATCH_VULNERABILITY,

/**
Expand All @@ -55,6 +67,17 @@
*/
NOT_A_VULNERABILITY,

/**
* The vulnerability exists in a component, but is not exploitable due to the product's specific architecture or
* configuration.
*/
NOT_EXPLOITABLE_VULNERABILITY,

Check warning on line 74 in model/src/main/kotlin/config/VulnerabilityResolutionReason.kt

View workflow job for this annotation

GitHub Actions / qodana-scan

Unused symbol 

Class "NOT_EXPLOITABLE_VULNERABILITY" is never used
Copy link
Member

@fviernau fviernau Sep 24, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regarding the entires PR, have you considered aligning with statuses defined in 1.
E.g. why should we deviated from that?

Copy link
Member Author

@sschuberth sschuberth Sep 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm following @willebra's advice / specification here.

Copy link

@willebra willebra Sep 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See comment #10886 (comment)

Copy link

@willebra willebra Sep 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A foundational requirement in the EU CRA is that products must be delivered "without any known exploitable vulnerabilities". So this choice of term makes ORT CRA-ready.


/**
* The vulnerability is acknowledged, but a conscious, documented decision is made to not apply a fix or mitigation.
*/
RISK_ACCEPTED_VULNERABILITY,

Check warning on line 79 in model/src/main/kotlin/config/VulnerabilityResolutionReason.kt

View workflow job for this annotation

GitHub Actions / qodana-scan

Unused symbol 

Class "RISK_ACCEPTED_VULNERABILITY" is never used

/**
* This vulnerability will never be fixed, e.g., because the package which is affected is orphaned,
* declared end-of-life, or otherwise deprecated.
Expand Down
Loading