Container Scanning CycloneDX SBOM reports not ingested when no other security reports exist

Summary

A lot has changed in the ingestion related codebase thus it isn't easy to pinpoint in which moment the ingestion of CS cyclonedx reports stopped working when additional reports aren't present.

Previously, the SBOM ingestion worker was triggered:

  1. After a pipeline completed when no other security report was provided
  2. After the main ingestion workflow of the security reports

As mentioned above, a lot has changed in this part of the codebase, and it seems that now the SBOM ingestion worker will only be triggered when there are other security reports or when the SBOM file is of the dependency scanning type. Differently from the previous workflow, now the SecurityReportBuilder is involved in the code flow but it only supports dependency scanning report types.

The initial motivation for this builder was to support the creation of security findings which, in alignment with CVS, only supports dependency scanning.

This issue doesn't happen when there are other security reports or DS cyclonedx reports within the same pipeline.

Steps to reproduce

  1. Create a project and run the pipeline on the default branch with the following files:

.gitlab-ci.yml:

container_scanning:
  stage: test
  artifacts:
    access: 'developer'
    reports:
      cyclonedx: gl-sbom.cdx.json
    paths: ["**/gl-container-scanning*.json", "**/gl-sbom.cdx.json"]
  script:
    - echo 'testing container scanning'

gl-sbom.cdx.json:

{
  "$schema": "http://cyclonedx.org/schema/bom-1.6.schema.json",
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:dbe97a38-3c50-4fbc-9f38-75043b60ca5c",
  "version": 1,
  "metadata": {
    "timestamp": "2025-08-22T22:21:47+00:00",
    "tools": {
      "components": [
        {
          "type": "application",
          "manufacturer": {
            "name": "Aqua Security Software Ltd."
          },
          "group": "aquasecurity",
          "name": "trivy",
          "version": "0.65.0"
        }
      ]
    },
    "properties": [
      {
        "name": "gitlab:meta:schema_version",
        "value": "1"
      },
      {
        "name": "gitlab:container_scanning:image:name",
        "value": "alpine"
      },
      {
        "name": "gitlab:container_scanning:image:tag",
        "value": "3.15"
      },
      {
        "name": "gitlab:container_scanning:operating_system:name",
        "value": "alpine"
      },
      {
        "name": "gitlab:container_scanning:operating_system:version",
        "value": "3.15.11"
      }
    ]
  },
  "components": [
    {
      "bom-ref": "23b9cc5e-72f3-428f-a437-a21ac8d96f6e",
      "type": "operating-system",
      "name": "alpine",
      "version": "3.15.11",
      "properties": [
        {
          "name": "aquasecurity:trivy:Class",
          "value": "os-pkgs"
        },
        {
          "name": "aquasecurity:trivy:Type",
          "value": "alpine"
        }
      ]
    }
  ],
  "dependencies": [],
  "vulnerabilities": []
}
  1. Go to Secure > Dependency List
  2. There won't be any dependencies listed.

Example Project

What is the current bug behavior?

There are no dependencies in the dependency list page.

What is the expected correct behavior?

There should be one dependency in the dependency list page.

Relevant logs and/or screenshots

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info 

(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`)

Results of GitLab application Check

Expand for output related to the GitLab application check 
(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)

Possible fixes

Patch release information for backports

If the bug fix needs to be backported in a patch release to a version under the maintenance policy, please follow the steps on the patch release runbook for GitLab engineers.

Refer to the internal "Release Information" dashboard 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 for single-tenant SaaS instances, refer to the internal release process for engineers.

Edited by Zamir Martins