Infrastructure Security (InfraSec) is a team within Product Security, part of the Platform Security group.
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.
| Area | Who owns it |
|---|---|
| Application-layer security reviews | Application Security |
| Product-layer security architecture requirements | Security Architecture |
| Vulnerability management outside FedRAMP | Vulnerability Operations |
| Security controls for GitLab’s own groups and namespaces, and software supply chain governance | Security Posture Management |
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.
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.
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.
We plan by quarter, and everything starts from the FY27 InfraSec Planning epic (&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.
Our work falls into a few buckets:
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. 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.
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.
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.
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.
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:
We don’t keep a list of names here, because it goes stale. For the current team:
@infrasec-team reaches everyone, and #security-infrasec is where we work in the open.We review this page at the end of each quarter, as part of quarterly planning. If you spot something wrong before then, open an MR.
655ce943)
