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 CVS Trigger vulnerability scans on SBOM changes (&8026). 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
- If there is no stable counterpart listed for Sales/CS please mention
- To see who the stable counterparts are for a product team visit product categories
-
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.