Design: Report notifications
Release notes
Problem to solve
There is an increasing need to signal the user to report level events, alerts, and actions they need to take. Today we are using an inline component that may soon fill-up and require a redesign. Further more, we only want to signal the user when their attention is required, which may vary depending on the severity of the notification we present. We should consider a component that can extend to cover all use cases today as well as future cases so we can ensure a stable and future-proof experience for both the user and ourselves.
Intended users
- Sam (Security Analyst)
- Anyone viewing, triaging, or exporting the vulnerability report.
User experience goal
Users will understand the state of the vulnerability report and be able to answer these question based on information provided to them:
- If the report is up-to-date and its contents are representative of what is in the default branch (if not, then why)
- What, if any material changes have been made to the report contents by the system (if so, what and where).
- What's available to them that isn't currently in use (scanners or AI feature not enabled, with links to enable)
Proposal
Explore a way to display the status of the vulnerability report to the user. Verify use cases that need to be supported for this capability.
Known use cases
- When Dependency scanning Jobs are using outdated vuln db - #347546 (closed) - #337296 (closed)
- When a security report is using an outdated schema - #335789 (closed)
- When a pipeline has failed with security jobs
- When 1 or more security scanners are not enabled
- When a report has not been updated for >30days
- When auto-fix MRs have been created
- SBOM last updated
- AI features available but not currently in use?
Errors such as the report failing to load should remain as page-level alerts, not notifications.
Scope
Consider how the vulnerability report status may roll up to different levels (project>group>instance).