Remove 'exploited' field in model/Security/Classes/ExploitCatalogVulnAssessmentRelationship.md

[VenkatTechnologist]

Per my understanding, a vulnerability is entered into an exploit catalog such as KEV only when it has been already exploited.
If we know that it has been already exploited, why do we need a Boolean field known as 'exploited' to indicate if it has been
exploited or not? I suggest removing this field (unless there's a case when a vulnerability will return back to
'unexploited' from 'exploited', which I don't think it will ever will).

[goneall]

@VenkatTechnologist is this still valid based on your current analysis?

[goneall]

@jeff-schutt - Thoughts?

[VenkatTechnologist]

@VenkatTechnologist is this still valid based on your current analysis?

Yes. This is being currently discussed in some forums. The overall opinion seems to be that once there's an exploit, it will always remain an exploit (true). And hence, this field seems redundant.

Here's one discussion that I came across:

https://www.linkedin.com/posts/jayjacobs1_vulnerability-vulnerabilitymanagement-vulnerabilityassessment-activity-7167539737052868608-rQXD?utm_source=share&utm_medium=member_desktop

[goneall]

@puerco @jeff-schutt - Can you review / weigh in - we need to close these before the 3.0 release which is coming up quick

[VenkatTechnologist]

I presume there might be some consultations required with industry experts, which might take time.

[goneall]

Since removing this will be a breaking change - we need to make a decision within the next few days. If we remove it, adding it back would not be a breaking change and could be done in 3.1.

Waiting for @jeff-schutt and @puerco to weigh in.

[jeff-schutt]

Yes, the logic of the argument holds: once exploited, a vuln in a particular software version will remain exploitable.

When we discussed this we decided that the extra information would be beneficial for a different reason. Consider that there are likely to be multiple exploit catalogs from which one could correlate vulnerability exploitation. Keeping this field allows one to search the graph or an SPDX document without having to know the name of every catalog that might be listed.

I recommend that we leave the field in the spec.

[VenkatTechnologist]

I don't quite understand the explanation. In fact, I do not think having this binary has any implications on having to know the name of every catalog. Please provide more details, and examples. Thanks.

…

On Tue, Apr 9, 2024 at 1:21 AM Jeff Schutt ***@***.***> wrote: Yes, the logic of the argument holds: once exploited, a vuln in a particular software version will remain exploitable. When we discussed this we decided that the extra information would be beneficial for a different reason. Consider that there are likely to be multiple exploit catalogs from which one could correlate vulnerability exploitation. Keeping this field allows one to search the graph or an SPDX document without having to know the name of every catalog that might be listed. I recommend that we leave the field in the spec. — Reply to this email directly, view it on GitHub <#652 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BFJ5PILYYDX2ZGXKXXCJJXTY4LYKNAVCNFSM6AAAAABDX4ZW7SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBTGUZTANRTGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[rnjudge]

Deferring to 3.1 per comment above.

When we discussed this in the security call today a comment was made that this is a technical issue (with JSON-LD) being transposed on the model but @tsteenbe strongly advocated for this from the beginning of the security profile.

[VenkatTechnologist]

This field could be set/reset by component suppliers without rfully realizing the background of a vulnerability, and thus a risk to consumers. SPDX internal implementation details should not ideally dictate the end-user functionality in general. Hence suggest alternate implementation, and removing this variable. Thanks.

…

On Thu, 11 Apr, 2024, 3:17 am Rose Judge, ***@***.***> wrote: Deferring to 3.1 per comment above. When we discussed this in the security call today a comment was made that this is a technical issue (with JSON-LD) being transposed on the model but @tsteenbe <https://github.com/tsteenbe> strongly advocated for this from the beginning of the security profile. — Reply to this email directly, view it on GitHub <#652 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BFJ5PINL4TY73C2J4U57B7LY4WXQXAVCNFSM6AAAAABDX4ZW7SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBYGQ4TCMBUGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>