Hi @brett.tasker, great question!
There are multiple definitions of “support” and it’s easy to get them mixed up.
The “Statement of Support” page is specific to GitLab’s paid support offering. GitLab customers with a license or subscription are entitled to receive support from GitLab Support Engineers. This document defines what we [GitLab Support team) support in terms of our products, services, and applications.
Essentially, if you’re a GitLab customer, you can expect that Support will help you with any problems or questions you have with GitLab versions 12.0 through the latest 14.x. Statement of Support | GitLab
So just wanted to have confirmation if the security fixes will be backported to these supported versions?
Our release and maintence policy state that GitLab will backport security fixes to the previous two monthly releases in addition to the current stable release.
For example, the latest GitLab Security patches are available for 14.5 (latest stable version) and they’ve also been backported to 14.4 and 14.3: GitLab Security Release: 14.5.2, 14.4.4, and 14.3.6 | GitLab
There’s an open issue to discuss whether we should extend or change the maintenance policy here:
Or if these versions should be considered vulnerable and should not be used?
GitLab versions 13.x may be vulnerable to security issues that were patched after the release of 14.2.
Using software that has known vulnerabilities is a risk that can be avoided by upgrading or mitigated by locking-down access to the instance beyond the application layer. For example, customers running 12.x or 13.x who’re unable to upgrade often mitigate risk by restricting access to the instance at the network level. A simple example would be a firewall with a DENY ALL rule that only allows traffic to/from IP addresses that you’ve intentionally added to an allowlist.
If security is a concern and your GitLab instance is public-facing (anyone on the internet can access it by typing the URL in their browser), I advise that you regularly update both GitLab and system packages regularly. If you can’t update regularly, lock down access as much as possible so that only authorized individuals/machines can access your GitLab instance.