<!--- Please read this! Before opening a new issue, make sure to search for keywords in the issues filtered by the "regression" or "type::bug" label: - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=regression - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=type::bug and verify the issue you're about to submit isn't a duplicate. ---> ### Summary When using the dependency scanning v2 template `Jobs/Dependency-Scanning.v2.gitlab-ci.yml` and latest `Jobs/Dependency-Scanning.v2.gitlab-ci.yml`, the Dependency scanning running control is not satisfied in the compliance centre for that specific compliance framework. This appears to only impact self-managed (18.9.1 in my testing), and works as expected on GitLab.com. I am curious if this could be caused by the lack of support for `gl-dependency-scanning-report.json` on self-managed in 18.9 or older :thinking: ### Steps to reproduce 1. Create a new compliance framework with the Dependency scanning running control 2. Create a new project with a compatible lock file, build job and [include the v2 template](https://docs.gitlab.com/18.9/user/application_security/dependency_scanning/dependency_scanning_sbom/#getting-started) 3. Allow the pipeline to run 4. Then visit the compliance centre for that framework, and notice the Dependency scanning running control check is failing 5. Revert to `latest` and set `DS_ENFORCE_NEW_ANALYZER: true` variable in your `.gitlab-ci.yml` 6. Open rails console and force refresh compliance framework checks - ```ruby ComplianceManagement::FrameworkEvaluationSchedulerWorker.new.perform ``` 7. Notice how the check also fails. ### Example Project I have this reproduced on a private self-managed instance, and can provide access to a GitLab team member upon request. ### What is the current *bug* behavior? Dependency scanning running control fails with v2 or latest DS template on self-managed ### What is the expected *correct* behavior? Dependency scanning running control should pass with v2 or latest DS template on self-managed ### Relevant logs and/or screenshots <!-- Paste any relevant logs - please use code blocks (```) to format console output, logs, and code as it's tough to read otherwise. --> ### Output of checks <!-- If you are reporting a bug on GitLab.com, uncomment below --> <!-- This bug happens on GitLab.com --> <!-- and uncomment below if you have /label privileges --> <!-- /label ~"reproduced on GitLab.com" --> <!-- or follow up with an issue comment of `@gitlab-bot label ~"reproduced on GitLab.com"` if you do not --> #### Results of GitLab environment info <!-- Input any relevant GitLab environment information if needed. --> <details> <summary>Expand for output related to GitLab environment info</summary> <pre> (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`) </pre> </details> #### Results of GitLab application Check <!-- Input any relevant GitLab application check information if needed. --> <details> <summary>Expand for output related to the GitLab application check</summary> <pre> (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) </pre> </details> ### Possible fixes <!-- If you can, link to the line of code that might be responsible for the problem. --> ### Patch release information for backports If the bug fix needs to be backported in a [patch release](https://handbook.gitlab.com/handbook/engineering/releases/patch-releases) to a version under [the maintenance policy](https://docs.gitlab.com/policy/maintenance/), please follow the steps on the [patch release runbook for GitLab engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/patch/engineers.md). Refer to the [internal "Release Information" dashboard](https://dashboards.gitlab.net/d/delivery-release_info/delivery3a-release-information?orgId=1) 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](https://handbook.gitlab.com/handbook/engineering/releases/internal-releases/) for single-tenant SaaS instances, refer to the [internal release process for engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/internal-releases/engineers.md?ref_type=heads). <!-- If you don't have /label privileges, follow up with an issue comment of `@gitlab-bot label ~"type::bug"` -->