Skip to content

Set secret push protection enabled to true for public projects

What does this MR do and why?

This is part of the plan to make SPP available to free and premium users for public projects on Gitlab.com. Issue: #551949

This MR enables Secret Push Protection (SPP) automatically for public projects on GitLab.com. When a project is created as public or changed to public visibility, project.security_setting.secret_push_protection_enabled = true and SPP is automatically enabled. When a project is created as private/internal or project visibility is changed to private/internal, project.security_setting.secret_push_protection_enabled = false SPP is automatically disabled.

A future MR will update the license checks to actually run SPP scanning (MR: !208036), and a different future MR will handle UI/UX (MR: !208029); this MR only handles the setting management.

Queries

This uses update! on a single ProjectSecuritySetting record during project visibility changes. Not sure that a database review is entirely necessary, but posting the query plans below anyway:

UPDATE project_security_settings 
SET secret_push_protection_enabled = [true/false], updated_at = NOW() 
WHERE project_id = 123
{"QUERY PLAN"=>"Update on project_security_settings  (cost=0.15..2.17 rows=0 width=0) (actual time=0.058..0.059 rows=0 loops=1)"}
{"QUERY PLAN"=>"  ->  Index Scan using project_security_settings_pkey on project_security_settings  (cost=0.15..2.17 rows=1 width=15) (actual time=0.018..0.019 rows=1 loops=1)"}
{"QUERY PLAN"=>"        Index Cond: (project_id = 23)"}
{"QUERY PLAN"=>"Planning Time: 0.067 ms"}
{"QUERY PLAN"=>"Execution Time: 0.078 ms"}

Feature Flag

This change is behind the auto_spp_public_com_projects feature flag, disabled by default.

SaaS Feature

This change uses the auto_enable_secret_push_protection_public_projects SaaS feature (ee/config/saas_features/auto_enable_secret_push_protection_public_projects.yml) to ensure it only applies to .com (not SM or Dedicated instances).

References

Screenshots or screen recordings

Before After

How to set up and validate locally

Test on self-managed (should NOT enable SPP)

  1. Remove your Ultimate license (if present)
  2. Create a public project
  3. In rails c: p = Project.last p.security_setting.secret_push_protection_enabled
  4. Should be false

Test on .com simulation (should enable SPP when feature flag is on)

  1. gdk stop
  2. Restart gdk with GITLAB_SIMULATE_SAAS=1 gdk start, which runs gdk in .com/SaaS mode.
  3. In rails c, enable the feature flag: Feature.enable(:auto_spp_public_com_projects)
  4. Test project creation:
  • In the UI, create a public project
  • In rails c, p=Project.last, p.security_setting, p.security_setting.secret_push_protection_enabled
  • Should be true
  • In the UI, create a private project
  • In rails c, p=Project.last, p.security_setting, p.security_setting.secret_push_protection_enabled
  • Should be false
  1. Test visibility changes:
  • Change the public project to private via UI (Settings > General > Visibility dropdown)
  • In rails c, p.reload, p.security_setting.secret_push_protection_enabled
  • Should be false
  • Change the project back to public
  • In rails c, p.reload, p.security_setting.secret_push_protection_enabled
  • Should be true

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Serena Fang

Merge request reports

Loading