Hey @gkatz1, I addressed the feedback, feel free to give it another look.

Hey @rossfuhrman could you please take a look at this MR as backend maintainer? Thank you!

Nicolae Rotaru (77572ce3) at 18 Mar 16:55

The scan_profile_eligibility_service accessor on the external context is a leftover from before I consolidated everything into scan_profile_context. I removed it in the last commit.

Nicolae Rotaru (05f6b543) at 18 Mar 13:56

Nicolae Rotaru (279ca7c2) at 18 Mar 12:56

... and 1614 more commits

Nicolae Rotaru (9928307c) at 18 Mar 11:56

Hey @gkatz1

Pretty solid points. I addressed them both. Please let me know if the implementation looks better now.

Agreed, the regex matching was brittle. Switched to the _metadata pattern you suggested - profile ID now travels with the job config through ScanPipelineService / CiAction::Template, same flow as scan execution policies. Removed build_job_name_to_profile_id_mapping entirely.

Please let me know if the implementation looks better now.

Good call, fixed. scan_profile_context is now the only entry point on the command.
The eligibility service is accessed via scan_profile_context.eligibility_service where needed.

Nicolae Rotaru (5637bd75) at 18 Mar 10:41

Nicolae Rotaru (fdbaa54c) at 18 Mar 09:46

Looks good, works as expected.

What does this MR do and why?

Add default DS scan profile based on #591553

Changelog: changed
EE: true

How to set up and validate locally

1. Select a root group g without DS security scan profiles.
2. Use this GraphQL query to get the available (default) profiles:

   query test {
     group(fullPath: "<g.full_path>") {
       availableSecurityScanProfiles(type: DEPENDENCY_SCANNING) {
         id
         scanType
         name
         description
         gitlabRecommended
         triggers
       }
     }
   }

3. Verify there is no DEPENDENCY_SCANNING profiles available.
4. Use this mutation to attach the default dependency_scanning profile to the projects under group g, and verify it fails with The resource that you are attempting to access does not exist:

       mutation {
      securityScanProfileAttach(
        input: {
          securityScanProfileId: "gid://gitlab/Security::ScanProfile/dependency_scanning"
          groupIds: ["gid://gitlab/Group/<g.id>"]
        }
      ) {
        errors
      }
    }

5. Turn :security_scan_profiles_dependency_scanning feature flag on:
   Feature.enable(:security_scan_profiles_dependency_scanning)
6. Using the same query, verify that default DEPENDENCY_SCANNING profile is returned with the correct name, description and triggers.
7. Using the same mutation, verify you are able to attach the default DEPENDENCY_SCANNING profile to projects under g.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #593009

Hey @gkatz1 I addressed your feedback and left a few comments. Feel free to give it a second look.

✅

✅

The counters reset on every state change (success resets failure count, failure resets success count), so they won't grow unbounded in practice. smallint max of 32,767 is safe. A defensive cap can be added in MR 3's UpdateService if preferred.

✅

✅