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) |
|---|---|---|---|
| Mark Art | Sec direction | Thomas Woodham, Thiago Figueiró | Hillary Benson |
| Dinesh Bolkensteyn | Static Analysis | Zach Rice | Connor Gilbert |
| Isaac Dawson | Dynamic Analysis | Cam Swords, Philip Cunningham, Craig Smith | Derek Ferguson |
| Julian Thome | Static Analysis, Composition Analysis | Zach Rice (Static Analysis), Fabien Catteau (Composition Analysis) | Connor Gilbert (Static Analysis), Samuel White (Composition Analysis) |
| GitLab Group | gitlab-org/secure/vulnerability-research |
| Issues Board | board |
| Slack Channels | #g_secure-vulnerability-research |
Vulnerability Research is a research & development team. While not being a product team, our work directly impacts the product. Our mission is to perform security research and develop proofs of concept that increase the capabilities and effectiveness of the Sec section. Additionally, the team's mission is to share security expertise and practical experience. To learn more about the latter, you can follow updates to our brown-bag sessions and the Gitlab blog (#security, #security-research, #vulnerability-research tags in particular).
Vulnerability researchers spend ~80% of their time on proofs of concept and free-form research in their areas of focus, working closely with their stable counterparts in development and product management. 20% of their time is split between Keeping the Lights On and free-form research that may be outside their areas of focus.
The vulnerability research team seeks to internally validate all proofs of concept. Successful iterations of developed tools that are aligned with Sec Section product roadmap can then be transitioned into the product and made available to the wider GitLab community.
The Application Security team plays a key role in this process by a) providing insight into user needs via their direct experience managing the security program at GitLab), and b) by being the first customer to try out proposed security capabilities.
The Vulnerability Research team uses the standard priority labels to determine priority, however those may carry a different meaning compared to the usage in product teams:
| Label | Color | Meaning |
|---|---|---|
~priority::1 |
red | The most critical task. Normally, only hull breaches should prompt a P1. Synonymous with incident. Examples: CNA/GemnasiumDB automation broke and needs to be fixed ASAP. |
~priority::2 |
orange | Top-priority work. |
~priority::3 |
yellow | A "roadmap" item. Large projects that we work on for months fall into this category. |
~priority::4 |
green | Tasks like discovery, nice-to-have PoCs, anything that we won't loose much by letting it sit there in the backlog. |
Any unlabeled issues are considered unprioritized, i.e. lowest-priority backlog.
