The Secret Detection group was split from Static Analysis on 2024-03-05.
The Secret Detection group maintains the Secret Detection feature category for customer software repositories.
For software delivery, we generally follow a similar process to the one used by Static Analysis group.
We have recently experimented with a new refinement process when refining the issues for the Pre-receive SD beta/.com epic. This process draws a lot of inspiration from other sections/stages but also aligns with the current Secure Engineering Refinement.
Following a set of discussions and feedback of said process, we have decided to make the improved refinement process a part of our software delivery workflow.
The goal of the process is to:
The refinement process doesn’t concern itself with how issues are picked up to be refined. This is assumed to be done in an earlier process that triages issues from the backlog (whether via the MoSCoW process or a similar variant). Normally, before issues are refined, a planning issue is created to select which issues are picked up in an upcoming milestone to be refined and delivered. This could possibly be done in the Looking Forward section of the planning issue.
This workflow can summarized as follows:
Below is a list of steps followed during the refinement process.
The following checklist is to be copied either in the issue description or posted as a comment in the issue being refined. This is used to clarify the refinement and refinement review progress for all interested stakeholders.
**Please copy the list below into the issue you are refining, and check them as you deem appropriate.**
#### Refinement Progress
If a checkbox is not relevant for the issue, please remove or strikethrough it.
- [ ] This issue describes a problem to solve, or a task to complete, and it's confirmed.
- [ ] This issue describes a proposal or an implementation plan that outlines a way to solve the problem or complete the task.
- [ ] This issue requires assistance or support from other groups, and it's indicated in the issue description.
- [ ] This issue could affect application security or performance, and the concern is explained in the issue description.
- [ ] This issue is the smallest iteration possible and doesn't require further break down.
- [ ] This issue has weight set - according to [this list of possible values](/handbook/engineering/development/sec/secure/workflow/#possible-values) - and ~"needs weight" label is removed.
- [ ] This issue has a success criteria defined, and it is outlined in the issue description.
- [ ] This issue is labeled correctly.
- [ ] This issue is reviewed by another team member to confirm proposal/implementation plan and weight.
- [ ] Finally, add ~"workflow::ready for development" label to this issue and unassign yourself.
#### Refinment Review Guidelines
If you're assigned this issue to review its refinement, please follow the guidelines below.
1. Please validate the proposal or the implementation plan described in the issue.
1. Please validate the weight of the issue according to [this list of possible values](/handbook/engineering/development/sec/secure/workflow/#possible-values).
1. If in disagreement, please state your thoughts/reasoning and notify the engineer refining this issue.
1. If the disagreement can't be resolved, please bring this issue to the next team meeting for discussion.
Issues are assigned randomly to engineers using triage-ops bot. The process works like follows:
~"group::secret detection"~"workflow::planning breakdown"Opened~"group::secret detection"~"workflow::planning breakdown"None.next_milestone.~"worfklow::refinement"~"needs weight"~"worfklow::planning breakdown"Hi #{secret_detection_engineer}
As a preparation for the upcoming milestone #{milestone.succ}, you have been assigned this issue to refine.
The goal of the process is to:
- Clarify any outstanding questions or concerns.
- Add a proposal or an implementation plan.
- Determine if the issue is the smallest iteration possible, and break it down if not.
- Determine if the issue requires support from other teams.
- Assign a weight to the issue.
- Ensure the issue is labeled correctly.
- Ensure issue is marked as ready to be worked on.
Please check the [steps to follow](/handbook/engineering/development/sec/secure/secret-detection/#steps) and the [checklist](/handbook/engineering/development/sec/secure/secret-detection/#checklist) to use for keeping refinement progress transparent.
If you have any questions, don't hesitate to ask in `#g_secure_secret-detection` channel.
[Bot policy](https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/master/policies/groups/gitlab-org/secret-detection/assign-refinement.yml).
/assign #{secret_detection_engineer}
The process to add metrics to our projects is documented in our Metrics page.
The process for monitoring, responding to, and mitigating incidents is documented within our Secret Detection Runbooks page.
This page documents the process a member of the Secure: Secret Detection team should use to add metrics to capture product insights for the features we develop.
You should this guide to help you understand the 2 different types of metrics we can use, when to use each one, and give you a jumpstart in implementing them.
In general, the workflow for developing and adding metrics is:
This page lists runbooks used by the Secret Detection team for monitoring, mitigating and responding to an incident.
95b1758d)
