spdx/spdx-3-model

assessedElement to target SoftwareArtifact instead of Element

Closed this issue · 5 comments

ilans commented

From /Security/assessedElement:
"Specifies subpackages, files or snippets ..."

If it's limited to only packages, files and snippets then why its target is Element and not SoftwareArtifact?

Package, File and Snippet are the only subclasses of SoftwareArtifact.

zvr commented

I think the target should be /Core/Artifact.

Since in the future we might have security info for other, non-software artifacts.

  • 👍1
goneall commented

Note - that if we make this more restrictive, it will be a breaking change, so this will have to be in either 3.0.1 or 4.0.

kestewart commented

Having it as Element is going to provide more flexibility for future profiles. Ok to discuss further but at this point it's going to 4.0 related change.

For instance, we could have an assessedElement on a Role or Relationship type which are not artifacts.

kestewart commented

Removing the milestone until this is discussed.

goneall commented

Discussed on tech call 2024-12-03:

  • We want to allow the future relationship to hardware - propose Artifact rather than SoftwareArtifact
  • Going from more restrictive to less restrictive would not be a breaking change, so we could restrict to SoftwareArtifact today and add HardwareArtifact in 3.1 without it being a breaking change
  • Requirement don't block the hardware profile
  • Requirement that we don't block functional safety
  • In general, don't block any other future profiles
  • Propose: Go with more restrictive now, relax the restrictions with the new profiles - this won't be breaking changes, so we meet the requirements
  • Specific change is to change range from "Element" to "SoftwareArtifact"
  • 👍1