How Much of "Git Is Risky, SVN Is Safe" Holds Up? An Operations Comparison Table

Conversations about source control in government agencies tend to turn into a security comparison of Git and SVN. I recently came across the explanation again: SVN keeps code on an on-premises server, so leaks are hard, while Git is cloud-based, so leaks are possible. Two separate problems are tangled together in that sentence. Where the repository runs, and what data gets replicated to developers.

The question of whether public-sector organizations may use Git at all, answered with government deployments and procurement records, has its own post: Is Git safe for government agencies on an internal network?. This post covers the practical question that comes next. Where do the two tools actually behave differently, and which items belong on the table in a security review meeting?

Does using Git send code to an external cloud?

No. Git is a version control system, and it is not the same thing as a hosting service like GitHub. Pro Git on servers and protocols covers running your own server and accessing repositories over local paths, SSH, and HTTP. Since an internal server on an internal network is technically straightforward, "is it Git?" and "does code get transmitted to an external service?" are two questions that have to be checked separately.

Does using SVN keep code from leaving the server?

No. SVN developers also receive a working copy in order to edit files. The Subversion documentation describes checkout as creating a private working copy of a subtree of the repository. However well the server is protected, the storage and egress of source files on developer machines has to be managed separately. That is fully compatible with a centralized repository.

That said, the two tools do not have identical leak exposure. A typical Git clone keeps locally the full past history reachable from the fetched branches and tags, which is the property Pro Git describes as distributed version control. A typical SVN checkout receives the files of the working target plus working metadata, not a replica of the entire history database. When comparing what a single endpoint could expose, this is the difference to look at.

Can shallow clone or sparse checkout close the gap?

They reduce how much is downloaded, but they are not an enforced security boundary on their own. The shallow and partial clone options described in the git-clone documentation limit the history and objects fetched initially. Whether a user can clone differently or fetch more later depends on server permissions and the execution environment. Having downloaded less is not the same as lacking permission to download more.

The same applies to git-sparse-checkout. It reduces which files appear in the working directory. Hiding a folder from view does not mean read access to that folder has been blocked. The Git namespaces documentation likewise does not treat namespaces within one repository as effective read access control and recommends placing protected data in a separate repository.

This is where the unit of read permission diverges. SVN can grant path-based read and write permissions within a single repository through server configuration. If you have been splitting which directories each contractor can see inside one repository, the first design task in a Git migration is how to move that requirement onto repository boundaries. I covered that migration design in moving from lock-based SCM to Git.

What does it look like from an operations viewpoint?

Laid out as five items, where the tools match and where they differ becomes clear.

Three of the five items are identical between the tools. The other two, local copy scope and per-path read separation, are the ones handled by design.

Which rows carry the most weight depends on actual requirements. An organization that must expose only part of the source to contractors checks read boundaries first. One that needs to limit exposure of past history reviews history separation and the working environment. Where code may not remain on personal developer machines at all, working inside a controlled development environment is an approach worth reviewing alongside.

Does an air-gapped network make this review unnecessary?

No. Being air-gapped does not describe the data flow for you. Even with internet access restricted, the approved egress procedures, removable media, build servers, and backup paths still have to be identified. Drawing developer endpoints, runners, artifact storage, and backups onto a diagram that previously showed only the repository server is the starting point of the security discussion. How closed-network deployment environments get partitioned is in the five environments of on-premises deployment.

It also matters to distinguish what disappears when an account is revoked. Blocking new access to the server and deleting files already downloaded are different actions. With Git and SVN alike, the copies of source a person was allowed to read remain somewhere and need managing. A private setting does not automatically control what an authorized user does later with code they already received.

A checklist to bring to the security review

Turned into questions you can use in the meeting:

• Where does the repository server live, and is there any path by which code reaches an external service?
• What scope lands on developer endpoints: current files only, or past history too?
• Is there a requirement to separate read permissions per path within one repository, and if so, can it move to repository boundaries?
• Are developer endpoints, runners, artifact storage, and backups all on the diagram?
• When an account is revoked, what procedure handles copies already downloaded?

An agency should base its adoption decision on its own security requirements and actual configuration. This comparison is the technical distinction that decision needs. Declaring safety by product name leaves out the threats and controls that have to be checked.

I build a platform that uses Git. So I owe the constraints of history replication and read boundaries the same precision I give the advantages. CollabOps treats closed-network installation as its default shape and keeps repository, change request, pipeline, and deployment records on one plane precisely to answer the last lines of that checklist. What a customer must be able to verify is where their code exists, who can reach how much of it, and what evidence proves it.