TechPrufer
Get started
GitLab
GitLab logoGitLab · Feature trail

Bug Triage and Reporting

36 posts · Dec 2014 – Jun 2026

What this trail covers

GitLab has established a structured approach to handling bugs, differentiating between security, regression, and feature bugs. This system aims to prioritize fixes based on severity and impact, encouraging community contributions for identification and resolution. The process involves clear channels for reporting different bug types, from direct contact for security vulnerabilities to the issue tracker and feedback channels for other bugs. This framework is crucial for maintaining the stability and reliability of the platform.

All GitLab trails
  1. Shai-Hulud copycat campaign targets Python developers through PyPI typosquattingThis post details the discovery and analysis of a coordinated supply chain attack on PyPI, involving five malicious Python packages impersonating popular libraries like Flask, Requests, and NumPy. The attack leverages Python's `.pth` file mechanism for initial execution and deploys a copy of the Shai-Hulud worm, which harvests credentials from CI/CD environments and major cloud providers. The post provides a deep technical dive into the infection vector, payload obfuscation (ROT-N cipher, AES-128-GCM encryption), credential harvesting targets, self-propagation mechanisms (committing malicious files to GitHub repos, publishing poisoned packages), and attacker attribution. It also outlines indicators of compromise and remediation steps for affected users, and highlights how GitLab's Dependency Scanning and Security Analyst Agent can help detect these threats.
  2. Manage vulnerability noise at scale with auto-dismiss policiesIntroduced auto-dismiss vulnerability policies, a new capability that allows users to define rules for automatically dismissing security findings. These policies can be configured based on file path, directory, or vulnerability identifier (CVE, CWE) and are applied on default-branch pipelines. The post details the 'why' and 'how' of auto-dismiss policies, provides use cases with ready-to-use configurations (e.g., dismissing test code vulnerabilities, vendored code, known false positives, generated code, infrastructure-mitigated vulnerabilities, and CVE families), and outlines a quick reference for parameters and limits. It also provides a getting started guide.
  3. How to transform compliance observation management with GitLabThis post details how the GitLab Security Team uses GitLab issues and issue boards to manage compliance observations, transforming them into actionable work items. It outlines the observation lifecycle (Identification, Validation, In-progress, Remediated, Resolution), the use of labels for organization (workflow, department, risk severity, system, program), and the creation of various issue boards for visualization. It also highlights the use of the triage bot for automation of issue hygiene and the key metrics used to measure success, such as resolution efficiency, risk assessment, and compliance readiness. Advanced strategies like integrating with security tools and applying predictive analytics are also discussed.
  4. Self-service security alert handling with GitLab's UAMIntroduced the User Attestation Module (UAM) as a Slack-first automation to streamline security alert handling. UAM allows team members to directly attest to the legitimacy of security alerts, reducing alert fatigue for the Security Incident Response Team (SIRT) and creating a new tier of alert handling. It integrates with GitLab API, Slack API, Tines, Devo, and a Metrics DB to manage the workflow, collect evidence, and provide audit trails and metrics.
  5. How GitLab measures Red Team impact: The adoption rate metricIntroduces a new metric for measuring Red Team impact: the adoption rate of recommendations. Details the implementation using GitLab issues, labels for classification (RTRec::Detection, RTRec::Control, RTRec::Process) and lifecycle tracking (RecOutcome::UnderReview, RecOutcome::InProgress, RecOutcome::Backlogged, RecOutcome::Blocked, RecOutcome::Adopted, RecOutcome::PartiallyAdopted, RecOutcome::NotAdopted). Leverages GitLab Query Language (GLQL) to create dynamic dashboards for monitoring recommendation status and trends. Discusses lessons learned regarding early metric implementation and cross-team collaboration.
  7. Introducing GitLab Advanced Vulnerability TrackingIntroduces Advanced Vulnerability Tracking, a feature that identifies and deduplicates vulnerabilities in a constantly changing codebase. It leverages contextual information from generated syntax trees to scope vulnerabilities and generates location fingerprints that are more robust to code changes than traditional line-based methods. A study showed this approach is 30% more effective than traditional tracking, reducing manual auditing effort.
  8. Quick vulnerability remediation with GitLab Advanced SAST + Duo AIThis post details the general availability of GitLab Advanced SAST, a new static application security testing scanner that performs cross-function and cross-file taint analysis. It outlines the prerequisites (Ultimate Subscription, GitLab 17.4+), configuration steps using `.gitlab-ci.yml`, and how to leverage the scanner's results within merge requests and the vulnerability report. It also highlights the integration with GitLab Duo Vulnerability Explanation for AI-powered remediation guidance, including a concrete example using OWASP Juice Shop.
  9. Integrate external security scanners into your DevSecOps workflowThis post details how to integrate external security scanners (specifically Snyk for dependency scanning and SAST) into GitLab's DevSecOps workflow. It provides concrete examples of CI/CD pipeline configurations and Python scripts to parse Snyk's JSON output into GitLab's expected `gl-dependency-scanning-report.json` format. It also demonstrates using a community-maintained SARIF converter to process Snyk's SARIF output into a `sast.json` artifact for SAST results. The goal is to display external scanner findings directly in the GitLab merge request widget and vulnerability report.
  10. Important information regarding xz-utils (CVE-2024-3094)This post details GitLab's response to CVE-2024-3094, a supply chain vulnerability in xz-utils. It confirms that GitLab.com and GitLab Dedicated are not affected by the vulnerable versions (5.6.0 and 5.6.1). It advises self-hosted customers to check their local packages, suggests downgrading to 5.4.x if affected, and recommends bringing potentially compromised hosts and containers offline. It also notes GitHub's action to disable the affected repository.
  11. Oxeye joins GitLab to advance application security capabilitiesAcquisition of Oxeye to enhance GitLab's SAST capabilities, including "code to cloud" vulnerability tracing and runtime context analysis for improved software composition analysis and compliance tools.
  12. How to integrate custom security scanners into GitLabThis post details the integration of custom security scanners into GitLab. It explains how these scanners can populate various security-related UI elements (merge request widget, Pipeline Security section, Vulnerability Report, vulnerability pages, Security dashboard) and integrate with Scan Result Policies. The post outlines the requirements for a custom scanner (scanning a directory, emitting JSON, containerization, providing a template) and provides a tutorial using the Fern Pattern Scanner. It emphasizes the use of JSON schemas for vulnerability data.
  13. Introducing GitLab browser-based active checks in DASTIntroduced browser-based active checks for DAST, starting with path traversal vulnerability detection (GitLab check 22.1) to replace ZAP alert 6. This enables more effective detection of vulnerabilities in modern web applications. Active checks are defined in YAML and can include match response, timing, and callback attack types. A worked example demonstrates how path traversal attacks are constructed and detected.
  14. How to export vulnerability reports to HTML/PDF and JiraThis post introduces custom scripts that leverage the GitLab API (GraphQL) to export vulnerability reports to HTML/PDF and to create Jira tickets for vulnerabilities. It provides detailed instructions on forking and setting up these scripts, including required CI/CD variables and API endpoints for both GitLab and Jira. The Jira integration script includes logic to prevent duplicate ticket creation.
  15. How to secure memory-safe vs. manually managed languagesThis post details how GitLab's SAST capabilities support security scanning for both memory-safe (Python, Go, Java, JavaScript, Ruby) and manually managed (C, C++) languages. It highlights specific scanners like Semgrep, Flawfinder, Bandit, GoSec, SpotBugs, ESLint, and Brakeman, and provides examples of detecting vulnerabilities like buffer overflows in C and SQL injection in Python. The post also emphasizes the importance of unit tests, fuzzing, and CI pipelines for further reliability and security, and introduces other security scanners like DAST, IaC scanning, dependency scanning, container scanning, license scanning, secret detection, and API fuzzing.
  16. Why 2022 was a record-breaking year in bug bounty awardsThis post details the record-breaking year for GitLab's bug bounty program in 2022, highlighting the total amount awarded ($1,055,770 USD across 221 valid reports), the number of reports received (920 from 424 researchers), and the number of resolved and public reports. It also recognizes top researchers for their contributions, including the most valid reports, most valid reports from a newcomer, best written report, most innovative report, and most impactful finding. Changes made in 2022 include adopting HackerOne's Gold Standard Safe Harbor, introducing a $20,000 CTF bonus, creating HackerOne Questions for direct communication, developing 'Reproducible Vulnerabilities' as a learning resource, and iterating on the HackerOne triage process and Bug Bounty Calculator for transparency and standardization.
  17. How GitLab handles security bugs (and why it matters)This post details GitLab's unique approach to handling security bugs, emphasizing transparency and public disclosure. It explains the role of CVEs, the CVSS scoring system, and GitLab's internal CVSS calculator. The post highlights why GitLab has many CVEs due to its commitment to transparency and open-core model, contrasting it with other SaaS platforms. It details the process of assigning CVEs to all vulnerabilities, publicly disclosing them after patches, and the use of automated bots to ensure public disclosure. The post also touches on the importance of supply chain transparency and encourages asking vendors about their security fix and disclosure processes. It mentions the combined patch and security releases delivered twice a month and the HackerOne bug bounty program.
  18. Using the GitLab GraphQL API for vulnerability reportingThis post details how to use the GitLab GraphQL API, specifically the `vulnerabilityCreate` mutation, to programmatically create vulnerabilities. It provides a step-by-step guide with `curl` commands, including obtaining a personal access token and project ID. Additionally, it outlines the process of building a custom vulnerability reporting application using GoLang and deploying it to Kubernetes via the GitLab Kubernetes Agent, demonstrating end-to-end integration of API capabilities.
  19. Three things you might not know about GitLab securityThis post introduces the GraphQL API for vulnerability management, enabling programmatic creation of vulnerability records. It also details the implementation of security approvals in merge requests to prevent the merging of new vulnerabilities and introduces compliance pipelines for enforcing security hygiene by combining project and group-level configurations.
  20. 3 Debugging tips we learned from youThis post contributes debugging tips derived from community experiences, focusing on: 1. Verifying non-code related issues (human factors, environmental issues). 2. The importance of detailed bug reporting (e.g., screen IDs, version numbers). 3. The principle that code executes as instructed, not necessarily as intended. 4. Investigating common suspects (e.g., DNS, SELinux) before deep dives. It emphasizes observability and systematic troubleshooting.
  21. Ask a hacker: ajxchapmanThis post features an interview with a bug bounty hunter who discusses their motivations, why they focus on GitLab's Bug Bounty Program (BBP), and their preferred bug hunting methodology (white/grey box with source code access). They highlight the value of open source and open issue response for identifying critical security issues. The hunter also provides advice on having a clear policy for reporting security vulnerabilities and expresses a desire for improved markdown editing capabilities within GitLab for issue tracking and wikis. They also touch upon supply chain attacks as an area deserving more research.
  22. Bug found and resolved in Dependency ScanningThis post details a bug in the Dependency Scanning analyzer (gemnasium) where the vulnerability database was not updating itself at scan time, affecting versions between v2.8.1 and v2.28.0. This resulted in outdated scan results. The fix involves updating to newer analyzer versions (gemnasium v2.28.1+, gemnasium-python v2.17.3+, gemnasium-maven v2.20.4+). Customers with custom registries or specific docker pull policies need to manually update their analyzer images.
  23. 2020: A year of iterationThis post details the architectural upgrade to Standalone Vulnerability Objects for storing vulnerability data, which was a significant undertaking that required a large feature flag for a coordinated release. It also highlights the subsequent feature development, including the transformation of Security Dashboards, the creation of a Security Center, and new integrations like linking issues to vulnerabilities and displaying pipeline status. The post emphasizes the technical achievement of reaching the 'Viable' maturity level for Vulnerability Management.
  24. Designing an incident management workflow from scratch and where its usedThis post details the development of GitLab's incident management workflow. It describes the process of validating the problem of fragmented alert and incident management tools, and the subsequent solution validation through a Special Interest Group (SIG). Key contributions include the introduction of a dedicated 'incident' issue type, which is a specialized form of issue designed for incident response, offering features like quick access to metrics, runbooks, and an incident timeline. This builds upon the existing issue framework by providing a more tailored experience for managing and resolving incidents, aiming to create a seamless workflow from alert receipt to code deployment.
  25. How we work to detect and mitigate Spam on GitLab.com and beyondThis post details the Trust and Safety team's work on detecting and mitigating spam on GitLab.com, defining abuse, and providing reporting mechanisms. For self-managed instances, it outlines best practices including enabling 2FA, implementing sign-up and sign-in restrictions (disabling new sign-ups, requiring admin approval, email confirmation, domain allow/denylist), hardening the instance, understanding abuse reporting and management for admins, and imposing rate limits on issue creation and user/IP access. It also mentions upcoming explorations in alternative captcha options and preventing bots from posting URLs, with the potential to integrate successful automation into the product.
  26. Search team directs testing efforts with risk mappingThis post introduces the concept and implementation of risk mapping for directing testing efforts within the search team. It details the process of identifying 'risk facets' (e.g., record insertion, indexing, recall, speed, efficiency, cost), mapping existing issues to these facets, assessing testing coverage (implicit vs. explicit), and constructing a risk matrix (risk level, impact, likelihood). The goal is to proactively identify and mitigate unmitigated risks by focusing testing resources on high-risk areas, moving away from reactive bug fixing.
  27. Bugs, bounties, and cherry brownsThis post details the first year of GitLab's public bug bounty program, highlighting the number of reports received (1378 from 513 researchers), total bounties awarded ($565,650 to 171 researchers), and the impact on product security. It also announces winners of a bug bounty contest held in October-November, recognizing contributions for reputation points, best written report, most innovative report, and most impactful finding. The post also mentions custom swag for winners and a commitment to continued program improvement.
  28. What we learned by taking our bug bounty program publicThis post details the evolution of GitLab's bug bounty program after opening it to the public. Key contributions include: the introduction of an automated bot for initial report responses and triage ETAs; the use of a Slack command to import triaged HackerOne reports into confidential GitLab issues, assigning them to product managers for scheduling fixes; analysis of report volume, reporter demographics (doubling new reporters), and vulnerability types (critical and high-severity); identification of an increase in false positives and the use of these to refine triage processes; enhancements to communication with reporters, including automated fix date estimations via the GitLab API; implementation of a weekly rotation schedule for dedicated H1 response and triage; a shift in fix scheduling where the security team assigns due dates and product managers balance feature/security deliverables; and insights gained that prompted refinements in the permissions model (investigating automated CI checks) and advocacy for code reuse via security-focused libraries to prevent recurring vulnerability classes.
  29. Inside the GitLab public bug bounty programThis post details the launch and early success of GitLab's public bug bounty program, highlighting its role as a reactive security measure. It outlines key metrics for measuring success, including the quantity of new report submissions, the percentage of repeat reporters, transparency in vulnerability disclosure (setting all vulnerability details to public 30 days after a patch is released), responsiveness to reporters, and the commitment to competitive rewards. It also lists the top five GitLab reporters by bounty and mentions the desire to put GitLab Tanuki on swag.
  30. How to radically simplify bug reporting in GitLabThis post introduces Marker.io as a third-party tool to integrate with GitLab for simplifying bug reporting. It details how Marker.io reduces the reporter's workflow from 10 steps to 3 by capturing and annotating screenshots and sending them directly to a chosen GitLab project. It also highlights the automatic capture of technical environment data (browser, OS, screen size, etc.) within the bug report, making it more actionable for developers. The post contrasts the traditional complex bug reporting process with the streamlined Marker.io workflow.
  31. 3 Rules for tackling thousands of open issuesThis post details a three-rule system for prioritizing and triaging engineering issues: 1. Regressions have the highest priority to ensure existing functionality remains stable. 2. Deliverables are second, representing planned features for the next release. 3. Bugs are addressed with any remaining free time. The post emphasizes the use of issue boards and labels for tracking progress and communication, particularly in a remote work environment. It highlights how this system simplifies management by allowing filtering based on issue type and promotes self-sufficiency among engineers.
  32. Explaining GitLab bugsThis post introduces the initial classification of bugs into three categories: security, regression, and feature bugs. It outlines the priority and response times for security bugs, the process for reporting regression bugs via Twitter or the issue tracker, and the criteria for identifying and reporting feature bugs through the feedback tracker or issue tracker. It also highlights the significant role of community contributions in finding and fixing bugs.