Spike: Provide migration path for customers that use the dependency scanning security report artifact in their tooling
Problem to solve
We have received feedback that some customers depend on the security report artifact to power custom built solutions. We never explicitly declared that these artifacts were supported in this fashion, but it appears that removing them from the new analyzer will leave customers without a solution. In the spirit of "Migrations over Breaking Changes", we should investigate a way to accommodate customers affected by this while we work to bridge the shortcomings of the platform that prompted them to build custom solutions.
Additional info
We've identified that the security reports were being used to
- Stop code from merging when it contains an unapproved vulnerability
- Stop a deployment when it contains an unapproved vulnerability
- Customize vulnerability details like severity
Long term improvements in this area will be tracked by:
- Allow merge request policies to have a block me... (#521765)
- Allow deployment approvals to consider security... (#521766 - closed)
- Manual Vulnerability Severity Overrides (&16157 - closed) • Gal Katz, Chen Charnolevsky (OOO until January 20, 2026) • 17.10
Proposals
- #521769 (comment 2372907543)
- #521769 (comment 2372884422)
- #521769 (comment 2373019533)
- #521769 (comment 2383356667)
Outcome
Our primary concern is preventing user insatisfaction and breaking existing workflows. Thus, our objective is to react positively to the feedback we've received and ensure the product we're developing is matching our customers needs.
We generally agreed on re-instating the DS security report (proposal 3), with some additional considerations and details to further discuss.
- Even if the DS using SBOM feature is in Beta, we can't break it freely. Indeed, as we've already deprecated Gemnasium, we've pushed some customers to already start using this feature with the current implementation. Reverting to a state where their integration could break is not deemed acceptable. Instead, we'll have to work through a migration and ensure user are not using it before we possibly sunset that feature in its current implementation. I will further refine this use case and the consequences it has on the new scope.
- We'd like to distinguish the maturity of the DS analyzer from the DS using SBOM feature, and call the former GA while keeping the later as Beta. There might be some challenges in doing that though. For instance, how will this play out with the redesign of the DS using SBOM feature?
- We must ensure to invest in setting proper metrics to drive decisions with data. Re-instating the DS report will give us the opportunity to leverage Update security report processing to handle met... (#473109 - closed), which we should do.
Thus we will re-design the Dependency Scanning using SBOM feature before making it Generally Available. That work is tracked in this new epic: Bring security scan results back into the Depen... (&17150 - closed)