Development container registries must be private
<!-- Implementation issues are used break-up a large piece of work into small, discrete tasks that can move independently through the build workflow steps. They're typically used to populate a Feature Epic. Once created, an implementation issue is usually refined in order to populate and review the implementation plan and weight. Example workflow: https://about.gitlab.com/handbook/engineering/development/threat-management/planning/diagram.html#plan --> ## Why are we doing this work In GitLab 15.0, we moved the production registry for Secure analyzers from `registry.gitlab.com/gitlab-org/security-products/analyzers` to `registry.gitlab.com/security-products`. To eliminate the risk of users accessing analyzer images that are not production-ready, the development container registries under `registry.gitlab.com/gitlab-org/security-products/analyzers` will be made private. As a result, unauthorized clients will be denied access to pull images from development registries. This is being treated as a breaking change so that any users still relying on `registry.gitlab.com/gitlab-org/security-products/analyzers` have a chance to see the deprecation note for %18.0 and update their settings. ## Relevant links - https://gitlab.com/gitlab-org/gitlab/-/issues/297525+ - https://docs.gitlab.com/ee/update/deprecations.html?removal_milestone=15.0#secure-and-protect-analyzer-images-published-in-new-location List of affected registries: - ~"group::composition analysis" - Registries: - [trivy-k8s-wrapper](https://gitlab.com/gitlab-org/security-products/analyzers/trivy-k8s-wrapper) - [container-scanning](https://gitlab.com/gitlab-org/security-products/analyzers/container-scanning) - [gemnasium](https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium/) - Removal issue: https://gitlab.com/gitlab-org/gitlab/-/issues/478454+s - ~"group::dynamic analysis" - Registries: - DAST - DAST API - Fuzz API - ~"group::secret detection" - Registries: - [secrets](https://gitlab.com/gitlab-org/security-products/analyzers/secrets) - Removal issue: https://gitlab.com/gitlab-org/gitlab/-/issues/486678+s - ~"group::static analysis": - Registries: - [semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep) - [sobelow](https://gitlab.com/gitlab-org/security-products/analyzers/sobelow) - [spotbugs](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs) - [bandit](https://gitlab.com/gitlab-org/security-products/analyzers/bandit) - [brakeman](https://gitlab.com/gitlab-org/security-products/analyzers/brakeman)' - [eslint](https://gitlab.com/gitlab-org/security-products/analyzers/eslint) - [flawfinder](https://gitlab.com/gitlab-org/security-products/analyzers/flawfinder) - [gosec](https://gitlab.com/gitlab-org/security-products/analyzers/gosec) - [mobsf](https://gitlab.com/gitlab-org/security-products/analyzers/mobsf) - [nodejs-scan](https://gitlab.com/gitlab-org/security-products/analyzers/nodejs-scan) - [phpcs-security-audit](https://gitlab.com/gitlab-org/security-products/analyzers/phpcs-security-audit) - [security-code-scan](https://gitlab.com/gitlab-org/security-products/analyzers/security-code-scan) - Removal issue: https://gitlab.com/gitlab-org/gitlab/-/issues/478741+s ## Non-functional requirements <!-- Add details for required items and delete others. --> - [ ] Documentation: - [ ] Feature flag: - [ ] Performance: - [ ] Testing: - Failing security report parsing: https://gitlab.com/gitlab-org/security-products/analyzers/container-scanning/-/pipelines/1326569776/security ## Implementation plan For each analyzer project, go to the project settings, `Visibility, project features, permissions`, and switch `Container registry` to `Only Project Members`. <!-- Workflow and other relevant labels # ~"group::" ~"Category:" ~"GitLab Ultimate" Other settings you might want to include when creating the issue. # /assign @ # /epic & --> ## Verification steps <!-- Add verification steps to help GitLab team members test the implementation. This is particularly useful during the MR review and the ~"workflow::verification" step. You may not know exactly what the verification steps should be during issue refinement, so you can always come back later to add them. 1. Check-out the corresponding branch 1. ... 1. Profit! -->
issue