Enable SkillGuard through a security scan profile

rossfuhrmanrequested to merge
634364-skillguard-scan-profile into master

What does this MR do and why?

Lets customers turn SkillGuard on by attaching a scan profile, the same way the Business Logic profile works.

  • Stacked on !263331 (merged), which registers the analyzer type. Review and merge that one first; this MR targets its branch.
  • Trigger: merge request pipelines only, matching BLSA. A scan runs after a merge request's head pipeline succeeds.
  • No configuration. SkillGuard is flow-backed, so there is no injected CI job to pass variables to. Its scan type gets no Configuration::SCHEMAS entry and no CiVariables::MAPPINGS entry, so it falls through to the empty configuration schema exactly as business_logic does.
  • Everything stays behind skillguard_analyzer, actored on the top-level group.

What this MR does not do

No scan runs yet. The skillguard_scan/v1 foundational flow is not registered in the monolith, so the profile is stored and surfaced but nothing reads it. Flow registration is tracked separately in !256919.

Analyzer status stays not_configured. skillguard is deliberately left out of PIPELINE_ONLY_TYPES. ProfileBasedUpdateService sets a project to success on profile attachment alone, independent of whether a scan ran, so wiring status now would report SkillGuard as covered while nothing scans. Status lands with the flow.

Review focus

  • ALLOWED_TRIGGER_TYPES_BY_SCAN_TYPE is what makes a trigger valid at all; without an entry every trigger fails trigger_type_compatible_with_profile.
  • FindOrCreateService#flag_enabled_for? replaces two near-identical flag checks on the saved-profile and preset paths. Behaviour is unchanged for business_logic and triage_and_remediation.
  • scanner_enabled? in the EE configuration presenter now keys off FLOW_BACKED_SCAN_TYPES rather than naming business_logic, so both flow-backed types resolve from profile presence.

References

Screenshots or screen recordings

No UI changes in this MR; the security configuration and inventory surfaces arrive in part 3 of the stack.

How to set up and validate locally

  1. Enable the flag for a top-level group: 
    Feature.enable(:skillguard_analyzer, Group.find_by_full_path('your-group'))
  2. Query group.availableSecurityScanProfiles and confirm the GitLab-provided SkillGuard (default) preset is listed. Disable the flag and confirm it disappears.
  3. Attach that preset to a project with securityScanProfileAttach. This is the path customers take: GitLab provides the profile, the customer enables it.
  4. Check Secure > Security configuration: SkillGuard shows as enabled because a profile is attached.
  5. Optional, for trigger validation: securityScanProfileCreate with scanType: SKILLGUARD and a MERGE_REQUEST_PIPELINE trigger succeeds; the same call with DEFAULT_BRANCH_PIPELINE fails with is not allowed for skillguard scan profiles.

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.

Edited by rossfuhrman

Merge request reports