1

I was just reading this slightly older post on choosing a good source control system when I started thinking about how different projects use source control. Where I work we've essentially moved completely to Git and things have been mostly good.

I have wondered about high security projects such as military software projects. Using something like Git there would fundamentally be unsafe; even allowing repo clones under restricted circumstances could be problematic. Using SVN or TFS may not even provide enough security in itself.

Are there any VCS systems that have any stronger security considerations? Or are there additional considerations that go into using VCS for high security projects?

7
  • Also, here's a precedent for asking such questions like this: programmers.stackexchange.com/questions/145669/… Commented May 23, 2014 at 19:31
  • 4
    It's very debatable if preventing copies of source code does anything at all for security/secrecy. There's certainly an argument to not allowing copies all over USB sticks, laptops, etc. spread over the entire globe and prone to theft, but this can be addressed by leaving all copies (repositories) on hardware that remains inside secure facilities. Are we being paranoid and assume any developer working on the code is a potential leak?
    – user7043
    Commented May 23, 2014 at 19:32
  • A combination of restricting access to the only hardware that can have access to the code and a good security policy on the VCS itself should handle every scenario that comes up.
    – Bobson
    Commented May 23, 2014 at 19:35
  • @delnan If a hacker got a clone URL and access to a network, they'd potentially get the entire project and history of a project. Does that sound secure? Commented May 23, 2014 at 19:41
  • 3
    @delnan - there's a principle called 'need to know'. When you work with military type stuff, no one knows anything other than what they 'need to know'. Everyone on the projects IS a potential leak, one way or another, so the less that information is spread around, the less likely it is that EVERYTHING will be compromised. In such a project, you don't want any engineer not working on something to have any ability to get to that code. Which, for most source control systems, just means keeping separate projects in separate repos, and only the integration guys get access to all repos. Commented May 23, 2014 at 19:41

1 Answer 1

1

We secure systems because there is some risk of an event happening that we'd like to mitigate, and there's always going to be a tradeoff between the ability to work effectively and avoid the potential problems. So first you need to know what specifically you're trying to avoid, and then you can look for ways of preventing that.

So let's say the military of North Bonanzallia is working on some top secret missile guidance software based on garbonzo rays. Everyone already knows how to drive the missile, so there's no risk in that part getting out. Also, even though Garbonzo rays are secret, guiding a missile using images is well known. So if the code for the missile guidance system gets out, it would reveal details of how the garbonzo ray generating hardware worked (let's say it needs special pulse timing or whatever), but it wouldn't reveal the secret of how the garbonzo rays are created.

So, only the team working on the API that translates the garbonzo rays into an image needs to work in an EM sealed room with strict network control and mandatory searches and scans.

They would run source control on a server in that room, and the machines in the room would not be able to communicate with anything outside. The other teams can then integrate their pieces in another room, without any code leaving the secure zone. The application code can then come into the secure zone for testing, and redacted reports can leave the secure zone.

So, really, any version control system will do.

Not the answer you're looking for? Browse other questions tagged or ask your own question.