Information Risks when Branching Software Versions

Branching of software versions is a regular and everyday process in software development. However, branching brings inherent information risks that require good controls and regular oversight. Here is an analysis of these risks and the possible controls to mitigate them.

Example scenario:
Shortinfosec Democorp has sold a software package to a customer company. The software package is rolled out in February and running well.
In June, the customer company is requesting a very specific upgrade.
Due to lack of resources, Democorp is scheduling the upgrade for the next planned version, which will happen at the end of the 12 month cycle (next February).
The customer company needs the upgrade asap, so it is agreed that the customer will create a patch for the software which will provide the required functionality. The patch is applied in July and running well.

During October Democorp software maintenance has prepared a patch that improves the performance of the overall solution. This patch is distributed to the customer and is applied to the system.
The next morning, the customer's data is corrupted, and needs to be restored from backup.

Incident management identifies that the customer created patch has failed and corrupted the data.
In depth analysis concludes that the performance patch has changed the underlying architecture of the software package, which caused the functional patch created by the customer company to fail.

This is a very common risk when failing to manage the possible branches of the software product and can sometimes lead to dire consequences.

When preparing custom solution applications, it is quite common that the application management of the customer are allowed to create certain supporting elements around the core solution. In extreme situations, like the example, they may even intervene within the core solution with a temporary workaround.
All these in-house developed solutions are based on the documented technology and architecture of the core solution.
Here are several methods that can be used and combined, in order to mitigate the risks associated with the developed branches.
  1. Establish standard and documented API's so the customer can interface with the core solution without the nececity to intervene directly into it. Maintain the API's for backward compatibility, and announce compatibility impacting changes to the API's at least 1 year in advance.
  2. Establish a practice to inform the customer of any technology changes in each new version and patch.
  3. Establish a cooperation protocol between the manufacturer and customer by which all in-house developed code supported by a core solution should be acknowledged and confirmed by the software manufacturer. By this protocol, the in-house code can be then maintained by the software manufacturer, or the software manufacturer will have to specifically alert the customer of changes impacting the in-house developed code.
Written by guest blogger - Marija Spirovska, currently holding position of senior developer at a multinational software company.
ShortInfosec thanks for her contribution, and hopes that she will continue to contribute to this site.

Related posts
3 rules to keep attention to detail in Software Development
8 Golden Rules of Change Management
Application security - too much function brings problems
Security risks and measures in software development
Security challenges in software development

Talkback and comments are most welcome

No comments:

Designed by Posicionamiento Web