search

spdx / spdx-3-model

The model for the information captured in SPDX version 3 standard.
https://spdx.dev/use/specifications/
Other
70 stars 45 forks source link

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

Open VenkatTechnologist opened 8 months ago

VenkatTechnologist commented 8 months ago

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 commented 7 months ago

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

goneall commented 7 months ago

@jeff-schutt - Thoughts?

VenkatTechnologist commented 7 months ago

@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 commented 7 months ago

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

VenkatTechnologist commented 7 months ago

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

goneall commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 https://github.com/spdx/spdx-3-model/issues/652#issuecomment-2043530631, or unsubscribe https://github.com/notifications/unsubscribe-auth/BFJ5PILYYDX2ZGXKXXCJJXTY4LYKNAVCNFSM6AAAAABDX4ZW7SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBTGUZTANRTGE . You are receiving this because you were mentioned.Message ID: @.***>

rnjudge commented 7 months ago

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 commented 7 months ago

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 https://github.com/spdx/spdx-3-model/issues/652#issuecomment-2048491045, or unsubscribe https://github.com/notifications/unsubscribe-auth/BFJ5PINL4TY73C2J4U57B7LY4WXQXAVCNFSM6AAAAABDX4ZW7SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBYGQ4TCMBUGU . You are receiving this because you were mentioned.Message ID: @.***>