GitLab's Infrastructure Security team is responsible for the planning, execution, and support of initiatives specific to the security of GitLab's Infrastructure.
As stable counterparts from the Security department, the team members support specific [Product Categories](https://gitlab.com/search?group_id=6543&project_id=7764&scope=blobs&search=infrasec+file%3Astages%5C.yml%24®ex=false) heavily reliant on Cloud and Infrastructure solutions. They collaborate with Development, Infrastructure, and Security teams across various product categories.
Infrastructure Security's engagements take place in the form of infrastructure change reviews, SaaS infrastructure access & permissions models, cloud security best practices, operating system security, security monitoring at the host and container level, vulnerability management, and patching policies.
Some high-priority initiatives for the team are:
- Deployment of tools to improve our data collection capabilities (e.g., Wiz, OSQuery)
- Counterpart work (e.g., Dedicated, FedRAMP, Cells, AI)
Infrastructure Security (InfraSec) is a team within [Product Security](/handbook/security/product-security/), part of the Platform Security group.
## Working With Us
## Mission
1. To request an **infrastructure security review**, please create an issue using [the security review template](https://gitlab.com/gitlab-com/gl-security/product-security/product-security-engagements/product-security-requests/-/issues/new?description_template=infrasec-security-review)
1. To request a **production readiness review**, please create an issue using [the production readiness template](https://gitlab.com/gitlab-com/gl-security/product-security/product-security-engagements/product-security-requests/-/issues/new?description_template=infrasec-production-readiness)
1. To report a bug or request a change related to **Teleport**, please create an issue using [the teleport issue template](https://gitlab.com/gitlab-com/gl-security/product-security/product-security-engagements/product-security-requests/-/issues/new?description_template=infrasec-teleport)
1. For everything else please create an issue using [the generic issue template](https://gitlab.com/gitlab-com/gl-security/product-security/product-security-engagements/product-security-requests/-/issues/new?description_template=infrasec-other-request)
We secure the cloud that GitLab's product and internal teams run on: commercial, corporate, and FedRAMP. We run the production security tooling that shows us our cloud posture, and we turn what it finds into fixes. We're also writing cloud, infrastructure, and data security requirements as controls that engineers and AI agents can both read, so secure configuration is built in from the start instead of caught in review.
- Please refrain from `@mention` individuals. Please use the `@gitlab-com/gl-security/product-security/infrastructure-security` handle on GitLab.com instead.
- You can also chat with us on Slack in the dedicated `#security-infrasec` channel or by tagging us `@infrasec-team`.
- The team will triage (and prioritise accordingly) all incoming request on a daily basis.
- If you have an urgent ask and can't wait for the regular triage please reach out in our Slack channel to let us know.
## Scope and responsibilities
## How We Work
### What we own
### Meetings and Scheduled Calls
1.**Cloud security requirements.** Cloud and infrastructure security requirements, written as machine-readable controls that plug into developer and AI coding workflows. This work lives in the GitLab Cloud Security Framework, which we're building now.
1.**Infrastructure security reviews.** AI-assisted reviews of features that add or change cloud infrastructure, containers, network architecture, infrastructure as code, or secrets management. We build and maintain the agents and flows behind these reviews.
1.**Production security tooling.** Running Wiz and our other security tools across GitLab's offerings, and feeding their findings into a steady remediation pipeline.
1.**Corporate cloud.** Securing our corporate cloud environments, including the Sandbox Cloud realm: access controls, cost governance, policy enforcement, and account lifecycle.
1.**Misconfiguration remediation.** Finding and fixing cloud misconfigurations in production and non-production environments.
1.**FedRAMP operations.** Moving off accelerator-provided tools toward one toolchain for Commercial and Federal, plus FedRAMP vulnerability management tooling, operations, and reporting.
1.**Data security.** Data-layer security requirements and remediation of data-layer risks, in production and non-production.
1.**Infrastructure penetration testing.** Coordinating pen tests of GitLab's cloud and production infrastructure.
1.**Risk register items.** Owning the cloud and data-layer items on the [Product Security Risk Register](/handbook/security/product-security/security-platforms-architecture/risk-register/) and leading their remediation.
Our preference is to work asynchronously, within our project issue tracker as described in [the project management section](#project-management) below.
### Out of scope
The team does have set of regular synchronous calls:
| Security controls for GitLab's own groups and namespaces, and software supply chain governance | Security Posture Management |
- A fortnightly team sync to discuss progress, blockers, and anything related to the InfraSec team.
- Everyone in the company is welcome to join.
- A quarterly team retrospective to reflect on what went well in the previous quarter, and discuss what can be improved going forward.
- 1-1s between Individual Contributors and the Engineering Manager.
### Where our work comes from
### Team Pages
Most of our work arrives through the request templates below. The rest comes from risk register items, FedRAMP and Security Compliance commitments, and the projects we plan each quarter.
- This [Handbook Page](/handbook/security/product-security/infrastructure-security/), which contains general information about the team
- The [Internal Handbook](https://internal.gitlab.com/handbook/security/product_security/infrastructure_security/), which is the operational source of truth for the team. Everyone is **encouraged** to check it out for team's information
- The [Infrastructure Security GitLab Sub-Group](https://gitlab.com/gitlab-com/gl-security/product-security/infrastructure-security), which contains EPICs and repositories
- The [Infrastructure Security **Public** Sub-Group](https://gitlab.com/gitlab-com/gl-security/security-operations/infrastructure-security-public), which contains publicly facing resources (e.g., Docker images, etc.)
## Working with us
### Project Management
1. To request an **infrastructure security review**, create an issue with [the security review template](https://gitlab.com/gitlab-com/gl-security/product-security/product-security-engagements/product-security-requests/-/issues/new?description_template=infrasec-security-review).
1. To request a **production readiness review**, create an issue with [the production readiness template](https://gitlab.com/gitlab-com/gl-security/product-security/product-security-engagements/product-security-requests/-/issues/new?description_template=infrasec-production-readiness).
1. To report a bug or request a change to **Teleport**, create an issue with [the Teleport template](https://gitlab.com/gitlab-com/gl-security/product-security/product-security-engagements/product-security-requests/-/issues/new?description_template=infrasec-teleport).
1. For anything else, use [the generic request template](https://gitlab.com/gitlab-com/gl-security/product-security/product-security-engagements/product-security-requests/-/issues/new?description_template=infrasec-other-request).
We use Epics, Issues, and Issue Boards to organize our work, as they complement each other:
- The single source of truth for engineering work is the [InfraSec Sub-Group in GitLab](https://gitlab.com/groups/gitlab-com/gl-security/product-security/infrastructure-security/-/epics). **All Epics will be collected at this level**
- Having all projects at this level allows us to use a single list for prioritization and enables us to prioritize work for different services alongside each other
- Projects are prioritized in line with the [InfraSec Goals](https://gitlab.com/groups/gitlab-com/gl-security/product-security/infrastructure-security/-/wikis/InfraSec-Goals)
#### Team Planning
- For the **long term strategy** of the InfraSec Team, you can refer to:
- From a **tactical point of view**, you can refer to:
- 🎛 [InfraSec Planning Board](https://gitlab.com/groups/gitlab-com/-/boards/7549315?label_name%5B%5D=Department%3A%3AInfraSec) (for the tasks we are currently working on)
#### Project Ownership
Each project has an owner who is responsible for delivering the project.
The owner needs to:
1. Regularly update the status in the Epic description and milestones.
1. Work with others to move project issues through the boards.
#### Labels
Please use the following labels for **project work only**:
| `~"Department::Product Security"` | Department Label |
| `~"Infrastructure Security Team"` | Team Label |
| `~"InfraSec::triage"` | For new issues which need to be triaged |
Please mention `@gitlab-com/gl-security/product-security/infrastructure-security` on GitLab instead of tagging individuals. On Slack, find us in `#security-infrasec` or tag `@infrasec-team`.
### Design Documents
We triage new requests every working day. If something's urgent and can't wait, say so in `#security-infrasec`. For a security incident, don't wait for us: page the Security Incident Response Team with `/security` in any Slack channel.
Before starting a new project, the team is **encouraged**
to define software designs through design docs.
These design doc documents the high level implementation strategy and key design decisions with emphasis on the trade-offs that were considered during those decisions.
## How we plan
To start discussing a new design:
We plan by quarter, and everything starts from the [FY27 InfraSec Planning epic (&210)](https://gitlab.com/groups/gitlab-com/gl-security/product-security/infrastructure-security/-/work_items/210). Each quarter has a planning epic and a KTLO/BAU epic underneath it. We link to the FY27 planning epic here rather than to the quarterly epics, because those change every quarter.
1. Create a new MR in the [InfraSec Team Charter repo](https://gitlab.com/gitlab-com/gl-security/product-security/infrastructure-security/team-charter/-/tree/main/designs) with the Design proposal. You can use [this template](https://gitlab.com/gitlab-com/gl-security/product-security/infrastructure-security/team-charter/-/blob/main/.gitlab/issue_templates/design_doc.md) as a reference for the structure of the Design doc.
2. Fill the data as requested
3. Mark other members of the team as reviewers
Our work falls into a few buckets:
## Additional Resources
-**Delivery epics** are planned projects. Each one has a lead and a named backup, a clear scope, and milestones written in the description.
-**Delivery issues** are smaller projects tracked as a single issue. If one grows, it gets an epic.
-**KTLO/BAU** is the recurring and reactive work: reviews, access grants, incident follow-up, renewals, and one-off tasks.
-**Paused work** stays visible in the quarter's planning epic, so nothing quietly disappears.
### Tracking KTLO and BAU work
When we pick up KTLO or BAU work, we add the issue as a child of the current quarter's KTLO/BAU epic, which sits under the [FY27 InfraSec Planning epic](https://gitlab.com/groups/gitlab-com/gl-security/product-security/infrastructure-security/-/work_items/210). If the issue already has a parent epic in another team's project, we link it to our KTLO/BAU epic as related instead of moving it.
This matters more than it looks. Reactive work is a big share of what we do, and the KTLO/BAU epic is the only place we can see and report on it. If it isn't linked, it didn't happen as far as planning is concerned.
### Labels
Delivery epics and delivery issues need both the team label and the current quarter label. The planning epic's queries use them to find active work, so anything missing either label won't show up.
| Label | Use it on |
|-------|-----------|
| `~"Infrastructure Security Team"` | All InfraSec work |
| `~"Department::Product Security"` | All InfraSec work |
| `~FY27-Q4` (the current quarter) | Delivery epics and delivery issues only. Don't add it to planning epics, KTLO/BAU epics, or KTLO/BAU items |
| `~"InfraSec::triage"` | New requests that need triage |
When delivery work carries into the next quarter, add the new quarter label and keep the old one as history.
### Project ownership
Each delivery epic's lead is responsible for delivering it. That means keeping the status and milestones in the epic description current, and moving issues along with the people working on them.
## Meetings
We work asynchronously by default, in our issues and epics. The team spans time zones from New Zealand to the US, so no single meeting time works for everyone.
Our team sync runs every week and rotates through three time slots, so everyone can make some of them without a midnight call. All three slots share one sync document, which holds the agenda and notes. Every session is recorded, with shortcuts to the recordings in the sync document and the InfraSec shared drive. When we miss a slot, we catch up on the recording and add to the agenda async.
Other team members are welcome to join. Get in touch with us in `#security-infrasec` and we'll add you to the invite and the agenda.
We also hold a quarterly retrospective on what went well and what to change, and each team member has regular 1:1s with their manager.
## Design documents
Before starting a new project, we encourage writing a design doc. It records the implementation approach and the key decisions, especially the trade-offs we weighed.
To propose a design:
1. Open an MR in the [InfraSec Team Charter repo](https://gitlab.com/gitlab-com/gl-security/product-security/infrastructure-security/team-charter/-/tree/main/designs), using [the design doc template](https://gitlab.com/gitlab-com/gl-security/product-security/infrastructure-security/team-charter/-/blob/main/.gitlab/issue_templates/design_doc.md) as a guide.
1. Fill in each section.
1. Add other team members as reviewers.
1. Link the MR from the delivery epic it belongs to.
## Who's on the team
We don't keep a list of names here, because it goes stale. For the current team:
-**Workday** shows who's on the team and who they report to.
-**Slack:**`@infrasec-team` reaches everyone, and `#security-infrasec` is where we work in the open.
-**GitLab:** the [Infrastructure Security group members list](https://gitlab.com/groups/gitlab-com/gl-security/product-security/infrastructure-security/-/group_members).
-**Role descriptions** are in the [job description library](/job-description-library/security/infrastructure-security).
## Team pages and resources
- The [Internal Handbook](https://internal.gitlab.com/handbook/security/product_security/infrastructure_security/) is our operational source of truth (GitLab team members only).
- The [Infrastructure Security subgroup](https://gitlab.com/gitlab-com/gl-security/product-security/infrastructure-security) holds our epics and repositories.
- The [Infrastructure Security public subgroup](https://gitlab.com/gitlab-com/gl-security/security-operations/infrastructure-security-public) holds public resources such as Docker images.
-[Teleport](teleport/) covers access to production resources.
-[Issue lifecycle](issue-lifecycle/) explains how the triage bot labels and closes issues.
### Onboarding
- Infrastructure Security Team [Onboarding Template](https://gitlab.com/gitlab-com/gl-security/product-security/infrastructure-security/team-charter/-/blob/master/onboarding/onboarding_template.md)
