Do Your CM/ALM Tools Help Secure Your Development Assets?

• a data classification or other basis.

In our shop we use a number of these. We use passwords for repository access. We use data ownership along with data permissions and access control lists. We use product-based data segregation so that all data relating to a given product is accessible only to those users who have been given access to the product. The beauty of this latter method is that a simple product specification identifies which problem reports, documents, source code, activities/tasks, etc. are visible for a given user (or class of users). Such a solution is a simple means of performing ITAR Data Segregation. We also have dynamic user interface customization that adapts to roles and permissions granted to our users.

Data Encryption

Of course data encryption is another means of securing data. Unless you have the key to unlock the data, it does not matter that you can access the raw files. Encryption applies to documents, source code and other data. But it is also useful during network transmissions, especially given how viruses have evolved over the years.
Encryption needs to be managed at multiple levels. For example, only the tools should have the keys to unlock data transmissions. Within the repository, there will be a need for project-specific, site-specific and user-specific keys, among others. And managing and securing keys becomes a challange in itself.

A Few Other Factors

Some CM/ALM tools provide a means for inserting, automatically, copyright notices into source code. This helps to address the intellectual property concerns. However, it is recommended that you embed some hidden copyright notices into your program code, so that if push comes to shove, it's easy to demonstrate that you really own the copyright. Of course within a CM setting, maintaining the history and evolution of your product will also speak volumes against anyone with claims to your IP. Imagine how easily the Unix code claims could be handled if the code were all properly managed in a CM/ALM system with full change control and traceability.
Another key factor to consider is consistency of your solution across the Lifecycle Management Applications. Ideally you want a single consistent means of implementing data security and integrity. An integrated ALM tool will likely give you fewer headaches than will point solutions which are glued together.
As with anything relating to CM, automation is the key. Whether it's backups, encryption, recovery, or otherwise, the more that you can automate, the better off the solution will be. More reliable, less error prone, and easier to administer.

At What Cost?

The Department of Defense seems to have deep pockets when it comes to securing development assets. What about for the rest of us? What can we hope to afford? The last few years have pushed security features from the top dollar optional feature classification into the commodity capability arena. That means you should start looking for these features in the CM/ALM tools that you will use. They should not be expensive add-ons. They should not be limited to the high-priced tools. They should just be there, and the CM industry is rapidly evolving along these lines, even if a premium is demanded today.
In the end, securing your development assets requires that you use appropriate tools and investigate their architectures sufficiently prior to purchasing them. I've presented a number of capabilities and requirements here. There are many more I've neglected, some of which I'm unaware.
There's one more development asset that's important - your team. Providing tools, processes and automation that keep your staff productive and enable them to continue learning with help you to keep