cdfoundation / sig-security-sbom Goto Github PK

There are several attributes specific to a package which are not captured in the other artifact types (e.g. download location, home page).

SPDX currently has these fields in the Package class. Not having these fields would create a compatibility issue.

this would be for compatibility with SPDX and perhaps simplify the spec.

Note the related issue in SPDX to add this as a required field (spdx/spdx-spec#171) - one of these approaches (but certainly not both) is needed to make the SBOM and SPDX compatible in 3.0.

Remove the snippets attribute from AbstractFile and only have a one way association from snippet to the file since it may be difficult for a file to know all snippets associated with it at SBOM construction time.

This would also help with SPDX compatibility.

Hi all,

The CDF is in the process of changing all the default branches for repositories within cd foundation org from master to main.
Some of these renaming changes have happened already.

I have unarchived this repo to change the default branch name to main and will soon re-archive the repo.

If any issues due to this change arise, please let me know by commenting on this issue.

Thank you!

Referencing artifacts in external documents seems to be structurally incompatible with the approach taken in SPDX.

Propose we review the 2 approaches (SBOM and SPDX) with concrete examples and determine if there are structural incompatibilities. If incompatible, propose changes to SBOM, SPDX or both.

This is a structural change to the current model.

Currently, creation information is in the attributes author and specVersion.

In SPDX, these are in a single attribute creationInformation which contains this information. A previous version of the model used this approach.

Currently, this repo consists of SVG and XMI for describing the model. Developing a SBOM schema by vector image or using XMI (an XML format that no tool understands) is a non-starter. I cannot see how this effort will be successful if we are looking at images without the ability discover, or dynamically browse the schema we're developing.

This seems to be multiple anti-patterns laid on top of each other in order to satisfy a standards body's requirements. It's actually quite crippling when you factor in that only a single individual in the working groups knows how to use the tool and has been doing all the development.

If you want increased participation in this effort, first-class support for XSD and JSON schema should be the approach. Let the community use the vast selection of tools available to understand and help develop the schema. Then use whatever conversion utility is required to generate the XMI to satisfy the standards body.

Without this capability, this project will likely never receive PRs to add corrections or other changes to the model as I don't think anyone will take the time to submit PRs against a vector image or XMI.

Propose changing LicenseReference Class to the SPDX ExtractedLicensingInfo class
Properties:
licenseId [1] – string
comment [0..1] – string
name [0..1] – string
seeAlso [*] – URL
extratedText [1] - string

This is a proposed structural change.

Background: The document is the actual artifact containing the BOM itself. Creating a checksum and storing in itself is mathematically impossible since storing the checksum in the document will modify the content and therefore modify the checksum.

This is also incompatible with SPDX.

The checksum is currently an inherited attribute from Element.

There are several possible solutions.

The approach SPDX took was to introduce another abstract class. In SBOM, the Artifact class could serve this purpose.

Proposal to resolve this issue: Move the checksum attribute from Element to Artifact.

Propose a similar structure for the LicenseInformationClass to what SPDX uses today.
Remove the type and use separate attribute for the different types of licenses, all of which have cardinality [0..1] declaredLicense, concludedLicense, distributedLicense. Each of these attributes would contain a valid SPDX license expression.
Add a licenseComment to capture the “other”

Clarify the semantics of the artifacts/documentDescribes in the Document as to whether this association is just for the artifacts described by the document or ALL artifacts contained within the SBOM.

SPDX uses the similar documentDescribes to describe the Artifacts the document is describing. The documentDescribes does not include all artifacts included in the document (e.g. if the Document is describing a package and that package contains files, the files will be included in the document but would not be part of the documentDescribes attribute).

Propose artifacts/documentDescribes having the same semantics as SPDX.

Propose merging the CopyrightInformation class with the LicenseInformationClass to simplify the model. It is very unlikely one would be present without the other.

Propose new class name of CopyrightLicenseInformation or IPInformation (IP being short for Intellectual Property)

Originator is an optional attribute of Package in SPDX.

It is an important field for several use cases. Although some of the more detailed (and complex) types and classes in SBOM may provide similar information, having a simple text field would be quite useful and allow for compatibility.

We need a CONTRIBUTING.md file to describe the license for repository content.

This will be a collaborative effort between @goneall, @tsteenbe, @CASTResearchLabs and @kaywilliams.

Thomas will provide boilerplate contributing.md file

Philippe-Emmanuel will provide information on how to edit content model content (JSON files) and rebuild model, documentation, and visuals.

Kay will work with Bob and attorneys to confirm license. Several options we discussed:

• Apache 2.0
• Apache 2.0 with DCO (developer certificate)
• Contributor License Agreement (CLA)

Hash support is limited and ambiguous in the case of SHA. CycloneDX is more precise and supports the following:

<xs:simpleType name="hashAlg">
  <xs:restriction base="xs:string">
    <xs:enumeration value="MD5"/>
    <xs:enumeration value="SHA-1"/>
    <xs:enumeration value="SHA-256"/>
    <xs:enumeration value="SHA-384"/>
    <xs:enumeration value="SHA-512"/>
    <xs:enumeration value="SHA3-256"/>
    <xs:enumeration value="SHA3-512"/>
  </xs:restriction>
</xs:simpleType>

<xs:simpleType name="hashValue">
  <xs:restriction base="xs:token">
    <xs:pattern value="([a-fA-F0-9]{32})|([a-fA-F0-9]{40})|([a-fA-F0-9]{64})|([a-fA-F0-9]{96})|([a-fA-F0-9]{128})"/>
  </xs:restriction>
</xs:simpleType>

It also supports simple validation of the field as well, although complex validation (e.g. SHA-512 alg with only 40 characters) is not supported.

Propose changing the SBOM Snippet class structure and attribute names to be compatible with SPDX and W3C pointer definitions

Add classes StartEndPointer, (abstract) singlePointer, byteRangePointer and LineCharPointer
Add properties byteRange and lineRange with type StartEndPointer