Generic Secrets (GA)
## Summary
We are adding detection for unstructured secrets, passwords, and other secrets. This expands our overall scope of detection, since these secrets can't be found using our current detection ruleset that relies on secrets being formatted in particular ways.
New detections will include secrets like:
- JWTs and other tokens
- Generic passwords (with enough contextual indicators to suggest that they are truly passwords)
- API tokens that do not use a well-identifiable prefix or other type
This detection technique can also detect secrets that _could_ have been identified with a pattern-based rule, but for which we lack a rule.
## Metrics
- **Direct result:** Improved secret-detection recall, as measured by:
- Meaningful improvement in recall (FN rate) on secret-detection benchmarks
- With acceptable impact on precision (FP rate)
- Favorable or near-peer performance compared to specific customer examples
- **Indirect results:**
- Reduced escalation rate related to false-negative results
- Improved performance on POVs, leading to:
- Improved First Order win rate
- Improved Ultimate retention, due to improved adoption of Secret Detection
<details>
<summary>Product Prioritization details</summary>
#### Product Prioritization Justification
As of September 2025, [several](https://gitlab.com/groups/gitlab-org/-/epics/18504#note_2745394933) of our large GitLab Ultimate customers are requesting enhanced secret detection coverage beyond our current default ruleset. In addition, there are [numerous support tickets](https://gitlab.com/gitlab-org/gitlab/-/issues/559970) around this friction point. These organizations frequently encounter unstructured secrets that cannot be identified through our existing regex-based scanner.
Currently, we address these gaps by directing customers to create custom detection rules. However, this approach presents significant challenges: configuration is time consuming, requires ongoing maintenance overhead, and custom regex patterns often generate excessive false positives that erode user confidence in GitLab's secret detection. Further, you can’t get to the point of customizing if you don’t adopt the tool in the first place. _We need to stop having coverage conversations._
In analyzing customer requests from [Custom Push Protection Rules](https://gitlab.com/groups/gitlab-org/-/epics/17997#top) from customers, they are trying to solve these specific problems:
* **Prevent generic secrets from leaking in the code** - Basic secret patterns like PASSWORD=”\<thepassword\>”, PWD are not detected. **_Requires generic secret detection._**
* **Password hash (and encryption) detection**- Specific need to catch password hashes in common formats. We’ve also heard requests to detect passwords that are encrypted. **_Requires generic secret detection._**
By prioritizing generic secret detection over other initiatives like &18327+, we can deliver comprehensive coverage for the most commonly requested secret types when a customer onboards. This proactive approach will establish trust early in the customer journey, accelerate feature adoption, and ensure users are immediately protected against the most prevalent types of credential leaks without the burden of custom rule management.
</details>
#### Engineering Assessment
1. ~"group::vulnerability research" [developed](https://gitlab.com/groups/gitlab-org/-/epics/18410#note_2818240010) a POC for this in ~"FY26::Q3". We did [an evaluation](https://gitlab.com/gitlab-org/gitlab/-/work_items/581282) on this POC and found there is still a significant amount of work needed in order to get this production ready.
2. ~"group::secret detection" is picking up the improvements needed to the POC in ~"FY26::Q4" via https://gitlab.com/groups/gitlab-org/-/work_items/18502+
- **Update:** We've [completed](https://gitlab.com/gitlab-org/gitlab/-/work_items/585297#note_3055405501) a rewrite of generic secrets (borrowing some elements from the POC) and we're now able to capture generic secrets with **\~89% precision and \~81% recall**, including the scenarios that customers expected GitLab Secret Detection to detect
3. Fine-tune precision and recall - we need to run generic secrets scan on a larger dataset and tune as per the false positives/negatives.
4. Develop new analyzer based on unified scan engine client ~"FY27::Q1"
- Requires support from Product and UX on rollout strategy
5. We still need support from Product on determining the strategy for how these findings will be displayed in the UI, as well as the accompanying workflows, views, schemas that need to be updated in order to make this a usable feature for customers. Some of this discussion has started in https://gitlab.com/gitlab-org/gitlab/-/issues/577325+, but we need to ensure we have these decisions made early in ~"FY27::Q1" in order for us to deliver this in a timely manner.
#### Open product questions
1. How should we differentiate high-confidence regex-based findings from these?
2. What changes need to be made to the security report schema in order to support the appropriate context fields for generic secret findings?
3. Will we be providing a configurable option for customers to disable generic SD if they don't want the added noise? If so, will this be a dependency on config profiles?
#### Dependencies
- Team dependencies:
* https://gitlab.com/groups/gitlab-org/-/epics/18502+
* https://gitlab.com/groups/gitlab-org/-/epics/18503+
* https://gitlab.com/groups/gitlab-org/-/epics/17911+
- External dependencies:
* May need ~UX support depending on the product strategy that is defined.
* May need support from ~"group::security insights" depending on the product strategy that is defined.
#### DRIs
- **PM**:
- **EM**: @amarpatel
- **UX/PDM**:
- **Group(s)**: ~"group::secret detection"
- **Engineering Owner**: @rvider
epic