## Problem The Security Inventory (SRM Profiles / security coverage view) currently determines which security tools are active for a project by inspecting report-type-specific CI job definitions (e.g. a job that produces a `gl-sast-report.json` artifact is counted as "SAST coverage"). This works well for GitLab-native scanners but breaks down when a project relies on direct SARIF uploads. When a SARIF report is uploaded directly (via the new `sarif` artifact type introduced in [#452042](https://gitlab.com/gitlab-org/gitlab/-/work_items/452042)), the scan type is inferred from the identifiers embedded in the findings (e.g. CWE → SAST, CVE → dependency scanning). There is no dedicated CI job per report type, so the existing rendering logic never registers coverage for those tool categories, leaving the security inventory incomplete or misleading. ## Impact - Projects that replace native GitLab scanners with third-party SARIF-producing tools appear to have **zero tool coverage** in the security inventory, even when they are actively scanning. - Security and compliance dashboards that surface tool coverage (e.g. for audit or policy purposes) will show false negatives. - The gap will grow as SARIF direct upload adoption increases. ## Proposed Investigation 1. **Audit the current coverage-detection path** – trace how the security inventory and Profiles resolve "which scanners are enabled" for a project today 2. **Map report type inference** – document how `Security::Scan` and the SARIF parser currently infer `scan_type` from identifiers (CWE, CVE, OWASP, etc.) and whether that inferred type is persisted on the `security_scans` record. (This might require completion of https://gitlab.com/gitlab-org/gitlab/-/work_items/452042 first) 3. **Identify the rendering gap** – determine exactly where the inventory UI reads scanner presence (CI job artifact types vs. `security_scans` rows) and what change is needed to also consider inferred types from SARIF scans. 4. **Design a solution** – options may include: - Changing inventory to query `security_scans` instead - Extending the existing `Security::Scan` status model to expose inferred coverage metadata to the inventory. ## Acceptance Criteria - [ ] The security inventory accurately reflects tool coverage for projects that upload SARIF reports directly, with no native GitLab scanner CI jobs present. - [ ] Inferred scan types (derived from finding identifiers) are surfaced in the same coverage UI as explicitly typed scans. ## Related - https://gitlab.com/gitlab-org/gitlab/-/work_items/452042+