Rename feature: DAST API to API Security Testing
What change is being made?
This MR renames DAST API to API Security Testing. API Security Testing is the feature, which lives within the API Security category.
Current state
- Category: API Security
- Features: DAST API
Future state
- Category: API Security
- Features:
- API Security Testing (formerly DAST API)
- API Discovery
- API Inventory
- API Audit
- API Risk Scoring
Why is this change being made?
Today, our customers and our sales teams have a challenging time differentiating between the Dynamic Analysis features --DAST API, proxy-based DAST, browser-based DAST. We learned from various calls and via interactions in Slack and in GitLab issues that having numerous adjacent features that include "DAST" confuses people, and we believe that this may have contributed to lower feature adoption. By renaming DAST API to API Security Testing, we will:
- Better conform to GitLab's feature naming guidelines
- Reduce confusion (and help increase feature adoption) by:
- Having as few words as possible
- Clearly expressing what the feature is
- Align the feature to industry-wide naming conventions. Today, GitLab is the only company using "DAST API" terminology, whereas "API Security Testing" is commonly used by numerous vendors (Synopsys, Noname, Salt, Cequence, StackHawk, Snyk, Checkmarx, etc.).
- Improve positive perception of API Security and reduce any negative association related to the perceived difficulty/complexity of using DAST products.
- Align to Analysts' naming expectations:
- Gartner identifies "API Security Testing" as one fundamental pillar of API Security
- On a recent call with Dan Kennedy from 451, he stated that "API Security Testing" is a better name than "DAST API"
When GitLab originally named the feature DAST API (~2020), customers were looking for DAST solutions that could be applied to either web applications or APIs. More recently, that has shifted and customers are now looking for API Security Testing solutions. API Security Testing is a market that is growing exponentially, while the market for DAST is not. Aligning ourselves to the growing market, and moving away from the GitLab-specific term "DAST API," will help us increase our API Security market share.
Process
Process for Renaming Features (handbook)
Approvals
Merge requests with changes to stages and groups and significant changes to categories need to be created, approved, and/or merged by each of the below:
-
Chief Product Officer @david
(post MR link in chief-product-officer once all others have approved) -
PLT Leader relevant to the affected Section(s) @hbenson -
The Product Director relevant to the affected Section(s) @sarahwaldner -
The Group Engineering Manager relevant to the affected Section(s) @twoodham -
The Engineering Director relevant to the affected Section(s) @wayne -
Director of Product Design @vkarnes
**Note:**_ Chief Product Officer approval should be requested once all other approvals have been completed. To request approval, post the MR link in the #chief-product-officer channel tagging @david
and cc'ing @Gena Schwam
._
The following people need to be on the merge request so they stay informed:
-
Chief Technology Officer @joergheilig -
Development Leader relevant to the affected Section(s) @bmarnane -
VP of Infrastructure & Quality Engineering @meks -
VP of UX @david -
Director of Technical Writing @susantacker -
Engineering Productivity @gl-quality/eng-prod -
The Product Marketing Manager relevant to the stage group(s) @dsteer
After Approvals and Merge
-
Create an issue in the gitlab-org/quality/triage-ops
project to update GitLab Bot automation:- for Category change
- for Stage or Group change
- If label migration is required, please follow the self-serve instructions to get started on a one-off label migration MR
-
Open an MR in the gitlab-org/gitlab
project to update any reference of the previous group label to the new one -
Mention the product group Technical Writer to update the documentation metadata -
Share MR in #product
,#development
, and relevant#s_
,#g_
, and#f_
Slack channels