How to set up a multi-developer environment with emphasis on source code security?

Question

One of my clients runs a small software development company (15 employees) with PHP as their sole server side development language. They are having a networked environment with all the computers connected to a central server via LAN. The server also runs a FTP server.

Their hardware setup is as follows:

Individual developer Environment: Windows 7 x64 Professional + XAMPP + Netbeans

Central Development Server Environment: CentOS 7 + Apache + PHP + mySQL

Their current workflow is as follows:

1. When multiple developers are involved in a same project they create a new directory in the central server under a /projects folder using a FTP client (with a common FTP credential that everyone knows).
2. Then they use GoodSync(http://www.goodsync.com/) to sync their files from their local machine to server and vice versa.

Also they are planning to install and use Git in the main server.

Everything works fine but the organization wants to tighten the code security so as to disallow the access of all code of all the projects to all the developers.

So how can they create a simple easy to manage but a secure system for multiple developers?

Answer 1

Firstly, you need to weigh up the cost/benefit of what you're trying to achieve.

Generally preventing code theft by developers is a very steep uphill battle, but fortunately I don't think it's a very common problem. I can't think of many prominent examples of code theft except in some cases where very specific proprietary algorithms are involved, or perhaps an employee jumping ship to a client and taking their code with them.

In terms of physically restricting access to code, really the only viable way is to restrict access to repositories. Even then, that will only be significantly effective if your application architecture in such that entire components can be operated as separate services and high risk employees can work on low risk components which might interact with the high risk components as a "black box" without having to give them access to the code.

It sounds like a high risk employee jumping ship with the project they're working on is your biggest threat and fundamentally they need access to that code to do their job so there's not much you can do about that.

The threat of legal action or damage to their professional reputation usually provides enough incentive for developers to do the right thing. Perusing these controls is probably a more practical approach. Endeavouring to hire trustworthy employees should also be obvious.

With regard to your deployment process specifically, it's pretty bad from both a security and operational standpoint. It seems you're without any form of version control, and I'd be shocked if you weren't frequently overwriting each others changes accidentally and trying to figure out who changed what without any way to know for sure.

It's typically considered good practice for:

• Your developers not to have direct access to your production servers except via an automated deployment process that takes code from version control where changes will be attributed to a specific developer
• To have a discrete deployment (as oppose to incrementally changing files) sourced from an explicit version control version
• For developers to have unique accounts, and typically their version control access dictates access to the production servers via their ability to commit code which will then be deployed automatically

There's plenty of resources on implementing version control and deployment management so I won't go into it too much further.