Show SkillGuard in security configuration and inventory

What does this MR do and why?

Mirrors the skillguard scan type on the frontend so a SkillGuard profile can be seen and managed: a SCAN_PROFILE_CATEGORIES entry on the security configuration page, its allowed trigger, and an SG coverage pill in the security inventory.

The backend landed in Enable SkillGuard through a security scan profile (!263332 - merged) • rossfuhrman • 19.6, which is now merged, so this MR is no longer stacked and targets master directly. It follows the BLSA equivalent, Show BLSA in security configuration and inventory (!258537 - merged) • Meir Benayoun • 19.5. Everything stays behind skillguard_analyzer, actored on the top-level group.

Changelog: added
EE: true

Design decisions

Trigger text is overridden. The generic MERGE_REQUEST_PIPELINE definition promises that "the full repository is scanned", which overstates what SkillGuard does. The subtitle, description and scope are overridden in SCAN_TRIGGER_DEFINITION_OVERRIDES to name the skill files it actually reads.

Visibility is flag-gated in isScanProfileTypeVisible, the same hook Automated Triage and Remediation uses. The category entry alone is not enough, because the security configuration page needs that entry to render the card at all.

SkillGuard is left out of the Enable Scanners Wizard for the beta. getAvailableScanProfiles already excluded Automated Triage and Remediation for the same reason, so that single comparison becomes a two-entry WIZARD_EXCLUDED_SCAN_TYPES list rather than a new mechanism.

visibleScannerGroups now hides each experiment independently, since there are two flags rather than one.

Known limitation, please read

The SkillGuard coverage pill can currently only ever render "not configured". skillguard is deliberately absent from PIPELINE_ONLY_TYPES in Security::AnalyzersStatus::BaseUpdateService, so attaching a profile never writes a Security::AnalyzerProjectStatus row, and being flow-backed there is no CI job to write one either. The security_inventory_filters.skillguard column stays 0.

That is invisible while the flag is off, but it means this MR should not be enabled for any group until the status pipeline lands with flow registration in Register SkillGuard security scan foundational ... (!256919) • Mher Tolpin • 19.6. If we would rather not carry a dead surface, this MR can be held and merged alongside the status work instead.

Related issue

https://gitlab.com/gitlab-org/gitlab/-/work_items/634364+s

Epic: https://gitlab.com/groups/gitlab-org/-/epics/22680+s

Screenshots or screen recordings

The surfaces render only with skillguard_analyzer feature flag on.

Inventory with flag off:

Inventory with flag on:

Bulk apply with flag off:

Bulk apply with flag on:

Project profile view with flag off:

Project profile view with flag on:

How to set up and validate locally

1. Enable the FF:

Feature.enable(:skillguard_analyzer, Group.find_by_full_path('your-group'))

1. Visit the group's Secure > Security configuration. The SkillGuard profile card appears, with "Merge Request Pipelines" as its trigger and skill-file-specific scope text ("AI agent skill files in the repository").
2. Visit Secure > Security inventory. An SG pill appears in the tool coverage column, and SkillGuard (SG) appears in the tool coverage filter.
3. Open the Enable Scanners Wizard from the tool coverage card and confirm SkillGuard is not offered.
4. Disable the flag and confirm the profile card, the pill and the filter token all disappear:

   Feature.disable(:skillguard_analyzer, Group.find_by_full_path('your-group'))

5. Run the frontend specs:

   yarn jest ee/spec/frontend/security_configuration ee/spec/frontend/security_inventory

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.