So, we use Tenable Security Center to scan for vulnerabilities and such. One of the findings it picked up on is that Gitlab is using an older version of Nginx and it wants us to upgrade to at least 1.20.1.
However, since Nginx is bundled, it doesn’t seem that this will be so straight forward.
Is this even possible? Does Gitlab have plans to release an update for the bundled Nginx? Any information regarding the specific reasoning behind the version of nginx Gitlab is running currently?
I really love it when these security scanners get hung up on the version number - when really what they should be concentrating on is whether the actual version installed has vulnerabilities. However, I cannot say that for sure, since you didn’t mention why Tenable Security Center/Nessus recommended the upgraded version in the first place.
here are a list of vulnerabilities, and obviously Nginx 1.18 does feature in some of them. More important is, not whether Gitlab, or a Linux distro is running the latest version - but rather, that vulnerabilities in the version installed are addressed during updates etc. For example, Debian 10 has Nginx 1.14, RHEL7 for example 1.16. Since these are stable distributions, they will not release the latest and greatest Nginx, but rather patch the version they released.
The same would also apply for any other applications, bundled or what be it, like Gitlab, addressing those by patching at a minimum or potentially upgrading to a later version in the near future.
Providing Tenable Security Center didn’t find any critical vulnerabilities, and as long as vulnerabilities are addressed by Gitlab, then the fact that 1.18 is installed instead of 1.20 should be a non-issue. @dnsmichi posted something earlier on the forum:
therefore if you find a vulnerability with your scanner, you can disclose it responsibly by following the link in the above post or directly here: Coordinated Disclosure Process | GitLab
I understand what you’re saying. Unfortunately for us, security office doesn’t see it the same way. They just know there is a finding and want it resolved :(.
Is there any vendor documentation for why they are still on nginx 1.18 I could reference?
You can always have more control with a source installation:
since then it either requires installing Nginx from the distros package registry, or in your case, building 1.20 manually and installing to resolve the issue. It would also be possible to create deb packages and install using apt for the 1.20 version as well, if a repo doesn’t exist already which provides Nginx directly without the need for compiling. So you can solve your problem this way if you like, but it will be very time-consuming.
There isn’t any documentation on why they are still on Nginx 1.18. It’s not that old a version anyway, especially when you consider what I mentioned already about Debian/RHEL. Nginx 1.18 was released April 2020. And as I said, what should be being addressed is the vulnerability, and not the version itself. Since you are using Tenable, then this is using Nessus - so the scanner can use SSH credentials to actually login to the server and correctly identify what is installed and if there are vulnerabilities. This is by far more accurate, than just scanning without the ability to SSH into the server to verify everything properly. Just because it says it’s 1.18 and not the latest, doesn’t mean there is an issue. But I don’t know what your scan results are, and if the scan actually allows Nessus to SSH to the server and verify everything 100% instead of potentially showing a false-positive.
For stability reasons, a lot of distros, as well as application developers will remain on a previous release until sometime in the near future where they will move to a new release.
Thanks for submitting this post and welcome to the GitLab forum, @jadams! @iwalker your insightful comments are also very much appreciated, thank you for contributing here!
There’s actually a publicly visible issue tracking the effort to upgrade Nginx to >= 1.20.1.
Although we believe there likely isn’t much impact to GitLab’s out-of-the-box configuration here, we’re still working to get this upgrade done as soon as possible. The SLA for a severity::3 vulnerability like this one is 90 days, but I wouldn’t be surprised if we address this quite a bit sooner than that.