Sec Section

The Sec Section is composed of development teams working on Secure and Govern features of the GitLab DevOps Platform.
DevSecOpsPlanCodeBuildTestReleaseDeployOperateMonitorSecurityCompliance
Secure
Govern

Teams and Handbook Pages

The following teams comprise the sub-department:

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.

Project Setup

Keeping our projects organized is very important for productivity and maintainability.

In general, we want to keep as few projects in security-products as necessary.

security-products should only contain :

  • Source code for applications that will run as part of a customer install
  • Demos
  • Historical projects that are difficult to move.

secure and govern should have projects for:

  • End-to-end testing
  • Benchmarks / Stats
  • Tooling

There may be projects that should belong in secure or govern but for technical reasons are much easier to have in security-products. In those cases, we can locate the project in security-products if reasonable efforts were made to get the project in secure or govern but were unsuccessful.

Other settings

Due to https://gitlab.com/gitlab-org/gitlab/-/issues/220535, we may choose to leave the Issue tracker enabled in the new project. In these cases, please consider these to avoid abandoned issues:

  1. Make the tracker private.
  2. Add an issue template with instructions.
  3. Ensure there’s a triage process in place.

Performance Indicators

Dashboards

Slack channels

Calendars

We have two stage level calendars, Secure Stage Calendar and Govern Stage Calendar, where we host cross-group events such as:

  1. Monthly retrospective
  2. Coffee chats
  3. Staff sync

Each group also has a calendar for team-based discussions, such as the our weekly group syncs.

We encourage utilizing our available Google Groups instead of including individuals as attendees when possible. Along with ensuring the event is represented on individual’s calendars for visibility, new team members are automatically added to events (as well as removed when someone departs from a team).

Google Groups

Google groups were setup and are structured as:

  • sec-section
  • sec-govern
  • sec-secure
  • sec-govern-threat-insights
  • sec-govern-security-policies
  • sec-govern-compliance
  • sec-secure-static-analysis
  • sec-secure-dynamic-analysis
  • sec-secure-composition-analysis

The members of each google group consists of stable counterparts and the correct eng-dev-[sub-department]-[team] group of engineers. When stable counterparts change, or team members onboard/offboard the appropriate group should be updated.

Staying Informed and Informing Team Members

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.

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_sec-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
    • 2-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 #govern 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 CatteauFabien Catteau
Security Policies Sashi Kumar KumaresanSashi Kumar Kumaresan .
Dynamic Analysis Cam SwordsCam Swords
Static Analysis Lucas CharlesLucas Charles
Threat Insights BE Mehmet Emin InacMehmet Emin Inac
Threat Insights FE Savas VedovaSavas Vedova
Vulnerability Research Isaac DawsonIsaac Dawson , Julian ThomeJulian Thome
Compliance Huzaifa IftikharHuzaifa Iftikhar

There may be a need for more than one team member per group, and also for team members to rotate in and out of the council depending on other priorities. In these cases team members should discuss with their direct manager, and open an MR to update their membership and share in the #s_sec-architectural-council Slack channel.

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

Working with Customer Support

The Sec engineering teams do not provide support directly to customers. Instead engineers collaborate with our Customer Support Engineers via the process on the Sec Sub-department support project.

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 facilitate an async 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 and an issue created with this template to facilitate the section retrospective.

Key Dates

  1. The Monday after the monthly release - Group async retrospective issues are generated. Groups should start contributing topics.
  2. The week the milestone ends - Groups hold their retrospectives. Team members bubble-up identified topics and follow-up items (outcomes) to the section retrospective document.
  3. The week of the release - Section wide retrospective async review shared in the #sec-section Slack channel.

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 async section retrospective, review bubble-up topics and identify 2-3 themes to support async discussion topics.
  2. Ask everyone through Slack in #sec-section to review the section retrospective document and add comments.
  3. Share a summary of the async discussions in Slack in #sec-section.
  4. Follow up with groups on any identified improvements.
  5. Promote, promote, promote!

  1. Meaning that the proposed work requires knowledge or impacts multiple groups ↩︎


Govern Sub-department
The Govern sub-department teams are the engineering teams in the Govern Stage of the product. Vision To support GitLab’s product vision through alignment with the Govern stage product direction. Groups Anti-abuse Authentication Authorization Compliance Security Policies Threat Insights Priorities Group priorities are reviewed collaboratively with product counterparts and published on the Govern direction pages Anti-abuse Authentication Authorization Compliance Security Policies Threat Insights Sub-department development people leaders Name Role Phil Calder Director of Engineering, Govern Adil Farrukh Engineering Manager, Govern:Authentication Jay Swain Engineering Manager, Govern:Authorization and Anti-abuse Alan (Maciej) Paruszewski Engineering Manager, Govern:Security Policies Neil McCorrison Engineering Manager, Govern:Threat Insights Nathan Rosandich Engineering Manager, Govern:Compliance To contact Govern sub-department development people leaders leaders use the following aliases:
Secure / Govern sub-department delineation
Definition of what engineering group is responsible for features in the Secure and Govern stages of the GitLab product
Secure Sub-Department
The Secure engineering sub-department is responsible for the Secure Stage of the product. Vision To provide content and tools to support the best possible assessment at the earliest possible moment. Following our single application paradigm, we integrate and build scanning tools to supply security and compliance assessment data to the main GitLab application where we develop our vulnerability management system and other features. While it might be technically feasible, we do not aim at building standalone products that provide this data independently from the GitLab application.