rvlsoft - Fotolia
Safe is a relative term. Decisions regarding ALM systems and security need to be based on an assessment of risk and tailored to the organization, team and applications being considered.
Taking a generic look at the security profile of an application lifecycle management (ALM) system, it is important to consider the data being stored. On the whole, this can be some pretty valuable stuff. Serious intellectual property can be managed within ALM systems -- specifically, source code. In addition, these systems contain information about bugs in your software, including security bugs. Furthermore, your ALM system likely manages information about new features and basically lays out development roadmaps for your products. Finally, ALM systems invariably have information about other infrastructure, such as test servers, continuous integration (CI) servers and test databases -- and this information can be valuable for attackers wanting to compromise the ALM system as a jumping-off point for further attacks. (By the way -- you don't have live customer data in your test databases, do you? That's a serious concern but a question for another day.)
In addition to assessing the data you store in your ALM system, it is also important to consider the types of applications you are building. The answer -- or answers -- to that question will provide insight into the sorts of attackers that might be interested in the data stored in your system.
Based on this, you need to consider the impact of different breaches as they relate to your ALM. A framework for doing this is the CIA triad of confidentiality, integrity and availability:
- Confidentiality: What would happen if attackers -- or the general public -- were to gain access to your ALM data? It would almost certainly be embarrassing, but what other impacts would it have on your business, your customers and your competitors?
- Integrity: What would happen if attackers were able to modify data in your ALM system? The potential here is for attackers to surreptitiously close out security bugs so that they are never addressed. Attacks could also potentially insert backdoors into your source code.
- Availability: What would happen if your developers suddenly do not have access to their task lists? Or if they do not have the ability to check in new code? Availability is often a tertiary concern when organizations think about security, but it shouldn't be. The impact of short-term and medium-term availability problems should be factored into your ALM security decisions.
Finally, you must consider the types of attackers who would be interested in your ALM system. All attackers are not created equal. Their goals are often very different, and the success of an attacker will vary. For example, competitors would probably be very interested to know about your roadmap and, if available, your source code. This would provide them with valuable competitive intelligence. Elements of organized crime might be interested in having access to your ALM data to help them better target and execute attacks against your systems. Chaotic actors like Anonymous and LulzSec might use a compromise as a propaganda victory. There are likely other potential groups. The important thing is to answer the question, "Who else might be interested in the data we have stored in our ALM system, and what might they do with it?"
Reasons to move to a cloud provider
Everything above seems to scream, "Don't put your ALM in the cloud!" but that isn't necessarily the case. A cloud-based ALM setup makes sense in many situations, and certain types of lower-risk applications might lend themselves to cloud-based ALM providers because of associated cost and simplicity advantages. A lot of this hinges on answering the question "How well are we really doing at securing our in-house ALM data?" Organizations need to make an honest assessment of how well their in-house operations team is doing at tasks like patching their ALM infrastructure, upgrading ALM versions when security updates are released, and monitoring the ALM system for potentially suspicious or malicious activity. Answers for this vary both across organizations and within organizations. If you take an honest look at how well your current ALM setup is being managed and maintained, and you find it lacking, a well-run cloud-based ALM system may provide a number of benefits over running these systems in-house.
If you decide to move to a cloud-based ALM provider, it is important to understand their security practices. Cloud providers have economies of scale associated with running their systems, versus in-house, on-premises software. If you're outsourcing your ALM to gain access to their superior operations, you need to be sure they actually have appropriately secure operations.
Reasons to stay with in-house ALM
When you're considering moving your ALM infrastructure to the cloud, your organization's culture can play an important role. The location of source code can be an emotional issue, and some organizations simply won't allow an off-site provider. In addition, organizations with ALM data that is so valuable or to which a breach scenario is so damaging that they can't take the risk of outsourcing this function to an outside provider -- these groups may not be able to justify moving their ALM to the cloud. It should be noted that if this is the decision you reach, you must also realize that the responsibility falls to your organization to properly secure, monitor and maintain your ALM infrastructure.
In short, cloud-based ALM providers can offer a number of advantages when compared with running these systems in-house. However, because of the nature and value of the data managed within ALM systems, the decision to move to the cloud must be made after a serious risk assessment.
How to integrate the five ALM processes
Check out these five ALM cloud tools
Dig Deeper on Topics Archive
Related Q&A from Dan Cornell
The jailbreaking of iOS devices has a huge affect on security. It opens the door for malicious hackers, and not just via adventurous consumers. Continue Reading
Code signing creates a system of trust among mobile users, but it doesn't bolster the security of the app itself, says expert Dan Cornell. Continue Reading
Step one in devising an application security plan is determining whether the development team or the security group is responsible for testing. Continue Reading