Skip to content

Dependency list export with API silently fails license validation

Summary

SBOM (Software Bill of Materials) dependency list exports fail with schema validation error when dependencies contain SPDX license IDs that are not in GitLab's static validation list, preventing API-based exports from completing.

Steps to reproduce

  1. Have a GitLab project with dependencies that use SPDX license IDs not included in GitLab's static validation list
  2. Attempt to export dependency list in SBOM format using the API:
  3. Check the export status repeatedly - it will remain stuck at "has_finished": false

Example Project

What is the current bug behavior?

  • SBOM export creation appears to succeed (returns HTTP 201 with export ID)
  • Export status remains permanently at "has_finished": false and never completes
  • Background processing fails with validation error: Invalid CycloneDX report: property '/components/2/licenses/2/license/id' is not one of: [extensive list of valid SPDX license IDs]
  • No user-facing error message indicates the cause of the failure

What is the expected correct behavior?

SBOM exports should complete successfully even when dependencies contain SPDX license IDs not in GitLab's static validation list

Relevant logs and/or screenshots

Error from logs


Message: 
Invalid CycloneDX report: property '/components/2/licenses/2/license/id' is not one of: [long list of valid SPDX license IDs]```

**API Response (stuck indefinitely):**

```json

{
  "id": 3275535,
  "status": "created",
  "has_finished": false,
  "export_type": "sbom",
  "send_email": false,
  "expires_at": null,
  "self": "https://gitlab.com/api/v4/dependency_list_exports/3275535",
  "download": "https://gitlab.com/api/v4/dependency_list_exports/3275535/download"
}````

## 

### Output of checks

<!--If you are reporting a bug on GitLab.com, uncomment below-->

<!--This bug happens on GitLab.com-->

<!--and uncomment below if you have /label privileges-->

<!--/label ~"reproduced on GitLab.com"-->

<!--or follow up with an issue comment of `@gitlab-bot label ~"reproduced on GitLab.com"` if you do not-->

This bug happens on GitLab.com

## 

#### Results of GitLab environment info

<!--Input any relevant GitLab environment information if needed.-->

<details>
<summary>Expand for output related to GitLab environment info</summary>

<pre>

 (For installations with omnibus-gitlab package run and paste the output of: \`sudo gitlab-rake gitlab:env:info\`)  (For installations from source run and paste the output of: \`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production\`)  
</pre>
</details>

#### Results of GitLab application Check

<!--Input any relevant GitLab application check information if needed.-->

<details>
<summary>Expand for output related to the GitLab application check</summary>

<pre>

(For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:check SANITIZE=true`)

(For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true`)

(we will only investigate if the tests are passing)

</pre>
</details>

### Possible fixes

<!--If you can, link to the line of code that might be responsible for the problem.-->

### Patch release information for backports

If the bug fix needs to be backported in a [patch release](https://handbook.gitlab.com/handbook/engineering/releases/patch-releases) to a version under [the maintenance policy](https://docs.gitlab.com/policy/maintenance/), please follow the steps on the [patch release runbook for GitLab engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/patch/engineers.md).

Refer to the [internal "Release Information" dashboard](https://dashboards.gitlab.net/d/delivery-release_info/delivery3a-release-information?orgId=1) for information about the next patch release, including the targeted versions, expected release date, and current status.

#### High-severity bug remediation

To remediate high-severity issues requiring an [internal release](https://handbook.gitlab.com/handbook/engineering/releases/internal-releases/) for single-tenant SaaS instances, refer to the [internal release process for engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/internal-releases/engineers.md?ref_type=heads).

/label ~"type::bug"



<!--If you don't have /label privileges, follow up with an issue comment of `@gitlab-bot label ~"type::bug"`-->

How to set up and validate locally

Before Change:

  1. Have a GitLab project with dependencies that use SPDX license IDs not included in GitLab's static validation list

    (example repo)

  2. Attempt to export dependency list in SBOM format using the API

  3. The export should complete, and the report will be downloadable with the invalid licenses included

Edited by Harrison Peters