Vulnerability Management Team
This is a Controlled Document
In line with GitLab’s regulatory obligations, changes to controlled documents must be approved or merged by a code owner. All contributions are welcome and encouraged.This handbook page describes how the Vulnerability Management team works on a day to day, quarter to quarter basis. We recognise this process is iterative and requires regular introspection to ensure we are always improving and not stagnating in our approach.
Planning
Vulnerability Management follows GitLab product milestones Prior to a new milestone beginning, planning is performed to define the expected outcome of the next milestone, and the work required to accomplish it. We review our ability to deliver this work within the milestone and commit/adjust to issues to fit. Additionally, any unscoped and unsized work is qualified and labelled.
How do we breakdown quarterly items into appropriately sized work items (issues)?
Ideally, sizing and planning labels are added as new issues are created. We aim to define work as small actionable issues to assist with fitting work into milestones and being able to parallelize work. Where work has not been sized and scoped, we do this sizing and scoping work during milestone planning for items we want to schedule for that milestone.
Refinement & Sizing
Work is sized based on the estimated percentage of a milestone required to complete the task as it is defined. Work is defined as clearly as possible to try and minimize the impact of misunderstood requirements leading to scope creep. Issue sizing is performed on a defined scale of issue weights and sizing labels.
These steps are used as guidelines:
- Check the issue for sufficiently detailed requirements needed to accomplish the desired outcome.
- If the requirements or outputs are not clear enough to confidently assess whether the issue is actionable and how much of the milestone it would consume, it needs to be refined.
- Add appropriate weighting & labels to the issue based on the estimated time to investigate, research and deliver the documented outputs.
- Request help/assistance from other parties when the issue requires cross team collaboration during planning if possible.
Issue Weighting
This is the scale used to size issues for scheduling. Note, the estimated durations are referring to overall effort, not scheduling duration. For example, if a large task can have several small tasks created and parallelized, it may be completed in less than 4+ weeks of scheduled time, but still be appropriately sized as a large work item.
| Weight | Size Label | Description | Estimated effort |
|---|---|---|---|
| 1 | ~“vuln-mgmt::Trivial” | Simple and quick changes where the work required is already understood. | < 1 week |
| 2 | ~“vuln-mgmt::Small” | Straight forward changes, no underlying dependencies needed. | 1 week |
| 3 | ~“vuln-mgmt::Medium” | Well understood changes with a few dependencies. Few surprises can be expected. | 2 weeks |
| 5 | ~“vuln-mgmt::Large” | A task that will require some investigation and research. | 3-4 weeks |
| 8 | ~“vuln-mgmt::X-Large” | A very large task that will require significant investigation and research, and multiple team members to deliver during a single milestone. May be a candidate for further refinement and having child issues created. | 2+ milestones |
| 13 | ~“vuln-mgmt::Break Down” | Please break the work down further, This would be a quarterly initiative or larger | N/A, requires further refinement |
Additional Labels Used
In addition to the sizing labels detailed in the previous section, the following labels are used in prioritization and planning.
| Label | Purpose | Scoped |
|---|---|---|
| ~“vuln-mgmt-BAU” | This issue represents work which is part of regular or BAU (“business as usual”) activities, which do not require explicit planning | No |
| ~“vulnerability-management-tooling::*” | Scoped label indicates which tool or automation this issue relates to. To be used for tooling owned by Vulnerability Management | Yes |
4e6ac4e3)
