Customers interested in Secret Push Protection
Background
We are developing Secret Push Protection (formerly named pre-receive secret scanning) ( &11439). It blocks certain types of secret leaks before commits are pushed to GitLab. This essentially prevents leaks from happening in the first place—they never escape the developer's machine.
This is a new feature, and one that involves hooking into a performance-critical part of GitLab—the path where commits are received and processed. Because of that, we are:
- Carefully testing and monitoring for performance and reliability impacts.
- Rolling out the feature incrementally.
Testing opportunities
We will have opportunities to try this feature before it reaches General Availability:
- We will begin by testing and monitoring on GitLab-internal projects only. At this point, the feature may still be in Experiment status.
- We understand the level of customer interest, but this provides us the most direct way to troubleshoot and make system changes as necessary.
- Next, we intend to offer GitLab.com customers the option to opt-in. At this point, the feature will be in Beta status.
- Epic: Make Secret Push Protection available in Beta o... (&12729)
- We will recommend starting with test projects to provide feedback on how the feature works, then moving on to other projects if the customer wants to continue testing pre-GA.
- We do not recommend testing in production projects—that is, projects that would have a significant impact on an organization's productivity if they were to be impacted by a problem with the feature (momentary or persistent).
- We recommend communicating about the feature with teams that could be affected by testing, and identifying internal Points of Contact who can disable the feature if necessary.
- After conducting enough testing on GitLab.com, we will make the feature available for opt-in in self-managed and recommend a similar incremental testing approach for self-managed. The feature will still be in Beta at this time.
- We will not encourage this testing earlier because:
- GitLab team members can't directly monitor self-managed instances.
- We can't push updates to self-managed instances as quickly as we can to GitLab.com.
- We will not encourage this testing earlier because:
After this, we will prepare for General Availability and release the feature as GA.
Interested?
Interested customers can be listed in this issue. Please use internal/confidential notes if able.
Customers who wish not to post directly, or can't post internal/confidential notes, can ask their account team to post on their behalf.
Please include:
- Salesforce link (if you are a GitLab team member).
- Whether the customer is on GitLab.com, self-managed, or Dedicated.
- Whether the customer is interested in testing when the feature is still in Beta (pre-GA) or only waiting for GA.