Sec Section

1. You are here:
2. Engineering
3. Development Department
4. Sec Section

On this page

• Teams and Handbook Pages
• Product Direction
• Performance Indicators
  • Dashboards
    • Cross-functional Backlog
    • Merged Merge Request Types
• Slack channels
• Staying Informed and Informing Team Members
• Planning in the Section
  • Process for planning section-wide initiatives
• Councils and Chapters
  • Architectural Council (Slack #s_secure-architectural-council)
    • Considerations when determining the approach
    • Capturing Resolved/Discovered Standards
      • Scope
    • Acceptance Criteria
    • Team Representatives
  • Frontend Chapter (Slack #secure-frontend-chapter)
    • Team Representatives
    • Page Performance
    • How to work with the Quality team
    • Frontend Responsibilities
    • Identifying potential breakages
    • Communicating changes that may break tests
  • Section Retrospectives
    • Key Dates
    • DRI Responsibilities

Teams and Handbook Pages

The following teams comprise the sub-department:

• Protect stage - handbook
  • Container Security group
• Secure stage - handbook
  • Composition Analysis group - handbook
  • Dynamic Analysis group - handbook
  • Vulnerability Research group - handbook
  • Threat Insights group - handbook
• Anti-Abuse stage - handbook

It is important to delineate who the EM and PM DRIs are for every functionality, especially where this may not be obvious. This is documented on a dedicated delineation page.

Product Direction

Product direction can be found on the Sec Section Product Direction handbook page.

Performance Indicators

• Sec Sub-department Performance Indicators
• Error Budgets as Performance Indicators for stage groups

Dashboards

Cross-functional Backlog

(Sisense↗) We also track our backlog of issues, including past due security and infradev issues, and total open SUS-impacting issues and bugs.

Merged Merge Request Types

(Sisense↗) MR Type labels help us report what we're working on to industry analysts in a way that's consistent across the engineering department. The dashboard below shows the trend of MR Types over time and a list of merged MRs.

Slack channels

• #sec-section - Sec Section discussions spanning the Protect, and Secure stages.
• #sec-growth-modelops-people-leaders - Engineering people leaders in Sec, Growth, and ModelOps.
• 🔒sec-growth-modelops-leadership-confidential - Private channel for engineering people leaders in Sec, Growth, and ModelOps.

Staying Informed and Informing Team Members

• Sec Week In Review Google Document - is an asynchronous weekly document of notables things happening in Sec. The document is inspired by the [Engineering Week In Review].(https://about.gitlab.com/handbook/engineering/#communication)
• Slack channels #s_secure, #s_protect, #g_anti-abuse are informative since they are all part of Sec Section.

Planning in the Section

In the vast majority of cases, work is scoped to individual groups within the section. However, there are times when the section needs to design and execute solutions as a coordinated Section or risk creating poor and non-cohesive user experiences.

These initiatives will be orchestrated through epics and issues. Initiatives with the following labels are deemed to fall in this category of work.

• ~section::sec and ~group::not owned; or
• all Sec groups

Process for planning section-wide initiatives

At least once per milestone, Senior Engineering Managers in the section will do the following:

• In partnership with Product Management, initiatives 6 months or older will be evaluated to determine if they're still relevant.
• New initiatives will be triaged, checking their requirements for understandability and completeness. Further, the group most impacted will be identified.
  • In situations where most impacted group is not clear, the Architectural Council will be engaged to help discern which group that might be.
• Group most impacted will be declared DRI for that initiative and are expected to:
  • Produce a high-level implementation plan that will scale for the whole problem.
  • Create implementation issues that are broken down by feature category.
    • The original high-level implementation plan will be included, or at least directly linked, in the created issues.
    • Original issue where implementation plan was debated and created will also be linked to the generated issues.
  • Distribute implementation issues to the relevant groups.

Generated issues will be worked through normal prioritization processes as they are distributed to individual groups.

Councils and Chapters

Architectural Council (Slack #s_secure-architectural-council)

Snippet to use in issues.

In order to help the Sec section come to resolution on defining approaches to section-wide issues, we have formed an Architectural Council. This group comprises tech leads (and SMEs to provide context) in order to keep the team small and nimble. The group is a non-authoritative, supportive group whose members provide representative insights from their respective teams.

• Tech leads will serve as the representative for their team
• An issue should be created to capture the discussion that covers:
  • What is the issue at hand and what is the preferred action
  • What are the potential solutions and their associated pros/cons
  • What approach was decided and why
  • 3-business day SLO
    • We need to know when to start the clock on these as some issues can exist for months before being brought to the council. In this case, we should define within the issue when the clock does start.
• There will be a DRI assigned to the issue that is being discussed
• The DRI will be decided by either who has to address the issue first or where the code change is occurring the most (in that order)
• The issue will be discussed and the DRI will be the ultimate decision-maker for the approach taken
• Issues will be tackled on a First-In-and-First-Out (FIFO) order. Attempts to minimize SLA overlap should be made to prevent scheduling conflicts between member’s time

Considerations when determining the approach

• Simplicity and elegance
• Portability and/or modularity
• Supportability
• Maintainability
• Scalability
• Extensibility
• Reliability
• Security
• Cost (will it impact .com for large customers)
• Performance (speed and accuracy)
• Consistency (Fit with existing code base)

Capturing Resolved/Discovered Standards

Common scenarios/architectural concepts will likely be resolved/discovered. These should be captured generically in an architectural guidelines page of the handbook and, if possible, codified into our processes/templates.

Scope

The table below captures characteristics (requirements?) of work that is in-scope, opt-in, or out-of-scope. All requirements must be met for each category.

Reason/Condition	In-Scope	Opt-in	Out-of-Scope
Does not involve architectural decisions			x
Is after-the-fact			x
Is not already covered by architecture guidelines/handbook	x	x
Has broad impact within #secure1	x
Is a new unit of work	x	x
Is strictly #secure or #protect	x	x
Could not come to an agreement (escalation)		?
Involves architecture decisions	x	x

Acceptance Criteria

GitLab’s Stance for Architectural issues: https://about.gitlab.com/handbook/engineering/architecture/

Team Representatives

Team	Representative
Composition Analysis	Fabien Catteau
Container Scanning	Alan (Maciej) Paruszewski
Dynamic Analysis	Cam Swords
Static Analysis	Lucas Charles
Threat Insights	Mehmet Emin Inac
Frontend	Savas Vedova
Vulnerability Research	Isaac Dawson, Julian Thome

Frontend Chapter (Slack #secure-frontend-chapter)

The Sec Section Frontend Chapter at GitLab is a federation of all Frontend Engineers and team members interested in frontend-related topics within the Sec Section.

The main purpose of the Frontend chapter is to connect Frontend Engineers within the Secure Group, share knowledge, exchange about common challenges and leverage their collaboration.

The chapter was founded when Secure transitioned to Fullstack Teams which resulted in some Engineers being the isolated experts within their team.

The members of the chapter exchange through the slack-channel, there is also a sync meeting twice a month on the Secure Group Calendar.

There is no strict rulebook of how chapter-members collaborate with each other. The chapter is about visibility of challenges that might be similar amongst the different teams within the secure-group and how we can benefit from this.

Team Representatives

Team	Representative
Composition Analysis	Fernando Arias
Static Analysis	Jannik Lehmann
Dynamic Analysis	Artur Fedorov
Dynamic Analysis	Dheeraj Joshi
Threat Insights	Daniel Tian
Threat Insights	Dave Pisek
Threat Insights	Paul Gascou-Vaillancourt
Threat Insights	Samantha Ming
Threat Insights	Savas Vedova

Page Performance

Our team monitors LCP (Largest Contentful Paint) to ensure performance is below our target (currently 2500ms).

LCP Dashboard for Secure owned pages

How to work with the Quality team

Frontend Responsibilities

1. Being able to identify what code changes would likely break E2E or System level tests and informing Quality.
2. Not to write E2E tests, but to catch potential failures and communicate gaps in coverage before landing to master.

Identifying potential breakages

1. Look to see if issue you are working on has existing test coverage. These are the tests likely to fail

2. If you are working around code that contains a selector like data-qa-selector="<name>", then there is likely to be an existing E2E test. Tests can be found by searching our E2E tests in Secure.

Communicating changes that may break tests

Ping the DRI for quality assigned to Secure. You can find the person on the team page. If they are unavailable, then #quality on slack or the triage DRI dependent on severity.

Section Retrospectives

In addition to our group retrospectives, we hold a Sec Section level retrospective each month. The goal of the section wide retrospective is to review topics that bubbled-up from our group/team retrospectives. Additionally, we identify themes that could be discussed synchronously. We use this doc to facilitate the section retrospective.

Key Dates

1. 26th of each month - Group async retrospective issues are generated. Groups should start contributing topics.
2. Week of the 17th - Groups hold their retrospectives. Team members bubble-up identified topics and follow-up items (outcomes) to the section retrospective document.
3. Week of the 22nd - Section wide retrospective sync. AMER/EMEA at 7:30am PT / 2:30pm UTC, APAC at 3:30pm PT / 10:30pm UTC.

DRI Responsibilities

The DRI for Section-wide retrospectives will be the Senior Engineering Manager. The SEM will find a volunteer if it is needed on specific milestones. The following tasks are executed each milestone:

1. Prior to the section sync, review bubble-up topics and identify up with 2-3 themes to support sync discussion topics.
2. Ask everyone through Slack to vote on which topics they would like to spend time discussing as a section.
3. Follow up with groups on any identified improvements.
4. Promote, promote, promote!