0-1 Creating the first DevSecOps platform

GitLab’s security capabilities were limited to basic vulnerability detection via open-source SAST tools. Vulnerabilities were transient, not stored in a database, and lacked auditing, making security management inefficient. As GitLab expanded its security offerings with Dependency Scanning, DAST, and a proprietary SAST tool, a scalable vulnerability management system was required to support multiple detection methods, provide better tracking, and integrate seamlessly into GitLab’s workflow.

The challenge was to create a scalable and extensible vulnerability management system while balancing engineering feasibility, user experience, and GitLab’s existing capabilities.

The goal was to design and implement a new Vulnerability Object that:

• Supports multiple security detection methods and scales over time.
• Integrates into GitLab’s ecosystem, leveraging existing components.
• Provides structured tracking, audit logs, and user-driven security actions.
• Ensures security professionals can manage vulnerabilities effectively with the right tools and workflows.

I broke the work down into themes to ensure the team could do as much in parallel as possible.

1. Understanding the space

To ensure a well-informed approach, I conducted a JTBD study with five internal security professionals and ten external users to understand how vulnerabilities were currently being managed and what improvements were necessary. I immersed myself in the security space by attending AppSec team meetings, webinars, and discussions to gain deeper insights into industry practices. This research helped clarify the pain points security teams faced when handling vulnerabilities and informed the approach to designing a scalable system.

2. Defining an extensible schema & system integration

With a deeper understanding of the space, I collaborated closely with engineers and AppSec teams to define an extensible vulnerability schema. Initially, the existing scheme only supported data from a few open-source analyzers, limiting flexibility. Through research, we discovered that security teams needed the ability to override severity ratings, maintain an audit log of actions, and attach evidence to vulnerabilities. We worked to refine the data structures, ensuring that the model was both scalable and adaptable for future enhancements.

At the same time, I worked with engineering to evaluate GitLab’s existing issue tracking system and determine how the vulnerability object could be integrated without disrupting current workflows. This led to necessary modifications in system architecture, including changes to how vulnerabilities were stored and linked to projects. We designed and tested modal updates that improved the experience for security workflows, ensuring that security professionals had a dedicated, structured way to manage vulnerabilities. User testing confirmed that vulnerabilities needed a distinct workflow separate from standard GitLab issues. Based on this feedback, we introduced audit trail functionality, allowing security teams to track vulnerability status changes over time, ensuring accountability and compliance.

3. Security Design Language

From the outset, I recognized the necessity of a security-centric design language to distinguish security workflows from other GitLab processes. I initiated the creation of a security-specific icon system that aligned with GitLab’s existing design system while ensuring clarity and usability for security professionals.

I introduced visual indicators for severity levels, vulnerability status, and security actions, ensuring that critical security insights were easily accessible.

4. Product enhancements & feature expansion

With a strong foundation in place, we developed a dedicated Vulnerability Management page that improved accessibility and streamlined tracking. The original vulnerability list view was converted into an interactive table with bulk actions, making it easier for security teams to manage large numbers of vulnerabilities efficiently.

Here are a few final deliverables: the new page layout, actions for adding a comment while dismissing, and the ability to translate severity to CVSS.

To ensure the roadmap was aligned with user needs, I conducted a KANO study, prioritizing security features based on impact and expectations. Throughout multiple iterations, we refined security dashboards and action workflows based on ongoing user feedback, ensuring that the final product met the demands of security professionals while maintaining GitLab’s usability standards.

The initiative successfully established GitLab as the first true DevSecOps platform, integrating security into the development lifecycle at scale.

Key outcomes

• $20M in ARR generated over three years.
• Increased top-tier subscription users from 500 to 28,000.
• Security professionals recognized GitLab as a viable enterprise security solution.
• Institutional biases against security-first issue types were challenged and ultimately overcome through user research and data-driven design decisions.

What I would have done differently:

• Started with organizational-level considerations before designing for asset-level security.
• Collaborated earlier with the team responsible for project management capabilities, ensuring alignment between vulnerability tracking and broader issue management.