PSIRT Case Lifecycle
Last updated: September 2, 2025
About the PSIRT Case Lifecycle
PSIRT Analysts and Engineers work together to investigate reports of security vulnerabilities within GitLab products, services, and infrastructure. For all valid reports, PSIRT works with Engineering to consult on remediation and with Delivery to inform our customers about essential security updates.
The PSIRT investigates reports from the following sources:
- HackerOne
- Customer
- VAT
- Public/News
- Security Tooling with demonstrable exploitation
- Internal Security Research
PSIRT raises an incident when a critical vulnerability is being actively exploited or is publicly known. See the Unified Incident Severity Matrix once it’s in the handbook for details of how the PSIRT works within the GitLab incident process. Otherwise, reports are investigated, filed, and remediated within established SLAs.
PSIRT Case Investigation
PSIRT cases have six stages. The first two stages, triage and assessment, are completed within PSIRT while the last four stages involve cross-functional work with multiple teams in Engineering and Delivery.
Note: The PSIRT triage process does not correspond to the Triage stage of a HackerOne case.
Stage | Triage | Assessment | Remediation | Validation | Release | Post-release |
---|---|---|---|---|---|---|
Who | Security Analyst (SA) | Security Engineer (SE) | SA & SE | Security Engineer (SE) | SA & SE | Security Analyst (SA) |
What | Initial review of a case to determine whether it requires a full assessment. | Full validation and assessment for each platform, including impact, reproduction steps, CWE, CVSS, impacted versions, severity | SE: Consultation on issue with Engineering and additional variant hunting SA: Monitoring of caseload SLAs & any Heightened Watch criteria | Review of fix to determine sufficiency | Release of fix and notification to customers in a security release blog post | Completion of monthly/quarterly reporting If critical, completion of retro and executive reporting. |
Possible Outcomes | Not valid Full assessment by PSIRT engineer Full assessment by PSIRT engineer with Heightened Watch Handover to SIRT Handover to Vulnerability Management | Not valid File defect for Engineering File defect for Engineering with Heightened Watch Joint PSIRT/SIRT Incident | Variants discovered and issue filed Mitigations and workarounds discovered No additional information discovered Escalate Heightened Watch to Joint PSIRT/SIRT incident | No fix: Risk accepted by Engineering Approve MR for fix RejectMR for fix | N/A | |
SLO | 5 days from case open | Critical/High: 10 days from triage handoff Medium/Low: 20 days from triage handoff | Per GitLab SLAs: Critical/High: 30 days Medium: 90 days Low: 180 days | N/A | N/A | Critical/High: 15 days from release Medium/Low: 30 days from release |
HackerOne case state | New Pending Program Review |
Pending Program Review | Triaged | Triaged | Triaged | Closed |
PSIRT Triage Workflow
The PSIRT Triage workflow ensures accurate initial assessment and proper routing of vulnerabilities through the system based on their severity and characteristics.
The following workflow applies to all reports within the scope of PSIRT but may include steps that are only applicable to HackerOne reports.
- Monitor for new reports in HackerOne, email, and Slack.
- Acknowledge Receipt
- Confirm receipt of the vulnerability report to the finder
- Completeness Check
- Assess the report to determine if there are sufficient details to proceed
- If incomplete: Ask the finder for additional details before continuing
- Check for handoff
- Handoff to Vulnerability Management
- If the report is of a published CVE that is not critical and has no GitLab specific POC, check the Known Exploited Vulnerabilities list
- If not on KEV: Hand off to Vulnerability Management
- Handoff to SecOps:
- If the report is of a published CVE that is critical and on the KEV list, trigger Heightened Watch
- If the report is within the SecOps scope, hand off to SecOps
- Handoff to Vulnerability Management
- For remaining reports, open a GitLab issue using the Import procedure in Slack
- Validate the report
- Review the report to determine if there is a potential vulnerability
- If invalid: Inform the issue reporter and update the report as required, then disengage
- If the report is potentially valid, classify the severity level (Critical, High, Medium, Low and complete the Triage Assessment section of the issue.
- Assign to Security Engineer
- (HackerOne) Monitor report for additional details or requests for updates
PSIRT Assessment Workflow
The assessment phase is primarily a technical evaluation period where PSIRT Engineers conduct deep analysis while maintaining coordination with other teams as needed for incident response or specialized expertise.
PSIRT Engineer Tasks
- Once assigned, complete technical vulnerability analysis
- Vulnerability Reproduction: Confirm and reproduce the reported vulnerability
- Platform and Version Identification: Determine all affected platforms and versions
- Exploitability Research: Assess how easily the vulnerability can be exploited
- Severity Assessment: Evaluate the technical severity level
- Impact Analysis: Conduct STRIDE methodology assessment to understand security impact
- CVSS Scoring: Calculate the Common Vulnerability Scoring System score
- CWE Classification: Assign appropriate Common Weakness Enumeration category
- Record all findings and technical details in the PSIRT investigation issue
- If GitLab is not impacted, identify reason and assign to Security Analyst for followup to finder
- If GitLab is impacted, complete assessment and file issue for Engineering remediation; ping Security Analyst to pay bounty and move HackerOne report to Triaged
- IOC Analysis: If the issue is critical, determine if Indicators of Compromise can be identified
- If Indicators of Compromise can be identified, open a joint PSIRT/SIRT investigation for SIRT to look for IOC exploitation markers.
- If exploitation is indicated, open SIRT incident
- Otherwise, implement Heightened Watch
PSIRT Analyst Tasks
- Complete Bounty and Administrative Tasks
- If GitLab is not impacted, follow up with finder
- If GitLab is impacted:
- For HackerOne reports pay appropriate bounty and move issue to Triaged state in HackerOne
- For other reports, follow up with finder
- If Heightened Watch, monitor for escalation to Incident
PSIRT Remediation Workflow
PSIRT Engineer Tasks
- In parallel with Remediation:
- Variant Hunting: Search for related vulnerabilities or attack vectors
- Mitigation Identification: Identify potential mitigations and workarounds
PSIRT Validation Workflow
The verification phase serves as a quality gate to ensure vulnerabilities are properly resolved before moving to the release process. The remediation and verification phases work in a loop - if the fix is determined to be insufficient during validation, the process returns to engineering remediation for additional work until the fix is deemed complete and sufficient.
PSIRT Engineer Tasks
- Validate Fix in MR Review
- If fix is inadequate, reject MR
- If fix is inadequate, approve MR and confirm affected platforms, versions, severity, CWE and CVSS score
PSIRT Release Workflow
Patch releases are a shared engineer and analyst responsibility. Refer to the General process for the application security team in patch releases for general information and AppSec Patch Release Duties for specific steps.
PSIRT Post-Release Workflow
The post-release tasks are shared between engineers and analysts.
PSIRT Engineer Tasks
- Verify that the release has been completed successfully.
- Create and/or contribute to the Release Retro issue
PSIRT Analyst Tasks
- If the issue is critical, schedule a retrospective and prepare executive reporting. Work in conjunction with SIRT if the issue was a joint SIRT/PSIRT responsibility.
- Create and/or contribute to the Release Retro issue
- Add to the Monthly Business Report (TBD)
- Ensure that the HackerOne report is closed.
1dd5ebd9
)