If you have a need or idea for security-relevant projects at GitLab that require automation, please add the
secauto|workflow::new label directly to your issue as detailed in the
Labels section. On the other hand, to bring an issue or artifact to our attention without expectation of a deliverable, please add the
secauto|interest label to it. We review and prioritize issues with those labels during our Weekly Meeting, which anyone can attend. In case you want to engage us directly, please reach out on Slack in by mentioning
@sec-automation-team in the #security-department channel. As usual, you can also tag the SecAuto team within GitLab by using
The SecAuto team continually works on improving the way in which we work and deliver value to the company. This sections describes our workflow and how we use GitLab to manage our team and projects.
Our workflow is a simplified version of GitLab's Engineering Workflow although we might increasingly adopt conventions and approaches referred to in there, our process will most likely perpetually deviate with bias towards simplicity.
The SecAuto team's weekly meeting is a 50-minute meeting that can also be found on the Security Department Team Meetings calendar.
The best way to get an overview of what the SecAuto team is working on at any time is to use our epics list and issue boards.
SecAuto's OKRs are team-centric and tackled as a team effort, only issues are assigned directly to DRIs. Epics tracking SecAuto OKRs, we follow the
SecAuto - <OKR Name> naming convention so they are easily discoverable despite absence of a
secauto|* label and regardless of the hierarchy level at which they are created. Finally, OKR-epics must be labeled
Security Management::Security Automation Team and be ideally created at the https://gitlab.com/groups/gitlab-com/gl-security/engineering-and-research/automation-team/-/epics level. Since epics bubble up the hierarchy, these will still be visible at https://gitlab.com/groups/gitlab-com/gl-security/-/epics/.
We have three issue boards, the Intake Board for use during prioritization meetings, the In-Progress Board to keep track of progress on issues and the Management Board, which is meant to give the SecAuto's team manager and the team an overview of OKRs and other matters exclusive to the team's management and operation.
secauto|* labels currently being used by the SecAuto team can be found in the issue label listing for gitlab-com.
Any issues and associated work concerning the SecAuto team that cannot be clearly assigned to a single, existing SecAuto product and its associated tracker.
Issues that are exclusive to a single product or project and for which a repository exists, these shall be labeled with the appropriate
secauto| labels (task, meta, priority, etc). If a repository doesn't exist but an issue is relevant only to a single project, component or product, a repository should be created.
Everyone in the team is responsible guaranteeing consistency in workflow and labeling. We're a small team and the more organized we are the better we'll be able to collaborate and communicate our results. New issues in the Main SecAuto tracker will be collectively reviewed and labeled before or during the weekly SecAuto meeting. New issues in project-specific trackers will be reviewed and properly labeled by each project's DRI(s) upon creation.
Most of the work SecAuto does is externally initiated. Opportunities for contributing originate from the day-to-day operations of teams in the Security Department and accross GitLab. These usually arise in Slack conversations, as issues in the GitLab groups
gitlab-com, etc. SecAuto's processes rely heavily on labels, they inform both customers and the team about the status of issues and other artifacts as detailed in the
SecAuto's intake process is simple, as detailed in the
Once SecAuto creates a task or is made aware of one relevant to the team, the team assigns the label
secauto|workflow::new. All tasks labeled
secauto|workflow::neware considered part of the SecAuto backlog and must be triaged.
After this has happened, the team will triage the issue, as is done with any issue labeled
Alternatively, the SecAuto team can be made aware of an issue where their awareness, contribution or involvement may be desired by applying the
secauto|interest label on an artifact.
secauto|interestcan be used to mark issues and other artifacts across the company's namespaces that might be of interest to secauto. An issue detailing new guidelines and expectations regarding cost management in GCP environments would be one such example.
Tasks that are considered too large for a single sprint will be upgraded to epics in our OKR Epics List. From there, additional sub-tasks will be created to define iterative sprint-sized or less chunks of work in an attempt to accomplish the epic.
secauto|task::management is meant for all issues and conversations related to the strategy, tactics and management aspects of the Security Automation team and its projects.
secauto|interest can be used to mark issues and other artifacts across the company's namespaces that might be of interest to secauto. An issue detailing new guidelines and expectations regarding cost management in GCP environments would be one such example.
Tasks, issues and other artifacts on which SecAuto is expected to deliver can be in the
Once SecAuto or another team creates a task for the team to triage, the label
secauto|workflow::new must be applied to it. All tasks labeled
secauto|workflow::new are considered part of the SecAuto backlog and must be triaged.
The next step is for tasks to be triaged and thus be labeled
secauto|workflow::ready to be worked on by the team. A task will only be labeled
secauto|workflow::ready once the following holds:
secauto|customerlabel identifiying the customers profiting from the deliverables.
Once a task is labeled
secauto|workflow::ready, work on it can begin, hence labeling it
secauto|workflow::in-progress, and eventually be concluded
Such is the ideal, more common path for a task to take.
secauto|workflow::cancelled labels can be applied at any time in the life-cycle of task and are mostly used to track how often we are blocked, how many times we triage, prioritize and work on something only for us or our customers to halt the task, etc.
Every task must have at least one
secauto|customer label, these labels signal what teams are requesting and will profit from the delivery on a given task. Furthermore, it can be assumed that the author of the issue, the members of their team participating in the issue, and if needed their manager, can act as stable counterparts during the time period the SecAuto team works on said task.
If there are multiple customer teams, each team should have at least one stable counterpart explicitly listed on the issue.
All work performed by SecAuto falls within the following areas:
secauto|task::incidentrelates to managerial activities affecting the SecAuto team
secauto|task::incidentreactively mitigates a critical malfunction on product by SecAuto
secauto|task::bugreactively addresses a non-critical, undesired condition in a product by SecAuto
secauto|task::improvementproactively delivers a non-critical related to a product by SecAuto
secauto|task::maintenanceproactively delivers an operative related to a product by SecAuto
secauto|task::infrastructureproactively delivers value related to a non-product, non-user-facing infrastructure component used by SecAuto, this includes scripts for cleanup, GCP infrastructure.
secauto|task::analysisdelivers information after performing evaluations, analyses, investigations, brainstorming and the like.
secauto|task::documentationformalizes and documents the results of other task types whenever this is required.
Infrastructure, maintenance and improvement labels exist since the nature of the work is different. As SecAuto, we work with more than features, in our day-to-day we act as developers, architects, consultants, at times even SREs. These labels help capture the nature of that work for strategic and tactical purposes such as metrics gathering.
secauto|priority::high are our priority markers. We use this to determine what needs to be done and when.
We assign priority labels based on a simplified version of the RICE framework in use by the Engineering Department and define Impact and Effort as follows:
|Low||a deliverable will somewhat improve the ability of the customer to act efficiently and effectively|
|Moderate||a deliverable will improve the ability of the customer to act efficiently and effectively|
|High||a deliverable will considerably improve the ability of the customer to act efficiently and effectively|
|Low||producing a deliverable will take one SecAuto team member less than a week|
|Moderate||producing a deliverable will take one SecAuto team member less than a month|
|High||producing a deliverable will take one SecAuto team member less than a quarter|
Taking this into consideration, we calculate priority as follows:
These priority calculations assume a good understading of the customers needs, also known as confidence. In cases where a task is not clearly defined or its purpose unclear, a
secauto|task::investigation issue should be created instead.
secauto|needsReviewCustomer must be looked at by the respective party mentioned in the label in order for work to proceed. For example, the creation of a new, expensive GCP environment should be labeled
secauto|needsReviewManager anytime a manager's input is needed. Furthermore, work potentially leading to down-time on a product used by a SecAuto customer should be labeled
secauto|needsReviewCustomer. Finally, for non-code-managed changes where approval cannot happen in an MR or where peer-review is desired,
secauto|needsReviewTeam should be used.
The planning activities in the meetings should be limited to 15 minutes.
This process relies on a rotating role of "SecAuto triager" to ensure that issues that do not correspond to project with an existing DRI are triaged asynchronously (see below).
Completing the following asynchronous tasks prior to the meeting will keep the synchronous meeting on schedule:
|The triager and DRIs for each SecAuto project should review ~"secauto||workflow::new" issues for issues relevant to their projects and:|
secauto|customerlabels identifying the customers requesting the deliverables.
|If an issue seems like it needs to be addressed immediately or within the next week, they will label it ~"secauto||priority::high". If so, they are expected to engage the most-likely DRI or raise with the team to find a DRI that will work on the task. This should be done immediately or at the upcoming SecAuto Team Meeting the latest. For other issues, these will remain in the ~"secauto||workflow::new" stage as a backlog items. The triager should note this in a comment to provide feedback for the requester on expected time frames.|
|For issues labeled ~"secauto||workflow::new" and ~"secauto||priority::high", the DRI should make an initial attempt at scoping the work for a weekly milestone. They or the DRI should, if this can be done without the teams consideration, break down the task in smaller issues prior to the meeting that can be scheduled and assigned for delivery during the next and following weeks.|
The "SecAuto triager" is responsible for facilitating the refinement portion of the meeting:
secauto|workflow:blockedas well as raise blockers for any unfinished work.
secauto|needsReviewCustomerare addressed and assigned or re-assigned for during the meeting.
secauto|workflow:newissues with high, moderate and low priority, in that order, are discussed and assigned to team members for them to triage them and bring them to a
|GSuite Group Members Reporter|
|Suricata Runner Metrics|