Workflow for escalation engine
This issue is for discussing the escalation engine workflow (see #383).
Escalation Engine Workflow
The escalation engine will consider
security issues (that are not labeled as
test) under a given GitLab group/project and:
- Stage 1: Ensure that the issue is triaged.
- Stage 2: Ensure that the issue is scheduled.
- Stage 3: Escalate if remediation goals are missed.
Stage 1: Ensure that the issue is triaged
security issue has no
Pxlabel: add a
group::label: add a
- Add a triage label (i.e.
- Send daily Slack notifications (i.e. to
#sec-appsec) if there are issues with a triage label.
The escalation engine should remove the above labels from issues that are triaged.
Stage 2: Ensure that the issue is scheduled
security issue (S1/S2) is triaged, not overdue (see below), but has no milestone with dates:
- Tag the group PM (according to stages.yml) in a comment asking for a milestone with dates.
- Add a
If the issue does not receive a milestone within 7 business days, tag the group PM again.
The escalation engine should remove the above label from issues that are scheduled.
security issues has an active milestone, but no assignee:
- Assign the group PM (according to stages.yml).
- Add a comment asking for a
Stage 3: Escalate if remediation goals are missed
security issue is triaged, but overdue (see below):
- Add a
- Add an
ESCALATED:prefix to the issue title.
- Tag the group PM (according to stages.yml) in a comment asking for a new milestone.
- Send a Slack message to the group PM.
If the issue does not receive a new milestone within 1/3/7 business days (for S1/S2/S3), tag the PM's manager as well.
The escalation engine should remove the above label and title prefix from issues that have been closed.
An issue is overdue if it has missed the latest of the following deadlines, plus a configurable margin:
Remediation goal counting from the date the
Sxlabel was added
- Issue due date
- Milestone due date
Escalation Engine Labels
The escalation engine adds and removes labels automatically, no manual changes should be necessary.
||Added in stage 1 until a
||Added in stage 1 until both
||Added to AppSec-owned issues in stage 1 until triaged.|
||Added in stage 2 until a milestone with dates is set.|
||Added in stage 3 on escalation until the issue is closed.|
- Prototype: https://gitlab.com/gitlab-com/gl-security/automation/escalator
- Product stages, groups, and categories in the handbook
- group:: labels