Improve the enabled/disabled status of security analyzers throughout the system
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
We currently have multiple ways to check on the status of security analyzers: security configuration, security inventory, APIs that report on analyzer status, compliance framework reports on analyzers. And, these methods don't always agree on the state of an analyzer. Furthermore, they don't take security policies into account.
Beyond those methods not agreeing on the state of analyzers, they also don't necessarily share the same definition for what it means for an analyzer to be enabled. For example, one method of reporting may just care what the last status of an analyzer is, and report on that, where another method of reporting may just care if a report has succeeded in the past 24 hours.
We first need to establish common definitions for enablement, and then we can work to implement them and standardize on them.
Problem Statement
Different parts of GitLab use inconsistent methods to determine if security analyzers are "enabled":
- Security configuration page
- Security inventory
- APIs that report analyzer status
- Compliance framework reports
- Security policies are not consistently considered
Impact
- Confusing user experience with conflicting status information
- Inconsistent reporting across different GitLab features
- Difficulty in understanding actual security posture
Proposed Solution
- Define standardized criteria for what constitutes an "enabled" security analyzer
- Implement consistent status checking across all GitLab features
- Include security policies in status determination
- Establish clear time windows for determining analyzer activity/enablement
Related Issues
This issue stems from observations in #350307 (closed) where customers reported inconsistencies in security analyzer status reporting across different parts of the GitLab interface.
Description above was generated using AI