GitLab Security Is Not The Problem – The Network Model Is
Businesses who use NetFoundry’s Ziti platform to secure GitLab can be on the beach with a cocktail if they feel like it. Because GitLab CVE-2024-45409 is a non-event to NetFoundry customers, despite being severity score 10.0 for the rest of the world.
Sure, at some point these NetFoundry-protected businesses should patch their self-hosted GitLab instances (GitLab patched their cloud-hosted version). But in the meantime, the attackers can’t exploit the bug. By design. Enjoy the sunset, work on your more important opportunities or problems, and then patch your GitLab.
Why GitLab CVE-2024-45409 is a Non-Event for NetFoundry Customers
TL;DR: NetFoundry’s solution means an attacker can only reach the GitLab server if the attacker either:
- Walks into the right data center and consoles into the right server.
- Gains physical control of an authorized GitLab user and their device.
Do you remember the last major breach caused by one of those factors? The GitLab CVE is a snoozer for NetFoundry customers because attackers can’t exploit the bug from the networks – with NetFoundry’s solution, the GitLab server is not reachable from the underlay network.
When you log in to your bank application on your mobile phone via facial or fingerprint recognition, modern cryptography secures your connection and it is mainly invisible to you as an end user. That’s what NetFoundry has done with our reinvention of networking. Simultaneously strengthened security, while getting it out of the way of users and administrators. Bugs like GitLab CVE-2024-45409 a non-event for the businesses who use NetFoundry to secure their self-hosted GitLab, but the NetFoundry reinvention of networking means that user and administrator experience is not compromised on the process.
The same solution secures all your self-hosted software, including all of its APIs, webhooks, pipelines and server-to-server workloads. But let’s use GitLab as an example since they are in the news for the wrong reasons.
We Need Resiliency – To Flip Networks From Aiding Attacks To Preventing Them
To get to GitLab and exploit a bug, you need two things:
- Network access
- GitLab access
Let’s start with GitLab. GitLab itself has stronger security. You’ll need to identify, authenticate, and authorize. Most of the time this is fine. But sometimes a bug arises – this is more of a ‘when’ than an ‘if’. CVE-2024-45409 is one of those times.
So this is where the other security layer enters – the network. In a resilient, multi-layer security solution, the network would not let attackers get to GitLab to exploit its bug. But today’s network model is inherently insecure – as we saw with GitLab, the attackers are able to get to the GitLab server.
It is tempting to say the bug is the root cause. It isn’t. The bug is a proximate cause or a symptom of a bigger problem. Our jobs are to design enough resiliency to make those bugs as unimpactful as possible, because they are inevitable.
Why We Need More Than GitLab Security
So what is the root cause? There is no resiliency. The root cause is the network itself is default insecure, and has no mechanism to fully identify, authenticate and authorize your session. Think of GitLab as the flight gate at the airport. Before you can get to the gate, you need to pass airport security to get into the terminal. For GitLab, and all networked applications, the equivalent of airport security is the network. But the network does not have strong security – you can stroll up to the GitLab ‘flight gate’ and walk right in if there is a bug. We don’t have resiliency—all eggs are in the GitLab security basket. Crazy? Only kind of.
It is not that crazy because network security is an oxymoron. Bolt-ons like VPNs, ZTNA, SASE, IdPs, and SD-WANs are expensive and complex. They block business velocity, agility, and extensibility. And they often aren’t very secure because they are bolted on top of inherently insecure TCP/IP networks. They are not much better than public Internet because the firewall in front of GitLab still needs to let certain ports, IPs, and VPN endpoints enter, and that is where the problem is. In short, VPN and ZTNA solutions fall short.
The Reinvention of Network Security
But what if we had a better way? Network security which actually improves velocity. A networking model which adds resiliency and prevents exploitations of bugs such as GitLab CVE-2024-45409, and the invariable scramble to patch it while you race against the entire Internet who can now exploit it. You’d need to invent a new networking model.
So that is what we did at NetFoundry. And we cheated. Network security is an oxymoron if you are bolting on top of an inherently insecure network. So, we reinvented the entire network model as software, with the security built-in. Rather than build yet another network security solution, we invented a secure network model. The network is now secure-by-design software. Let’s unpack that:
- Reinvented the network as software means you spin up secure-by-design overlay networks in minutes, with no hardware dependencies. Like spinning up a VM or container. Run it in your environment, run it in ours, run it in both. Software. You can use a NetFoundry free trial to spin up a network in less time than it would take you to read this article. You can get under the hood to see for yourself with NetFoundry’s open source, OpenZiti.
- Secure-by-design networks knows if a specific session is identified, authenticated and authorized, all the way up the stack to application-specific authorization, before the session is allowed to even get on the overlay network – the attacker can’t get to the GitLab server, and can’t even get on the overlay network. It would be like trying to get through airport security with no verifiable identity and no valid flight ticket.
Unreachable is less breach-able
Why was last week’s GitLab CVE a maximum severity bug for the rest of the world, but a snoozer for businesses who use NetFoundry to secure their GitLab? Â
It is because there is only one root cause of all major cybersecurity breaches: the network model. TCP/IP networks are inherently insecure, and bolting security on top of them doesn’t put the genie back in the bottle. GitLab had a bug, but the bug is only relevant because attackers exploit it via the enterprise network.
NetFoundry overlays add the security layers which TCP/IP doesn’t have, while being software-only overlays which go anywhere that applications go, without any dependencies. This new network model addresses the root cause of every major cybersecurity breach – including GitLab CVE 2024-45409. With NetFoundry, GitLab is not reachable via the underlay networks, even when GitLab does have authentication or authorization bugs.
