Use 180-day SLO for sev4 vulnerability bot pings
Context
Triage ops makes automatic bot comments on security bugvulnerability issues based on to warn team members when we get close to breaching a remediation SLO. https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/master/policies/groups/gitlab-org/hygiene/comment-vulnerability-issue-slo.yml
We use severity to determine Remediation SLAs for these issues. The Remediation SLA for severity4 security bugvulnerability issues is 180 days.
Problem
GitLab bot appears to be calculating SLO breach date for severity4 vulnerabilities to be 120 days after issue creation instead of 180 days after issue creation.
For example, this ~"severity::4" issue was opened on 2023-09-12
. The bot is commenting that the SLO breach date is 2024-01-10
(120 days after issue was opened). The SLA for severity4 vulnerabilities is 180 days, and 180 days from 2023-09-12
is actually 2024-03-10
, not 2024-01-10
.
Why is this a problem?
Developers are getting pinged too early about approaching SLO breach, when they actually have an additional 60 days to remediate the vulnerabilities
Proposal
Change the automation to use 180 day remediation SLO instead of 120 day remediation SLO for severity4 security bugvulnerability issues.