Skip to content

Consolidate triage policies for vulnerability issues

Olivier Gonzalez requested to merge consolidate_vulnerability_policies into master

What does this MR do and why?

The bug::vulnerability issues have specific SLAs defined by the security department that differs from other bugs SLOs. As a result, we should have separate policies to prevent overlap and conflicts in setting labels and applying due date.

Additionally, some of the policies in place only apply to FedRAMP vulnerabilities. Per our Remediation SLAs we should apply a consistent policy to all ~bug::vulnerability issues, not only the FedRAMP ones.

Finally, considering that today both SLA::* and SLO::* labels are applied, I've kept this behavior. This also ensures that the status of vulnerability bugs is reported consistently in bugs metrics and on the Missed SLO Heatmap for instance.

After this MR is merged we should have the folling automation:

  1. Based on vulnerability SLAs, due date is set and labels SLO:* and SLA:* are applied to all ~bug:vulnerability issues, whether or not they are FedRAMP related.
  2. Bassed on regular bug SLOs, due date is set and labels SLO:* are applied to all bugs execpt ~bug:vulnerability issues.

Example of current incorrect behavior:

  • This issue has seen it's due date set to August 22nd by the Security bot and then to September 30st by the GitLab bot. Also, since this is not a FedRAMPVulnerability issue, no ~SLA:* labels have been applied to inform about past being a due security issue. The ~SLO:* labels applied where not following the correct timeframes expected for a vulnerability remediation.
  • This issue has been set wit SLABreached and then SLOMissed 30 days later.

Expected impact & dry-runs

These are strongly recommended to assist reviewers and reduce the time to merge your change.

See https://gitlab.com/gitlab-org/quality/triage-ops/-/tree/master/doc/scheduled#testing-policies-with-a-dry-run on how to perform dry-runs for new policies.

See https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/master/doc/reactive/best_practices.md#use-the-sandbox-to-test-new-processors on how to make sure a new processor can be tested.

Action items

Merge request reports