1. You are here:
2. Engineering
3. Development Department
4. Sec Section
5. Secure Sub-Department
6. Secure, Vulnerability Research

Vulnerability Research

On this page

• Area of focus
• Common Links
• Mission
• Vision
• Priorities
• How we work
  • Ideate
  • Prioritize
  • Prototype
  • Build and Ship

Area of focus

Team members on the Vulnerability Research team normally have an area of focus where they spend most of their time. They have stable counterparts in development and product management in those areas of focus to stay aligned on direction across teams.

Team member	Area of focus	Dev stable counterpart(s)	PM stable counterpart(s)
Dinesh Bolkensteyn	Static Analysis, Composition Analysis	Vishwa Bhat (Static Analysis), Fabien Catteau (Composition Analysis)	Connor Gilbert (Static Analysis), Sara Meadzinger (Composition Analysis)
Isaac Dawson	Static Analysis, Dynamic Analysis	Vishwa Bhat (Static Analysis), Cam Swords (Dynamic Analysis)	Sara Meadzinger (Dynamic Analysis), Connor Gilbert (Static Analysis)
Julian Thome	Static Analysis, Composition Analysis	Vishwa Bhat (Static Analysis), Fabien Catteau (Composition Analysis)	Connor Gilbert (Static Analysis), Sara Meadzinger (Composition Analysis)
Michael Henriksen	Dynamic Analysis	Cam Swords (Dynamic Analysis)	Sara Meadzinger (Dynamic Analysis)
Wayne Haber (Team Manager)	Team direction	Thomas Woodham	Sarah Waldner

Common Links

GitLab Group	gitlab-org/secure/vulnerability-research
Slack Channels	#g_secure-vulnerability-research

Mission

Our mission is to advance GitLab's security offerings toward their long-term vision and to elevate GitLab's prominence in the security community. We do this by performing security research, working to improve the efficacy of GitLab's security capabilities, developing proofs of concept, publishing papers, speaking at conferences, and broadly sharing our security expertise and practical experience. You can follow updates to our brown-bag sessions and the GitLab blog (#security and #security-research tags).

Vision

Facilitate the secure stage achieving lovable maturity and supporting the best possible security assessment at the earliest possible moment.

Priorities

Vulnerability Research is a research & development team. While we do not typically develop or maintain production features, our work directly impacts the product.

Our priorities are:

1. Perform security research and develop proofs of concept that strengthen GitLab's security product offerings, focusing on advancing analyzers. Proofs of concept are split between high-confidence short-term bets that are highly aligned with the product roadmap and low-confidence long-term bets that prove out hypotheses about what our customers will need in the future, as well as new technical approaches that may be novel or unique to GitLab.
2. Maintain the advisory database(s) (Gitlab Advisory Database and GitLab Advisory Database (Open Source Edition)).
3. Carry out CVE Numbering Authority (CNA) duties. GitLab is a CNA.
4. Publish papers and write blog posts that are of interest to our GitLab users or those in the security domain.
5. Present at security and software engineering conferences to learn and improve our vulnerability research or demonstrate GitLab as a thought leader to the GitLab user base and those in the security domain.
6. Write patent applications for unique security technologies.
7. Improve the security of open source software.

How we work

Ideate

• Type of improvement: DevSecOps adoption, Revenue, Security Quality/Efficacy, Cost, Efficiency
• Publication potential: can we present, blog about, or patent this work?
• Evaluation criteria: how will we measure progress and success?
• Reviewers: Secure Product Managers and Engineering Managers
• Tracking: We use the group::vulnerability research label on gitlab-org/gitlab issues as our SSOT

Prioritize

• Success rate: Balance short-term and long-term bets
• Publication: Potential for using as a source for something public or a patent
• Timing: POC projects should always be aligned with short- or long-term product vision (as appropriate), should be developed in consultation with the product team that will eventually inherit it, and an anticipated timeline for that expected handover should be jointly understood.

Prototype

• Timebox: Short-term bets should be mature enough within three months to decide whether to continue them. The time frame for long-term bets is within six months.
• Customers & prospects: Identify those outside our team to help validate the prototypes (including coordinating with PM and UXR)

Build and Ship

The vulnerability researcher’s top priority is, as needed, to support the engineering team until the feature becomes available in GitLab. A secondary focus is to publish things publicly (blogs, talks, etc.) and file patent applications.