Draft: Show one advanced configuration per profile [ci skip]

What does this MR do and why?

Layout option 3 of 3 for showing a secret detection profile's analyzer settings. This one follows @gkatz1's reading of the UI/UX meeting: present a single configuration for the whole profile, which makes the Trigger column redundant.

The bottom of the scan profile details modal gains an Advanced configuration section with a Setting / Value table, one row per setting rather than one per trigger.

The three options

	Layout
Draft: Show advanced configuration in the profi... (!252986 - closed)	one table at the bottom, a row per trigger per setting
Draft: Show advanced configuration in each trig... (!253278 - closed)	a table inside each trigger's card
this MR	one table at the bottom, one row per setting for the whole profile

Discussion: Advanced Secret Detection Configuration Profile (gitlab-org#20198)

The honesty problem, and how this handles it

The backend has no per-profile configuration. It hangs off security_scan_profile_triggers via a nullable FK, and securityScanProfileUpdate can only write it through the triggers array. A single profile-level table is therefore a presentation-layer fiction over per-trigger data, and it has to decide what to show when triggers disagree.

• where the triggers that set a value agree, the value shows plainly
• where they disagree, each distinct value is named with the triggers holding it, for example Yes (Merge Request Pipelines); No (Branch pipelines (default only)) - rather than picking one and silently misreporting the rest

One case is deliberately papered over: a setting only one trigger sets counts as agreed and shows plainly, which overstates it as profile-wide. That is inherent to the model rather than a bug, and is called out here so it is a decision rather than an accident. There is a test pinning the behaviour.

Screenshots

References

• issue: [Frontend] Support custom Secret Detection prof... (#624190 - closed)
• follow-up issue that reuses the section in the drawer: [Frontend] Scan profile drawer: view, create, e... (#624191 - closed)
• epic: Advanced Secret Detection Configuration Profile (gitlab-org#20198)
• designs: Design: Advanced Configuration Profiles management (gitlab-org#23403)
• backend implementation plan for per-trigger configuration: [Backend] Advanced profiles: Implementation plan (#604721 - closed)
• the field to CI variable mapping these names come from: ee/app/models/security/scan_profiles/configuration/ci_variables.rb
• why secret push protection carries no configuration: UNCONFIGURABLE_TRIGGER_TYPES_BY_SCAN_TYPE in ee/app/models/security/scan_profile_trigger.rb

How to set up and validate locally

0. git checkout 624190-advanced-configuration-per-profile
   echo "Feature.enable(:configurable_security_scan_profiles)" | gdk rails c

1. have a GitLab Ultimate licence

2. be Maintainer, Owner or Security Manager on the root group

3. create a custom secret detection profile whose two configurable triggers disagree, so the conflict handling is exercised

   • open GraphiQL at /-/graphql-explorer and run the mutation below, substituting the root group's gid://gitlab/Group/<group_id>
   • GIT_PUSH_EVENT deliberately carries no configuration, since the backend rejects one
   expand for the create mutation

   mutation {
     securityScanProfileCreate(
       input: {
         namespaceId: "gid://gitlab/Group/<group_id>"
         scanType: SECRET_DETECTION
         name: "Advanced configuration demo"
         description: "Two configurable triggers that disagree"
         stripDefaults: false
         triggers: [
           { triggerType: GIT_PUSH_EVENT }
           {
             triggerType: MERGE_REQUEST_PIPELINE
             configuration: {
               secretDetection: {
                 secureAnalyzersPrefix: "registry.gitlab.com/security-products"
                 imageSuffix: FIPS
                 historicScan: true
                 logOptions: "--all"
                 excludedPaths: ["spec/fixtures/**", "**/*.min.js"]
               }
             }
           }
           {
             triggerType: DEFAULT_BRANCH_PIPELINE
             configuration: {
               secretDetection: {
                 secureAnalyzersPrefix: "registry.gitlab.com/security-products"
                 imageSuffix: DEFAULT
                 historicScan: false
               }
             }
           }
         ]
       }
     ) {
       scanProfile {
         id
         name
       }
       errors
     }
   }

4. go to a project in that group => Secure => Security configuration

5. select the Preview profile button on the row for the custom profile - the eye icon in the actions column

6. check that the modal shows an Advanced configuration section at the bottom, below the trigger cards, with only Setting and Value columns

7. check the values, which exercise all three cases:

   • SECURE_ANALYZERS_PREFIX shows the shared value plainly, because both triggers agree
   • SECRET_DETECTION_IMAGE_SUFFIX and SECRET_DETECTION_HISTORIC_SCAN name the trigger against each value, because the two triggers disagree
   • SECRET_DETECTION_EXCLUDED_PATHS shows plainly even though only the merge request trigger sets it - the overstatement described above

8. check that SECRET_DETECTION_RULESET_GIT_REFERENCE does not appear at all, since neither trigger sets it

9. check that no row mentions Secret push protection

the trigger cards

10. check that the merge request and default branch cards:
    • no longer show a Scope: row
    • no longer promise a full repository scan or every vulnerability in their descriptions
    • still show their Target branch: and Results: rows, which the settings cannot contradict

to run tests

yarn jest ee/spec/frontend/security_configuration/components/scan_profiles