Skip to content

Dependency Scanning SBOM scan API fails authentication when using a custom token

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

Summary

When users override the CI_JOB_TOKEN with a different one (e.g. a project access token) this breaks the API logic that expect an original CI_JOB_TOKEN to identify the corresponding CI job. (Example customer report: #523458 (comment 2791667211))

It's not clear at the moment why such override does not affect the CI job artifact upload functionality, as it uses the same authentication method.

Note that overridding pre-defined CI variables is discouraged in our docs https://docs.gitlab.com/ci/variables/#use-pipeline-variables

You should avoid overriding predefined variables in most cases, as it can cause the pipeline to behave unexpectedly.

Steps to reproduce

Reproduced in this CI job: https://gitlab.com/gitlab-org/secure/tests/olivier/monorepo-multi-language/-/jobs/11571938124

  1. Clone/fork the example project:
  2. Create a new project access token with api scope: Settings -> Access tokens
  3. Add a new CUSTOM_CI_JOB_TOKEN CI variable exposing this token: Settings -> CI/CD Settings -> Variables
    • Screenshot_2025-10-29_at_09.48.44
  4. Run a pipeline and see the 403 error in the log:
    • Screenshot_2025-10-29_at_09.55.30

Example Project

What is the current bug behavior?

The SBOM Scan API fails to authenticate queries when using a custom token like a project access token with api scope.

What is the expected correct behavior?

The SBOM Scan API should succeed in authenticating queries when using a custom token like a project access token with api scope, considering such scope is granting full read/write access on API.

Alternatively, we could advise on using fine grained token permissions but we'd first have to implement such fine grained permission for these particular API endpoints.

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

  1. Investigate why CI job artifact upload endpoint doesn't fail similarly and possibly apply same logic to our API.
  2. Maybe consider https://docs.gitlab.com/ci/jobs/fine_grained_permissions/

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 🤖 GitLab Bot 🤖