Is Git Safe for Government Agencies on an Internal Network? What the Public Record Says

"Git is cloud-based. We run an air-gapped network, so we can't use it."

I hear this fairly often in public-sector meetings, and it's a fair question. Source code is among the most sensitive assets an agency holds, and being careful about replacing a tool that has run without incident for close to twenty years is exactly right. Developer forums had the same argument in 2024, with rebuttals and corrections going back and forth until the thread fizzled out. So this time I decided not to answer from intuition. I went through the official Git and SVN documentation, government announcements, procurement documents, and CVE advisories one claim at a time.

The answer first. Git deployed on an internal network can be operated safely by a government agency. The government itself runs it that way, a high-security financial institution has procured closed-network GitLab, and the national e-government framework lists Git as a standard tool. There are two things to settle at the design stage when moving over from SVN, and both have known solutions. This post lays out the evidence, those two decisions, and a list of questions you can use directly in a security review.

Does Git require the internet?

No. Git is version control software, and it runs on an agency's internal servers over SSH, HTTP(S), or local paths. Nothing in the official Git protocol documentation assumes an external cloud. GitLab also publishes official installation procedures for fully offline, air-gapped environments.

I can guess where the misconception comes from. For many people, their first experience of Git was GitHub, so "Git = GitHub = external SaaS" gets fused into one memory. But that's structurally the same as saying "to use email you must use Gmail." A protocol and a hosting service are different layers, and that distinction is the single most important thing in this whole debate.

With SVN the source stays on the server, but with Git it leaves?

It leaves in both cases. An SVN checkout copies source to the developer's PC. That is what checkout means. The SVN working copy even keeps a pristine cache of the originals locally, alongside the working files, as documented in the Apache SVN 1.8 release notes.

"Centralized" means the canonical history lives on one server. It does not mean developers work without file copies; no copies, no development. So whichever tool you use, what needs protecting is the same: the server and the endpoints, both.

Is the Korean public sector actually using Git?

Yes. No blanket rule banning Git turned up in the public record, and three cases run directly by the government did.

The Ministry of the Interior and Safety's public GitLab. On July 2, 2026, the ministry announced its "AI Government Lab," stating that project documents, source code, and prompts would be managed on a public GitLab instance. A July 22 follow-up explicitly says development deliverables are registered and managed there.

A closed-network GitLab procurement by the Korea Financial Telecommunications & Clearings Institute (KFTC). Its June 2025 RFP specifies GitLab Premium for 250 users, deployment on an internal closed network, on-premises cloud, security review obligations, and a special contract clause on source-code leakage and vendor liability. A high-security institution has already worked out how a closed-network Git platform, access control, and accountability fit together.

The eGovFrame standard framework. The eGovFrame 5.0 configuration-management guide describes SVN and Git side by side as the representative version control tools.

To be precise, these three sources do not mean "Git is approved everywhere." The ministry case started as a pilot on the internet-facing network, with expansion to the government business network planned for 2027. If a specific project contract designates SVN, the contractual change process still has to be followed. But the generalization "Git is simply not allowed in the public sector" does not hold up against these documents.

Policy is heading the same direction. KISA's National Network Security Framework (N2SF), announced June 17, 2026, classifies business information as classified, sensitive, or open and applies security levels per grade. It judges by information grade and processing location, not by tool name.

What does internal-network Git need in order to be safe?

To keep the same level of control you had with SVN, two things need to be decided at the design stage. Fudging them would undermine everything above, so here they are as they stand.

1. Decide how much history lands on developer PCs

A default Git clone brings not just the current files but the entire reachable history. Code deleted in the latest version still exists in past commits. SVN delivers only the working copy of the selected revision by default. During verification I reproduced this on a local dummy repository with no external access, Git 2.51.1:

• Commit a file, delete it, then clone: gone from the working tree, readable from the past commit
• Sparse checkout showing only one folder: the other files disappear from view but remain readable via Git object queries
• Shallow clone at depth 1, then an unshallow fetch: the history count grew right back

So if the same endpoint is compromised, the scope of what could be exposed is wider on the Git side. That says nothing about the probability of a breach. And the response is clear: keep endpoint security at the level you already had for SVN, and set the rule that a secret found in an old commit is handled by revoking and rotating the credential, not by deleting the file. GitHub's own guidance on removing sensitive data prescribes the same order. On a closed network, the paths by which history could leave an endpoint are already controlled, which shrinks this item further.

2. Move per-folder read permissions to repository boundaries

SVN's path-based authz can split read permissions by path within a single repository: contractor A reads only frontend, contractor B reads only backend. Standard Git grants read access per repository. Git's own documentation states that namespaces are not a read access control mechanism and recommends putting data that must stay hidden in a separate repository.

The solution is to split repositories along trust boundaries. Wherever your current SVN authz draws a line, draw a repository boundary there instead. I covered that migration design in moving from lock-based SCM to Git. Running the affected repositories on SVN in parallel until the split is designed is a perfectly reasonable order of operations. Nothing has to move all at once.

Can't we just compare CVE counts?

Both sides have real vulnerabilities, so counts don't settle it. The Git project published CVE-2025-48385 on July 8, 2025: a bundle-URI feature where a malicious remote could manipulate file write locations, with fixed versions and preconditions stated in the advisory. Apache published CVE-2024-46901 for SVN's mod_dav_svn, a denial-of-service via control characters in paths, fixed in 1.14.5.

Exposure surface, install base, reporting practices, and patch velocity all differ, so CVE counts cannot rank the two tools. What these two cases show is that whichever tool you run, a patch-intake process is a hard requirement of closed-network operation, and any agency already running SVN has that process in place.

What should a security review actually ask?

Instead of a tool name, separate four layers.

"Git or SVN" touches only the first layer. The paths in real leak incidents mostly run through the other three: a compromised developer PC, an authorized insider exfiltrating, stolen accounts and tokens, secrets left in old commits. When I mapped threat scenarios against both tools, almost nothing was Git-only; most differences reduced to "both are possible, Git's history scope is wider."

Four questions you can use in the review room:

• Is the thing being restricted the Git program itself, an external code-hosting service, or the scope of endpoint replication? Which document says so?
• In the current SVN setup, who can read which paths and which past revisions? Does a Git migration widen that scope?
• What are the approved storage locations and actual egress paths for source, history, build artifacts, and prompts?
• When an incident happens, what evidence identifies the authenticated user, the downloads, the approval changes, and any external transfer?

One note on that last question. The author field on a Git commit is a configuration value, so by itself it is not proof of identity. Accountability comes from server-side authentication and access records, and a self-managed Git platform keeps those by default. As the KFTC RFP shows by writing vendor and administrator liability, data return, and disposal into a special clause, records and accountability can be designed in alongside adoption.

How we answer this question

CollabOps is Git-based and treats closed-network installation as a first-class deployment shape. When we hear "it's Git, so no" in a meeting, this is the answer we actually give.

Git does not presuppose an external cloud and can be deployed on an agency's internal closed network. Because its distributed model replicates history into development environments, set endpoint controls and a credential-rotation rule alongside it, and move SVN's per-folder read permissions to repository boundaries. On top of that, verify the code's classification grade, storage and processing locations, egress controls, access records, and operational accountability, and you have the same level of safety you had with SVN.

The second half of that answer is close to why our product exists. Of the four layers above, operations and evidence is the one that falls apart when assembled from separate tools: issue tracker here, repository there, CI somewhere else, audit collection bolted on, with the evidence breaking at every seam. When the repository, change requests, pipelines, and deployment records live on one plane from the start, "who approved this and what shipped" accumulates as a byproduct of doing the work. That record is exactly what a security review asks for.

Of course, "it's self-hosted, so it's safe" is the same fallacy of claiming safety by tool name. Proving full offline operation, repository read separation, migration of existing SVN authz permissions, account and key revocation, and handling of secrets in past history is the vendor's job, with actual tests and evidence; the verification report organizes this into 14 inspection items. The principle that whoever claims a control must be able to demonstrate it applies to us just as much.

If you're the security officer who has run SVN incident-free on a closed network for years, keep asking these questions. How a vendor should answer them is where "We're happy with SVN, why switch?" picks up. What to demand isn't a tool's name but evidence from verification, and internal-network Git is a configuration that can produce that evidence.