Skip to content

SPDX Export for the Dependency List at the Project Level

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Release notes

SPDX format is the primary format for license compliance and software metadata, while CycloneDX (already completed) focuses on licensing, compliance and software metadata. Providing users these two common standards will help us complete the SBOM story that the dependency list delivers on.

Problem to solve

SPDX format is the primary format for license compliance and software metadata, while CycloneDX (already completed) focuses on licensing, compliance and software metadata. Providing users these two common standards will help us complete the SBOM story that the dependency list delivers on.

Requirements

Allow users to produce an SPDX based format

  • in JSON - similar to CycloneDX this is a graph based format
  • at the project level (similar to the CycloneDX implementation, the thought of munging these together may be overkill)
  • As part of the export button (and via API) that is already present in the UI
  • The SPDX format can be found here: https://github.com/spdx/spdx-3-model/tree/main/schema

The format here can be broken down as follows

From Clause 6: Document Creation Information

Required

  • spdxVersion: SPDX spec version (e.g., SPDX-2.3)
  • dataLicense: License under which SPDX doc is shared (CC0-1.0)
  • SPDXID: Identifier for the SPDX document (e.g., SPDXRef-DOCUMENT)
  • name: Document name (often the project name)
  • documentNamespace: Unique URI to disambiguate this document
  • creationInfo.created: ISO timestamp for creation
  • creationInfo.creators: List of entities (tool, person, org) who created the doc
  • creationInfo.licenseListVersion: Version of SPDX license list used

Optional

  • creationInfo.comment: Notes about creation
Clause 7: Package Information
Required:
  • name: Package name (e.g., log4j)
  • versionInfo: Dependency version
  • SPDXID: Unique ID (e.g., SPDXRef-Package-log4j)
  • downloadLocation: Where it was retrieved from or NOASSERTION
  • licenseConcluded: License inferred to apply (or NOASSERTION)
  • licenseDeclared: Declared license by authors
  • PackageLicenseInfoFromFiles: Aggregate of license information found in the files
  • PackageLicenseComments: Notes regarding the license analysis
  • copyrightText: Usually NOASSERTION
    • FileCopyrightText: Copyright statements at the file level (if tracking at this granularity)
    • PackageCopyrightText: Copyright statements found in the package
  • checksums: SHA1/SHA256 of the package
  • releaseDate
  • supplier / originator: Who supplied or created the package
  • primaryPackagePurpose: Application vs. library
  • PackageAttributionText:Text that must be provided with distributions
  • FileNotice: Notices at the file level that must be preserved
Optional:
  • filesAnalyzed: Not relevant for gitlab dependency scans
  • packageFileName: Tarball or distribution file name
  • externalRefs: Reference to package URL, e.g., purl
  • homepage: Project homepage URL
  • sourceInfo: How the package was built
  • builtDate, releaseDate, validUntilDate: Timestamps
From Clause 11
Required (one per package):
Optional:
  • comment: Extra notes on the relationship

Most important fields, really, given the use case of compliance/licensing are:

  • licenseConcluded
  • licenseDeclared

Intended users

Feature Usage Metrics

We will add frontend event tracking when export menu items are clicked.

Does this feature require an audit event?

No

Edited by 🤖 GitLab Bot 🤖