Bug Triage and Reporting

6/9/2026

This 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.

3/25/2026

Introduced 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.

7/24/2025

This 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.

3/18/2025

Introduced 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.

3/5/2025

Introduces 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.

1/21/2025

Introduces 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.

10/22/2024

This 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/19/2024

Introduces Advanced SAST, a new scanner powered by acquired Oxeye technology, which uses taint analysis and in-house security research to identify exploitable vulnerabilities with lower false-positive rates. It integrates natively into the GitLab DevSecOps platform, providing contextual remediation and integrating with GitLab Duo Enterprise AI. The feature is available in GitLab 17.3+ and will be enabled by default no later than GitLab 18.0. Future plans include upgrading more languages, real-time IDE scanning, and incremental scanning.

5/8/2024

Introduces the Jam for GitLab browser extension, which integrates with GitLab's API to automatically create comprehensive debugging reports as GitLab issues. These reports include instant replays of bugs, internet speed, browser information, console/network logs, and reproduction steps, significantly streamlining the bug-fixing process.

4/8/2024

This 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.

3/20/2024

Acquisition 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.

2/27/2024

This 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.

10/10/2023

Introduced 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.

9/14/2023

This 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.

3/14/2023

This 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.

12/19/2022

This 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.

2/17/2022

This post details GitLab's process for handling security bugs, emphasizing transparency and public disclosure. It explains the role of CVEs, the Common Vulnerability Scoring System (CVSS), and GitLab's internal CVSS calculator. The post highlights GitLab's commitment to transparency by assigning a CVE to every vulnerability, disclosing issues publicly via security release blog posts and HackerOne Hacktivity, and aiming to publicly disclose GitLab issues 30 days after a patch is released. It also discusses supply chain risks and encourages customers to inquire about their vendors' security disclosure processes. The post also mentions the combination of patch and security releases into unified patch releases delivered twice a month.

2/2/2022

This 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.

12/14/2021

This post details GitLab's bug bounty program in 2021, highlighting metrics such as 752 reports, $280K USD in bounties awarded, and 189 resolved reports. It announces the move to a managed program on HackerOne, which shifted initial triage and reproduction responsibilities. Bounties were increased across all ranges. The post also discusses the GitLab Bug Bounty Council process, the use of CVSS scores and a CVSS calculator for transparency, and provides tips for hackers through various content formats. It mentions contest winners for reputation points, best written report, most innovative report, and most impactful finding, with details to be released later. Future plans include cleaning up the security backlog and potentially increasing program scope.

11/23/2021

This 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.

11/1/2021

This post announces the 3rd annual bug bounty contest, a "swagtastic sequel to the sequel." It highlights increased bounties across all ranges (Critical: $20,000 - $35,000, High: $5,000 - $15,000, Medium: $1,000 - $2500, Low: $100 - $750) for reports submitted after November 22, 2021. It also introduces a new CVSS calculator for standardizing bounty calculations and announces a community hacking contest from November 1 to December 3, 2021, with custom GitLab swag prizes for categories such as most reputation points, most reputation points by a new reporter, best written report, most innovative report, and most impactful finding. The post also provides links to resources for inspiration, including the release process, previous bug bounty blog posts, and advice from top bug bounty hunters.

6/11/2021

This post highlights how bug bounty hunters use GitLab for issue tracking, collaboration, and managing bug reports. Alex Chapman uses GitLab issues for note-taking, idea generation, and tracking bug bounty programs, labeling issues with program state and payout amounts. Dominic Couture uses private GitLab projects for collaboration on hacking projects, with each idea as an issue and scripts/files stored in Git repositories. Nishant Jain uses GitLab for hosting CTFs and hacking POCs, leveraging the Web IDE and issue tracking for HackerOne programs, including custom labels, delegation, group permissions, and issue boards. The post also identifies areas for improvement, such as markdown editing, mobile experience, and custom file templates.

3/31/2021

This post shares debugging tips learned from the community, focusing on identifying non-code related issues (user errors, environmental factors), the importance of detailed bug reports ('receipts'), understanding that code executes as instructed, and investigating common suspects. It contributes to the 'Bug Triage and Reporting' thread by providing practical, community-sourced advice for debugging.

3/4/2021

This 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.

2/19/2021

This 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.

1/18/2021

This 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.

11/3/2020

This 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.

10/29/2020

This 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.

9/3/2020

Introduced the concept of risk mapping for directing testing efforts within the Search team. Developed a methodology for creating risk maps by identifying 'risk facets' (e.g., record insertion, indexing, recall, speed, efficiency, cost) and mapping them to testing coverage (implicit vs. explicit). The risk map includes a risk matrix (risk level, impact, likelihood) to quantify and prioritize risks. The post also outlines next steps for improving the risk mapping process, including automation and feature enhancements.

12/12/2019

This post details the first year of GitLab's public bug bounty program, highlighting its success in receiving 1378 reports from 513 researchers and awarding $565,650 in bounties to 171 researchers. It also announces the winners of a bug bounty contest held in October/November, recognizing contributions in reputation points, report quality, innovation, and impact. The post emphasizes the program's role in enhancing product security and outlines plans for continued growth and improvement.

7/19/2019

This post details the evolution of GitLab's bug bounty program after making it public. It highlights the increase in valid vulnerability reports, particularly from new reporters, and the challenges and improvements in the triage and response process. Key technical contributions include the use of an automated bot for initial responses and ETA estimations, a Slack command to import triaged reports into confidential GitLab issues, and the integration of the GitLab API to provide reporters with expected fix dates based on assigned milestones. The post also discusses how bug bounty findings have informed improvements to the platform's permissions model and the advocacy for code reuse through security-focused libraries.

4/29/2019

This post details the launch and early success of GitLab's public bug bounty program. It outlines the program's goals, metrics for success (quantity of submissions, repeat reporters, transparency, responsiveness, competitive rewards), and highlights the importance of both proactive and reactive security measures. It also lists the top five GitLab reporters by bounty and discusses the value of transparency in vulnerability disclosure.

1/9/2019

This post introduces Marker.io as a tool to simplify and speed up bug reporting into GitLab. It details the manual steps reporters typically take and contrasts them with the streamlined three-step process using Marker.io. The post highlights the automatic capture of technical environment data (browser, OS, screen size, etc.) and the inclusion of annotated screenshots, URLs, and other vital information directly within GitLab issues, making reports more actionable for developers.

10/30/2018

This post details the challenges GitLab faces in prioritizing and assigning ownership for engineering-led issues that span multiple product categories, such as technical debt. It highlights the 'bystander effect' where no single team feels responsible, leading to stalled initiatives. The post discusses research on cross-functional team dysfunction and the need for end-to-end accountable leaders. It proposes potential solutions, including establishing a dedicated team for cross-vertical issues or improving communication and incentive alignment between Product and Engineering Managers to ensure these tasks are scheduled and addressed.

4/10/2017

This post details GitLab's three core rules for issue prioritization: 1. Regressions have the highest priority to ensure existing functionality remains stable. 2. Deliverables are the second priority, representing planned work for the next release. 3. Open bugs are addressed by engineers with free time, unless otherwise directed. The post emphasizes the use of the issue board and labels for tracking progress and communication, facilitating asynchronous work and manager oversight.

12/8/2014

This post introduces the initial classification of bugs into three categories: Security bugs, Regression bugs, and Feature bugs. It outlines the priority given to each type, the expected feedback timelines for security bugs, and the recommended channels for reporting each type of bug (support.gitlab.com for security, Twitter or issue tracker for regressions, and feedback tracker or issue tracker for feature bugs). It also highlights the role of the community in contributing fixes.