Protecting source code

As I mentioned on the missing Live episode, one of the consequences of the Gawker hack was that their source code for their internal software was leaked into the Internet. I doubt any of my readers would want that to happen to their code, so I’m going to share the details of how I protect my clients’ code when I’m working. Maybe some of this will work for you.

In the office, I work at a desktop iMac. This has an external time machine backup disk and a DropBox for off-site storage. However, client code does _not_ go onto the DropBox. Instead I keep a separate, encrypted sparse disk image for each project I’m working on. The password for each is different. As well as protecting against snooping, this helps stop cross-contamination. I rarely have two such images mounted at once. Note that it’s not just source that goes into these images: build products, notes, Instruments traces, and images all go into the encrypted containers.

Obviously that means a lot of passwords, and no I can’t remember them all. I use a keychain. It locks automatically when not in use, and has a passphrase that’s different from my login passphrase.

The devices I test on are all encrypted where available (if a client needs me to test on an iPhone 3G, then I can, but it isn’t encrypted). They are passphrase locked, set to require passphrase immediately. And I NEVER take them away from the desk before deleting any developer builds, unless I need to do something special like a real-world location services test.

I rarely do coding work on the laptop, but when I do I copy the appropriate encrypted image onto it. The laptop additionally has FileVault configured, though I’m evaluating full-disk encryption options. Keychain configuration as above, additionally with a password required on wake from sleep or screensaver, and a firmware password.

For pushing work back to the clients, most clients use github or bitbucket which offer SSL-encrypted connections to the repositories. Personally, I have a self-run repo host available over HTTPS or SSH, but will probably move that to a github-like service because life’s too short. Their security policy seems acceptable to me.

About Graham

I make it faster and easier for you to create high-quality code.
This entry was posted in Business, code-level, Data Leakage, Encryption, Policy, Responsibility, software-engineering. Bookmark the permalink.

5 Responses to Protecting source code

  1. Pingback: Tweets that mention Protecting source code — Secure Mac Programming --

  2. Oliver says:

    What sort of impact does this have on your productivity? Is all that encrypting not slowing things down terribly? And what would happen if you lost your passwords or there was a keychain issue? And is it strictly necessary to go to such a great length? Should we all be doing this?

  3. Graham says:

    @Oliver: it’s not a performance problem at all. It takes a few minutes to set up per project, and then I have to double-click a DMG before I do any work. Assuming I lost my passwords, I could recover the data from the upstream repository.

  4. Pingback: Securing the security guy's home office: what should we do? | Q&A System

  5. Pingback: Securing the security guy's home office: what should we do? | Q&A System

Comments are closed.