## Summary This issue is to roll out the Phase 1 feature on production, that is currently behind the `dependency_firewall_phase1` feature flag. The Dependency Firewall feature allows organizations to control and restrict which external package dependencies can be used within their projects. It acts as a security layer between developers and external package registries, enabling policy-based blocking of untrusted or vulnerable packages. ## Owners - Most appropriate Slack channel to reach out to: `#g_sscs-dependency-firewall` ## Expectations ### What are we expecting to happen? Users will be able to: - Enable the dependency firewall for their GitLab instance or group - Define policies to allow or block specific packages from external registries - Receive feedback when a blocked dependency is requested during a build ### What can go wrong and how would we detect it? - **Policy evaluation failures**: Packages being incorrectly blocked or allowed due to misconfigured rules. Check job failure rates and firewall policy logs. - **Performance degradation**: Increased latency on package download requests due to firewall evaluation overhead. Monitor response times on package registry endpoints. - **Database performance**: Potential slow queries when evaluating firewall rules at scale. Monitor database performance metrics. ## Rollout Steps Note: All `/chatops` commands that target production must be executed in the [`#production` Slack channel](https://gitlab.slack.com/archives/C101F3796) and cross-posted (with the command results) to `#g_sscs-dependency-firewall`. ### Rollout on non-production environments - [ ] Enable on staging: `/chatops run feature set dependency_firewall_phase1 true --staging` - [ ] Verify the feature works as expected on staging-canary - Test enabling the dependency firewall for a group or project - Test that blocked packages are correctly rejected during a build - Verify that allowed packages pass through without issues ### Rollout on production - [ ] Enable for `gitlab-org/gitlab`: `/chatops run feature set dependency_firewall_phase1 true --project=gitlab-org/gitlab` - [ ] Monitor for 15+ minutes, verify no issues - [ ] Enable for 25% of projects: `/chatops run feature set dependency_firewall_phase1 25 --actors` - [ ] Monitor for 15+ minutes - [ ] Enable for 50% of projects: `/chatops run feature set dependency_firewall_phase1 50 --actors` - [ ] Monitor for 15+ minutes - [ ] Enable for 75% of projects: `/chatops run feature set dependency_firewall_phase1 75 --actors` - [ ] Monitor for 15+ minutes - [ ] Enable globally: `/chatops run feature set dependency_firewall_phase1 true` - [ ] Monitor for at least one day ### Release the feature - [ ] Create a merge request to remove the `dependency_firewall_phase1` feature flag - Remove all references to the feature flag from the codebase - Remove the YAML definitions for the feature from the repository - [ ] Once the cleanup MR is deployed, delete the feature flag: `/chatops run feature delete dependency_firewall_phase1 --dev --pre --staging --staging-ref --production` - [ ] Close this rollout issue ## Rollback Steps - [ ] Disable on production: `/chatops run feature set dependency_firewall_phase1 false` - [ ] Disable on staging: `/chatops run feature set dependency_firewall_phase1 false --staging`