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 1 commit
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
7 changes: 7 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 @@ -40,6 +40,7 @@ enum class VulnerabilityResolutionReason {
* 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,

/**
Expand All @@ -60,6 +61,12 @@ enum class VulnerabilityResolutionReason {
*/
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,
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.
*/
Expand Down