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