A partner’s security team sent us a finding: “Your self-hosted GitLab at
git.zupermicro.com is reachable from the public internet.” They rated it High. We rated it
“working as intended,” and I promised to explain why, which is how this post came to exist.
The short answer is that the GitLab is not on the internet. The internet is on the GitLab.
The longer answer: the server sits on our partner VPN, which is where it belongs. In 2019 a contractor needed to reach it from a hotel, and the hotel’s Wi-Fi blocked our VPN, so somebody added a port forward “for the weekend.” The weekend ended. The port forward did not. By the time anyone noticed, three CI runners, a deploy script and the HL7 bridge all reached the GitLab through the public name, and turning it off would have broken the nightly exports.
You might say, “Then put it behind single sign-on.” It is! The sign-in page is right there at
/users/sign_in. You just have to have an account, and accounts are only issued to employees, partners,
the contractor from the hotel, and anyone who registered before we turned off sign-ups in 2021.
You might also say, “At least keep it patched.” We do keep it patched, in the sense that it has
patches. We pin the version deliberately. Every GitLab upgrade renames something our CI depends on, and the last
time we upgraded, the merge request API started returning a field called draft where it used to say
work_in_progress, and the release pipeline decided every merge request was finished. We shipped a
Tuesday’s worth of half-written code to staging. Since then, upgrades require a change advisory board, and the
change advisory board has not met since the person who scheduled it went on parental leave.
So the GitLab is reachable, pinned, and signed-in. Those are three different properties, and only one of them is the one the finding was about.
Bonus chatter: The partner’s security team re-rated the finding to Medium after reading a draft of this post. I am choosing to count that as a win.