Sec Section

The Sec Section is composed of development teams working on Secure and Software Supply Chain Security features of the GitLab DevOps Platform.

Secure

Govern

Teams and Handbook Pages

The following teams comprise the sub-department:

Software Supply Chain Security stage - handbook
- Anti-abuse group - handbook
- Authentication group - handbook
- Authorization group - handbook
- Compliance group - handbook
- Security Policies group - handbook
- Threat Insights group - handbook
Secure stage - handbook
- Composition Analysis group - handbook
- Dynamic Analysis group - handbook
- Static Analysis group - handbook
- Secret Detection group - handbook
- Vulnerability Research group - handbook
- API Security - 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.

Project Setup

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

To setup a new project we follow the company-wide Engineering guidelines.
Sec projects should be organized into one of

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 software-supply-chain-security should have projects for:

End-to-end testing
Benchmarks / Stats
Tooling

There may be projects that should belong in secure or software-supply-chain-security 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 software-supply-chain-security but were unsuccessful.

Recommended settings

When creating a new project, all settings should be left to the default options, except for the following which are specific to the secure stage:

Add a CODEOWNERS file to the project, for example:
```
[Maintainers]
* @gitlab-org/maintainers/container-scanning

^[Reviewers]
* @gitlab-org/secure/static-analysis
```
We recommend creating a dedicated group of maintainers for use in the CODEOWNERS file.
Disable the project issue tracker.
- Settings -> General -> Visibility, project features, permissions -> Issues
  - Disabled
Issues should be created in the groups/gitlab-org issue tracker instead. See step 3. below to configure this.

Using a single, centralized issue tracker over per-project issue trackers has the following advantages:
- It improves the visibility of issues and aligns with our value of transparency.
  
  For example, it’s very easy for community members to filter the issues in the groups/gitlab-org tracker to discover GitLab issues seeking wider community contributions.
- It leverages existing tools and infrastructure, such as having triage-ops and other bots executed against issues, without any additional configuration.
- It provides a more consistent experience, since all labels and issue templates will be the same.
- It’s easier to write automated scripts, such as using the Security triage automation tool to create/modify vulnerabilities.
- There are some issues that apply to multiple projects. If each project has their own issue tracker, we’d need to figure out which issue tracker should “own” an issue that applies to multiple projects.
Having said that, there are currently some limitations related to using a single, centralized issue tracker, for example resolving threads in new issues doesn’t work.

Until this issue has been resolved, 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.
Configure a custom issue tracker
- Settings -> Integrations -> Custom issue tracker -> Configure
  - Enable integration
    - Active
  - Project URL
    - https://gitlab.com/gitlab-org/gitlab/issues
  - Issue URL
    - https://gitlab.com/gitlab-org/gitlab/issues/:id
  - New issue URL
    - https://gitlab.com/gitlab-org/gitlab/issues/new

Configure the following project features and permissions:

Settings -> General -> Visibility, project features, permissions -> Additional options -> Users can request access
- Allowed to merge
  - Maintainers
- Allowed to push and merge
  - No one
- Allowed to force push
  - Disabled
- Code owner approval
  - Enabled
Settings -> Repository -> Protected branches
- Allowed to merge
  - Maintainers
- Allowed to push and merge
  - No one
- Allowed to force push
  - Disabled
- Code owner approval
  - Enabled
Settings -> Repository -> Protected tags
- Tag
  - v*
- Allowed to create
  - Maintainers

Settings -> Merge Requests

Squash commits when merging
- Require
Approval settings
- Prevent approval by author
- Prevent editing approval rules in merge requests
- Remove approvals by Code Owners if their files changed
Merge request approvals -> Approval rules
- Approvers
  - All eligible users
- Target branch
  - All branches
- Approvals required
  - 1
Merge checks
- All threads must be resolved
- Pipelines must succeed

Merge commit message template

Merge branch '%{source_branch}' into '%{target_branch}'

%{title}

%{issues}

See merge request %{url}

Merged-by: %{merged_by}
%{approved_by}
%{reviewed_by}
%{co_authored_by}

Default description template for merge requests

## What does this MR do?

<!--
Describe in detail what your merge request does, why it does that, etc.

Please also keep this description up-to-date with any discussion that takes
place so that reviewers can understand your intent. This is especially
important if they didn't participate in the discussion.

Make sure to remove this comment when you are done.
-->

## What are the relevant issue numbers?

## Does this MR meet the acceptance criteria?

- [ ] Changelog entry added
- [ ] [Documentation created/updated for GitLab EE](https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html), if necessary
- [ ] Documentation created/updated for this project, if necessary
- [ ] Documentation reviewed by technical writer *or* follow-up review issue [created](https://gitlab.com/gitlab-org/gitlab-ee/issues/new?issuable_template=Doc%20Review)
- [ ] [Tests added for this feature/bug](https://docs.gitlab.com/ee/development/testing_guide/index.html)
- [ ] Job definition updated, if necessary
  - [ ] [Auto-DevOps template](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/lib/gitlab/ci/templates)
  - [ ] [Job definition example](https://docs.gitlab.com/ee/ci/examples/sast.html)
  - [ ] [CI Templates](https://gitlab.com/gitlab-org/security-products/ci-templates/tree/master/includes)
- [ ] Ensure the report version [matches the equivalent schema version](https://gitlab.com/gitlab-org/security-products/security-report-schemas/-/blob/master/CHANGELOG.md)
- [ ] Conforms to the [code review guidelines](https://docs.gitlab.com/ee/development/code_review.html)
- [ ] Conforms to the [Go guidelines](https://docs.gitlab.com/ee/development/go_guide/index.html)
- [ ] Security reports checked/validated by reviewer

/label ~"devops::secure" ~"Category:" ~"group::" ~"backend"

When configuring projects that are not part of the secure stage, please see the GitLab Projects Baseline Requirements for more details.

Performance Indicators

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

Dashboards

Slack channels

#sec-section - Sec Section discussions spanning the Software Supply Chain Security and Secure stages.
#sec-growth-datascience-people-leaders - Engineering people leaders in Sec, Growth, and ModelOps.
🔒sec-growth-datascience-leadership-confidential - Private channel for engineering people leaders in Sec, Growth, and ModelOps.

Calendars

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

Monthly retrospective
Coffee chats
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 follow the convention [section]-[stage]-[group], separating multi-word names with _ and are structured as the following:

sec-section
sec-software_supply_chain_security
sec-security_risk_management
sec-application_security_testing
sec-security_risk_management-security_insights
sec-security_risk_management-security_policies
sec-security_risk_management-security_platform_management
sec-security_risk_management-security_infrastructure
sec-application_security_testing-static_analysis
sec-application_security_testing-secret_detection
sec-application_security_testing-dynamic_analysis
sec-application_security_testing-composition_analysis
sec-software_supply_chain_security-authentication
sec-software_supply_chain_security-authorization
sec-software_supply_chain_security-compliance
sec-software_supply_chain_security-pipeline_security
vulnerability-research

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

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.
Slack channels #s_secure and #s_software-supply-chain-security 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.

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, technical leadership via #sec-section 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.

Page Performance

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

LCP Dashboard for Secure owned pages

Working with Product Design

To streamline our workflow and ensure efficient collaboration between the Engineering and Product Design teams, we have established the following guidelines for UX involvement in merge request (MR) reviews:

Merge Request UX Review Requirement:

A UX review is required only for work that has been explicitly designed by a Product Designer and should be reviewed by that Product Designer.
MRs that do not involve work explicitly designed by a Product Designer can be labeled as UX Tech Debt and merged without a UX review.

Handling High Priority UX Reviews:

If a high-priority task arises that requires a UX review but was not planned during the milestone planning process, it should be discussed with the Product Design Manager for Sec.
To accommodate this unexpected work, another task from the original milestone plan will need to be deprioritized or dropped.

Exceptions:

These new guidelines do not apply to the Authentication, Authorization, and Pipeline Security groups, which will continue to operate under their current processes.

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.

How to work with the Quality team

Frontend Responsibilities

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

Identifying potential breakages

Look to see if issue you are working on has existing test coverage. These are the tests likely to fail
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

The Monday after the monthly release - Group async retrospective issues are generated. Groups should start contributing topics.
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.
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:

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

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.

Security Risk Management Section

The Security Risk Management Section is composed of development teams working to enable appsec and development teams to efficiently release secure modern applications while maintaining rapid delivery and reducing risk across the software development lifecycle. Support the needs and leverage the capabilities of the entire GitLab security and compliance portfolio to accomplish this end.

Software Supply Chain Security Sub-department

The Software Supply Chain Security sub-department teams are the engineering teams in the Software Supply Chain Security Stage of the product.

Vision

To support GitLab’s product vision through alignment with the Software Supply Chain Security stage product direction.

Groups

Priorities

Group priorities are reviewed collaboratively with product counterparts and published on the Software Supply Chain Security direction pages

Product Documentation Links

All Team Members

Authentication

Name	Role
Adil Farrukh	Engineering Manager, Software Supply Chain Security:Authentication
Andrew Evans	Senior Backend Engineer, Software Supply Chain Security:Authentication
Bogdan Denkovych	Senior Backend Engineer, Software Supply Chain Security:Authentication
Drew Blessing	Senior Backend Engineer, Software Supply Chain Security:Authentication
Eduardo Sanz-Garcia	Senior Frontend Engineer, Software Supply Chain Security:Authentication
Hakeem Abdul-Razak	Associate Backend Engineer, Software Supply Chain Security:Authentication
Imre Farkas	Staff Backend Engineer, Software Supply Chain Security:Authentication
Smriti Garg	Senior Backend Engineer, Software Supply Chain Security:Authentication
Aboobacker MK	Senior Backend Engineer, Software Supply Chain Security:Authentication

Authorization and Anti-abuse

Name	Role
Jay Swain	Engineering Manager, Software Supply Chain Security:Authorization
Ayush Billore	Backend Engineer, Software Supply Chain Security:Authorization
Alex Buijs	Senior Fullstack Engineer, Software Supply Chain Security:Authorization
Daniel Tian	Senior Frontend Engineer, Software Supply Chain Security:Authorization
Eugie Limpin	Senior Fullstack Engineer, Software Supply Chain Security:Authorization
Hinam Mehra	Fullstack Engineer, Software Supply Chain Security:Authorization
Ian Anderson	Staff Backend Engineer, Software Supply Chain Security:Authorization
Jarka Košanová	Staff Backend Engineer, Software Supply Chain Security:Authorization
Mo Khan	Senior Backend Engineer, Software Supply Chain Security:Authorization

Compliance

Name	Role
Nathan Rosandich	Engineering Manager, Software Supply Chain Security:Compliance
Andrew Jung	Backend Engineer, Software Supply Chain Security:Compliance
Harsimar Sandhu	Senior Backend Engineer, Software Supply Chain Security:Compliance
Hitesh Raghuvanshi	Senior Backend Engineer, Software Supply Chain Security:Compliance
Huzaifa Iftikhar	Senior Backend Engineer, Software Supply Chain Security:Compliance
Illya Klymov	Staff Frontend Engineer, Software Supply Chain Security:Compliance
Nataliia Radina	Frontend Engineer, Software Supply Chain Security:Compliance
Sam Figueroa	Fullstack Engineer, Software Supply Chain Security:Compliance