Triage Rotation

Application Security team members are alphabetically assigned as the responsible individual (DRI) for incoming requests to the Application Security team, typically for a weekly or fortnightly period.

Who is on rotation?

Automation manages the scheduling and assignment of rotations:

• “Who is on rotation now?”
• Rotation Management FAQ & README
• Holiday Coverage

What are the rotations?

For any request to the Application Security team member during rotation, the AppSec Triage Dashboard is the single-source-of-truth.

The following rotations are defined:

• (Weekly Assignment) Security Dashboard Review

  • Responsible for reviewing security dashboards on a best-effort level

• (Weekly Assignment) Triage Rotation (mentions and issues), by order of priority:

  • First responder to JiHu Contribution pings that come up in the AppSec Triage Dashboard
  • First responder to merge requests which reference confidential issues as listed in the AppSec Triage Dashboard. An individual issue is created for each merge request which references confidential issues in the AppSec Triage Dashboard issue tracker. For those issues:
    • Close it if the merge request can be public (comment any rationale in the issue)
    • If the merge request references a legitimate security issue
      • If the referenced confidential issue has a ~security-fix-in-public label, indicating it has been approved by an AppSec team member to be fixed in public, link to the comment granting approval or include a message in the AppSec Triage Dashboard issue denoting that the ~security-fix-in-public label was added.
      • Decide if it can be public anyway, and apply the ~security-fix-in-public label retrospectively
      • Otherwise contact SIRT and the merge request author to get the merge request removed.
      • Use the Urgent - SEOC should be paged right away option if waiting up to 24 hours for a resolution would be too long.
  • First responder to mentions of the following group aliases:
    • @gitlab-com/gl-security/product-security/appsec on GitLab.com. These mentions appear as “Ping Triage SLA” items in the AppSec Triage Dashboard
      • PSIRT and/or SIRT are responsible for addressing external reports of a product vulnerability or customer exploit. See Hand-off to PSIRT/SIRT during triage rotation
    • @appsec-team in Slack
  • First responder to mentions from the custom SAST bot:
    • All merge requests with the ~appsec-sast-ping::unresolved label must be reviewed. These appear as “Custom SAST Reports” in the AppSec Triage Dashboard
    • Apply the ~appsec-sast-ping::resolved label once the bot’s findings have been resolved.
    • A dashboard with all the bot’s findings can be found here.
  • First responder to any Dependency Reviews showing up in the AppSec Triage Dashboard

• (~Fortnightly Assignment) Security Engineer for Security & Patch Releases

• (Fortnightly Assignment, Federal AppSec only) Release Certifications

  • Responsible for the release certification process
  • This applies to any release that might have JiHu contributions, including monthly and patch releases

• (Quarterly Assignment) AppSec Blog Post

If the Application Security team member has a conflict for the assigned week they may swap rotation weeks with another team member. This may be done for any reason including time off or the need for time to focus on a particular task.

Team members should not be assigned on weeks they are responsible for the scheduled security release.

Team members not assigned as the DRI for the week should continue to triage reports when possible, especially to close duplicates or handle related reports to those they have already triaged.

Team members remain responsible for their own assigned reports.

Triage SLA policies

Without clear SLA targets, requesters don’t know when to expect a response, and the AppSec team lacks visibility into which requests are becoming urgent. This results in inefficient communication patterns, duplicate follow-ups, and difficulty prioritizing work based on how long requests have been waiting. Establishing formal SLAs creates transparency for both requesters and the AppSec team, reduces ad-hoc interruptions, and ensures timely responses while providing clear escalation paths when needed.

SLA Targets

Resource Type	Response SLA	Resolution SLA
Issues	4 business days	N/A (issues are tracked for response only)
Merge Requests	2 business days	5 business days

Issues

How the bot works:

When someone pings AppSec (@gitlab-com/gl-security/product-security/appsec or @gitlab-com/gl-security/appsec) in an issue:

1. The bot automatically responds to acknowledge the ping
2. Adds labels: ~AppSecResponseSLA::pinged, ~AppSecWorkflow::new, ~Application Security Team
3. Starts tracking the 4-day response SLA

SLA tracking timeline:

• Day 2: Bot adds ~AppSecResponseSLA::at-risk warning label and posts a reminder
• Day 3: Bot adds ~AppSecResponseSLA::near-breach warning label with urgent notification
• Day 4: Bot adds ~AppSecResponseSLA::breached label and escalates to leadership
• Weekly: Bot posts reminders every 7 days after breach

What you need to do:

1. When you begin working on the issue, apply one of these labels:
   • ~AppSecWorkflow::planned - if scheduled for later
   • ~AppSecWorkflow::in-progress - if actively working on it
2. When complete, apply ~AppSecWorkflow::complete
3. The bot will automatically update SLA tracking labels based on your workflow updates

Merge Requests

How the bot works:

When someone pings AppSec in a merge request:

1. The bot automatically responds to acknowledge the ping
2. Adds labels: ~AppSecResponseSLA::pinged, ~AppSecWorkflow::new, ~Application Security Team
3. Starts tracking both response and resolution SLAs

Response SLA (2 business days)

Timeline:

• Day 1: Bot adds ~AppSecResponseSLA::near-breach warning label
• Day 2: Bot adds ~AppSecResponseSLA::breached warning label and escalates to leadership
• Weekly: Bot posts reminders every 7 days after breach

How to meet the Response SLA:

Apply one of these workflow labels within 2 business days:

• ~AppSecWorkflow::planned - if you’ve reviewed and scheduled it for later
• ~AppSecWorkflow::in-progress - if you’re actively reviewing
• ~AppSecWorkflow::complete - if review is already done

Once you apply any of these labels:

• The bot stops the response SLA timer
• The bot adds ~AppSecResponseSLA::completed-within-sla (if not breached)
• For planned or in-progress labels, the resolution SLA timer begins

Resolution SLA (5 business days from when work begins)

Timeline (starts when planned or in-progress is applied):

• Day 3: Bot adds ~AppSecResolutionSLA::at-risk warning label
• Day 4: Bot adds ~AppSecResolutionSLA::near-breach warning label with urgent notification
• Day 5: Bot adds ~AppSecResolutionSLA::breached label and escalates to leadership
• Weekly: Bot posts reminders every 7 days after breach

How to meet the Resolution SLA:

Complete your review and apply ~AppSecWorkflow::complete within 5 business days of starting work.

Once you apply the complete label:

• The bot stops the resolution SLA timer
• The bot adds ~AppSecResolutionSLA::completed-within-sla (if not breached)
• All warning labels (at-risk, near-breach) are removed

Important notes:

• Business days exclude weekends
• Breached labels remain for visibility to leadership
• You can add ~AppSecSLA::ignore to exclude items from SLA tracking
• The bot will not trigger if an AppSec team member pings the team

Hand-off to PSIRT/SIRT during triage rotation

When team members are assigned to Triage rotation and are first responder to mentions of @gitlab-com/gl-security/product-security/appsec on GitLab.com or @appsec-team in Slack, assess whether the ping is an external report of a product vulnerability or customer exploit. In these instances, hand off to @gitlab-com/gl-security/product-security/appsec/psirt-group and/or @gitlab-sirt.

Direct reports from customers of vulnerabilities found during container scans to the Vulnerability Mangement team.

Triaging exposed secrets

Exposure of information and secrets is handled a little differently to vulnerabilities, as there is nothing to patch and therefore no need for a GitLab Project Issue, CVSS, or CVE. When you’re pinged during your rotation and you see a leaked secret, follow the process described on the HackerOne runbook