Inconsistent badge design vs design system badges makes for using gitlab-ui components difficult and any change we want to make will take longer and require more effort.
Security Badge
Gilab variant
Lack of color ramp / scale makes identifying criticality difficult and the lack a defined scale will cause issues in the future as we mature.
The current color documentation in pajamas does not meet our scale needs and should be adjusted or have an alternate for severity.
Pajamas documentation:
Blue indicates a current or active state. It communicates: management, progress, connectivity, or organization.
Green indicates success. It communicates: save, create, add, available, done, approved, or resolved.
Orange indicates ‘attention-required.’ It communicates: warning, pending, missing, or impeded progress.
Red indicates a problem. It communicates: critical states, destructive actions, errors, fails, removals, or declines.
Secure color usage:
Red: indicates a critical severity / new vulnerability in the MR / blacklisted license
Orange: indicates a high severity / dependency has a vulnerability
Blue: All severities in the history chart
Green: fixed vulnerability in the MR / approved license / no vulnerabilities associated with a dependency
Dark Gray: Unknown / Experimental / Undefined severity / New license
Light Gray: Low severity
Goals:
Solution uses a color scale but does not solely rely on color
Solution includes a text label
Solution is accessible
Solution does not conflict with our iconography system
Solution is simple and easily understandable
Solution considers size and scale and should drive for compactness if possible
Proposal:
Let's look at our color usage as a system that can grow to fit our needs as both devopssecure ~"devops::defend" mature. We should achieve this by using the current colors and design elements defined in the gitlab pattern-library and Pajamas so as not to create unnecessary components unless they are absolutely needed.