Deprecate Dependency Scanning reports

For guidance on the overall deprecations, removals and breaking changes workflow, please visit Breaking changes, deprecations, and removing features

Deprecation Summary

Dependency Scanning is moving from a CI job based approach to a worker based approach as part of SBOM-based dependency scanning findings for def... (&8026 - closed). To simplify the security ingestion path for Dependency Scanning, we should deprecate dependency scanning reports and favor the CycloneDX specification which includes a vulnerabilities field in the component schema. This field will allow third parties to integrate with the security ingestion process, and handle the responsibility previously held by dependency_scanning reports.

Breaking Change

The dependency_scanning reports will no longer be parsed and ingested, so all vulnerabilities should be tied to a CycloneDX component's vulnerabilities field instead.

Affected Topology

  • Self-managed
  • SaaS

Affected Tier

  • Ultimate

Checklists

Labels

  • This issue is labeled deprecation, and with the relevant ~devops::, ~group::, and ~Category: labels.
  • This issue is labeled breaking change if the removal of the deprecated item will be a breaking change.

Timeline

Please add links to the relevant merge requests.

  • As soon as possible, but no later than the third milestone preceding the major release (for example, given the following release schedule: 14.8, 14.9, 14.10, 15.0 – 14.8 is the third milestone preceding the major release):
    • A deprecation announcement entry has been created so the deprecation will appear in release posts and on the general deprecation page.
    • Documentation has been updated to mark the feature as deprecated.
  • On or before the major milestone: A removal entry has been created so the removal will appear on the removals by milestones page and be announced in the release post.
  • On the major milestone:
    • The deprecated item has been removed.
    • If the removal of the deprecated item is a breaking change, the merge request is labeled breaking change.

Mentions

  • Your stage's stable counterparts have been @mentioned on this issue. For example, Customer Support, Customer Success (Technical Account Manager), Product Marketing Manager.
    • To see who the stable counterparts are for a product team visit product categories
      • If there is no stable counterpart listed for Sales/CS please mention @timtams
      • If there is no stable counterpart listed for Support please mention @gitlab-com/support/managers
      • If there is no stable counterpart listed for Marketing please mention @cfoster3
  • Your GPM has been @mentioned so that they are aware of planned deprecations. The goal is to have reviews happen at least two releases before the final removal of the feature or introduction of a breaking change.

Deprecation Milestone

Planned Removal Milestone

Links

  • CycloneDX schema
  • SBOM-based dependency scanning findings for def... (&8026 - closed)
Edited Aug 11, 2025 by 🤖 GitLab Bot 🤖
Assignee Loading
Time tracking Loading