@@ -60,7 +60,7 @@ For details on our team-specific workflows, including backlog management, refine
## Communication
-**Slack**: Ask in [`#security_help`](https://gitlab.enterprise.slack.com/archives/C094L6F5D2A) on Slack and @ mention the `@product-security-engineering` handle
-**Slack**: Ask in [`#security_help`](https://gitlab.enterprise.slack.com/archives/C094L6F5D2A)or [`#security-capabilities-engineering`](https://gitlab.enterprise.slack.com/archives/C0AEU6LHQ7R)on Slack and @ mention the `@product-security-engineering` handle
-**Issues**: Submit to the [ProdSecEng team repository](https://gitlab.com/gitlab-com/gl-security/product-security/product-security-engineering/product-security-engineering-team/-/issues/new)
-**Emergencies**: Page the Security Incident Response Team using `/security` in any Slack channel
@@ -125,4 +125,4 @@ Our team is a mix of software and security engineers. Our plans for internal tea
## Review and Updates
This charter is reviewed quarterly. Next scheduled review: May 1, 2026.
This charter is reviewed quarterly. Next scheduled review: August 1, 2026.
@@ -4,7 +4,7 @@ title: "Rotate Service Account Personal Access Tokens (PATs)"
## Rotate Service Account Personal Access Tokens (PATs) Runbook
This runbook is an approach to rotating a GitLab Service Accounts Personal Access Tokens (PATs). From here on out we will refer to Personal Access Tokens as PATS and singular use of Personal Access Token as PAT.
This runbook is an approach to rotating a GitLab Service Accounts Personal Access Tokens (PATs). They can be configured as a legacy PAT (which uses broader scopes) or a fine-grained PAT (which scopes to specific boundaries and resources). From here on out we will refer to Personal Access Tokens as PATS and singular use of Personal Access Token as PAT.
### 1. Why is this important?
@@ -26,40 +26,46 @@ This runbook is an approach to rotating a GitLab Service Accounts Personal Acces
### 3. Steps to fix
- Make sure you are logged out of your personal account on GitLab.com.
- Using the Service Accounts credentials in 1Password, login in to GitLab.com with them.
- Use the `one-time password` parameter in 1Password for the MFA OTP.
- You should land on the Service Account's Project page like below:
1. Before rotating, check whether this token is a legacy PAT or a fine-grained PAT.
1. Make sure you are logged out of your personal account on GitLab.com.
1. Using the Service Accounts credentials in 1Password, login in to GitLab.com with them.
1. Use the `one-time password` parameter in 1Password for the MFA OTP.
1. You should land on the Service Account's Project page like below:
- Click on `Access tokens` in the `User settings` then click the `Add new token` button:
1. Click on `Access tokens` in the `User settings`:
-**If the existing token is a fine-grained PAT and you are not changing its boundaries or permissions:** next to the active token, select the vertical ellipsis (⋮) → **Rotate**. GitLab issues a new token with the same configuration, immediately deactivates the old one, and retains both for audit. Skip to step 12.
-**Otherwise** (legacy PAT, or you need to change a gPAT's scope): click the `Add new token` button and continue with step 8.
- Add the `Token name` that matches the previous token that had expired, in this case it is `GitLab Security Service - Architecture - Inventory`.
- Add a `Description` of what the token is used for.
- For `Expiration Date` set it for 365 days in the future (the maximum expiration). If you do not set it, it is default to expire in 30 days.
- Click the `Select scopes` permission level that best matches what access the Service account needs (In this case it is API only), like in the image below:
1. Add the `Token name` that matches the previous token that had expired, in this case it is `GitLab Security Service - Architecture - Inventory`. **For a fine-grained PAT**, select "Fine-grained token" from the Generate token dropdown.
1. Add a `Description` of what the token is used for.
1. For `Expiration Date` set it for 365 days in the future (the maximum expiration). If you do not set it, it is default to expire in 30 days for legacy PATs (gPATs default to 365).
1. Configure access:
-**For a legacy PAT:** click the `Select scopes` permission level that best matches what access the Service account needs (in this case it is API only), like in the image below:
- Before you click `Create Token` make sure to scroll down the page and `Revoke` the old token, as shown in the image below:
- **For a fine-grained PAT:** select the **Boundary** (Group, Project, or User; pick the most restrictive that still lets the automation work) and then in the right panel select the minimum **permission** per resource.
1. Before you click `Create Token` make sure to scroll down the page and `Revoke` the old token, as shown in the image below. Skip if you used the in-place Rotate flow in step 7. GitLab already deactivated the old token.
- Then click the `Create token` button and review the confirmation that the new token is in the PAT list on `Personal access tokens` page.
1. Then click the `Create token` button and review the confirmation that the new token is in the PAT list on `Personal access tokens` page.
### 4. Steps to test
- Logout of the Service Account and back in to an Account that has permissions to re-run any pipelines associated with the Service Accounts PAT.
- For this particular Service Account, the GitLab Inventory Builder uses this Service Accounts PAT to access APIs.
- So re-running a pipeline job for that repository that was previously failing due to token errors, demonstrated that the PAT rotation was successful as seen in the image below:
1. Logout of the Service Account and back in to an Account that has permissions to re-run any pipelines associated with the Service Accounts PAT.
1. For this particular Service Account, the GitLab Inventory Builder uses this Service Accounts PAT to access APIs.
1. So re-running a pipeline job for that repository that was previously failing due to token errors, demonstrated that the PAT rotation was successful as seen in the image below:
- If the pipeline passes, congratulations, update the issue with the success and notify any concerned parties of the successful PAT rotation, and finally, close the associated issue.
1. If the pipeline passes, congratulations, update the issue with the success and notify any concerned parties of the successful PAT rotation, and finally, close the associated issue.
@@ -31,7 +31,7 @@ The following list of questions can help determine if a tool may be a potential
1. Does it require an infrastructure that does not fit into GitLab?
1. Is there some complexity to managing the infrastructure of the tool that would justify it being outside of GitLab's monolith?
1. Are we adding another layer of complexity by having that infrastructure outside GitLab's monolith, and if so is it higher or lower than managing that?
1. Do we require Runway features that are not in the list of [supported features](https://docs.runway.gitlab.com/welcome/supported-features/)?
1. Do we require Runway features that are not in the list of [supported features](https://docs.runway.gitlab.com/runtimes/cloud-run/supported-features/)?
1. In terms of [tooling handover](/handbook/security/product-security/security-platforms-architecture/product-security-engineering/detailed-workflow#tooling-handover-epics), does the team have any experience with Runway and are they willing to take it over if it is deployed using that method?
Which can be visualized as the following mermaid diagram:
This runbook is a collection of resources for new or existing Product Security Engineers, or for those looking to build a body of work
to enhance their skills and knowledge in product security. This runbook is designed to provide guidance and resources for continuous learning and professional development.
This runbook is a collection of resources for new or existing Product Security Engineers, or for those looking to build a body of work to enhance their skills and knowledge in product security. This runbook is designed to provide guidance and resources for continuous learning and professional development.
### 1. Core Competencies
@@ -15,6 +14,7 @@ Team members should work to become proficient in the following core competencies
- Secure coding practices
- Threat modeling
- Risk assessment and management
- Internal security team functions and their purposes, such as Vulnerability Management and Product Security Incident Response
Team members should also have 'good' knowledge of the following areas; enough to know how to go and learn more should the need arise:
@@ -29,7 +29,7 @@ These learning paths are designed to help new team members in Product Security E
Essential:
-[ ] Analyze a historic GitLab vulnerability (from release posts or our [internal](https://internal.gitlab.com/handbook/security/product_security/application_security/reproducible-vulnerabilities/) or [public Reproducible Vulnerabilities page](/handbook/security/product-security/security-platforms-architecture/application-security/reproducible-vulnerabilities/)) or identify a class of recurring issues from [Bug Bounty Stats](https://bb-vuln-stats-gitlab-com-gl-security-security-re-c25977bf1ada94.gitlab.io/) or [HackerOne](https://hackerone.com/organizations/gitlab/analytics/dashboards/submissions?eid=submissions_by_weakness)
-[ ] Analyze a historic GitLab vulnerability (from release posts or our [internal](https://internal.gitlab.com/handbook/security/product_security/application_security/reproducible-vulnerabilities/) or [public Reproducible Vulnerabilities page](/handbook/security/product-security/security-platforms-architecture/application-security/reproducible-vulnerabilities/))
- [ ] Design a solution that makes it easier for developers to avoid this class of bug ("paved road"), and/or prevents or mitigates the class of bug (defense-in-depth)
-[ ] Document your solution design in an [issue](https://gitlab.com/gitlab-com/gl-security/product-security/product-security-engineering/product-security-engineering-team/-/issues/new)(and/or epic & child items)
- Have the solution peer reviewed by a teammate
@@ -57,7 +57,7 @@ Recommended:
- [ ] Conduct a post-implementation review and propose improvements
- [ ] Collaborate with the Application Security team to identify other high-impact automation opportunities
### 3. "Security Upskilling and Collaboration" Learning Path
#### 3. "Security Upskilling and Collaboration" Learning Path
Essential:
@@ -72,3 +72,29 @@ Essential:
Recommended:
- [ ] Update this page with resources or processes you found helpful!
#### 4. "Understanding Internal Security Team Functions" Learning Path
ProdSecEng builds tools, automation, and paved roads for other Product Security teams. To make good engineering decisions (what to build, how to scope it, what trade-offs matter) you need to understand what these teams do day-to-day, what processes they follow, and why.
The goal of this path is to build enough fluency that you can ask good clarifying questions when one of these teams brings ProdSecEng a tooling request.
**Essential:**
-[ ] Read the [Product Security overview](/handbook/security/product-security/) to see how the teams in the department fit together
-[ ] Read the [Security Capabilities Engineering](/handbook/security/product-security/security-capabilities-engineering/) page to understand ProdSecEng's immediate parent grouping (PSIRT, Vulnerability Management, and ProdSecEng)
- [ ] Skim each of the following team pages and note what kinds of work they do:
-[ ] [Application Security (AppSec)](/handbook/security/product-security/security-platforms-architecture/application-security/) - reviews code, threat-models features, and triages vulnerabilities reported through HackerOne
-[ ] [PSIRT](/handbook/security/product-security/psirt/) - handles vulnerability reports, coordinates remediation, and runs the security release process
-[ ] [Vulnerability Management](/handbook/security/product-security/vulnerability-management/) - tracks vulnerabilities across GitLab's products and infrastructure to closure
-[ ] [Infrastructure Security](/handbook/security/product-security/infrastructure-security/) - secures GitLab's production infrastructure
-[ ] [Data Security](/handbook/security/product-security/data-security/) - protects customer and corporate data
-[ ] [Supply Chain Risk Management](/handbook/security/product-security/supply-chain-risk-management/) - addresses risks from third-party dependencies and the software supply chain
-[ ] For each team above, identify a ProdSecEng-maintained tool that may support their work (the [tooling inventory in the internal handbook](https://internal.gitlab.com/handbook/security/product_security/product_security_engineering/) lists each tool's stakeholder)
-[ ] Read the [ProdSec-to-Product workflow](/handbook/security/product-security/security-platforms-architecture/security-interlock/prodsec-to-product-workflow/) to see how ProdSecEng turns requests from these teams into product features
**Recommended:**
- [ ] Sit in on a meeting from one of the teams ProdSecEng builds for (e.g., AppSec triage, PSIRT sync) to see how they actually use the tooling
- [ ] Pick one ProdSecEng-maintained tool and trace it end-to-end: read the project README, look at recent issues, and see which stakeholder team filed them
