Another Computerworld article has grabbed my attention, and probably the attention of a lot of folks looking at offshoring. The article, "DOD Report to Detail Dangers of Foreign Software,” referred to a report due out shortly by the Defense Science Board, a military/civilian think tank. It is expected that they will come out against "foreign written" software since it can be more susceptible to code bombs.
Code bombs, logic bombs, malware (Malicious Software) software are nothing new. A search on the Information Week website for Malware or logic bombs, brings up pages of results. The most recent results, spread over several pages, refer to the trial of the UBS PaineWebber systems administrator, Roger Duronio, who was convicted in July 2006 of planting a logic bomb that brought down nearly 2,000 servers in 2004. Unfortunately, it is a good example that malware can cause serious issues and can occur no matter where the code is written, both inside the US and outside, and within one’s own company and outside of it.
In any situtation, when developing only in-house or in an outsourcing situation, there are some ways to help mitigate the risk of logic bombs. One of the simplest ways is to conduct peer reviews/code reviews looking for any anomalies in the code being written. Conduct them often and some times without warning. This practice, while both assuring uniform coding standards within the application and serving to catch bugs can also help prevent programmers from implementing any “time bombs” which may come back to haunt the company later.
Peer reviews are part of the standard software development life cycle, and standard quality practices such as ISO and CMM; however, they should be practiced by any firm regardless of any official certified quality level the company may have attained. Peer reviews can be scheduled with both onshore/offshore outsourced and insourced teams. Some can be conducted on a scheduled basis and some can be conducted without warning. When programmers know this practice is in place and that checking will be random, it will reduce the likelihood of any anomalies.
Peer reviews also have the side benefit of assuring that the programmers are on track with their coding. Could there be a simpler solution for their assigned task, or are they writing something that will be too hard to maintain in the future? Do their peers see something that was tried before and did not work? Catching these situations earlier can save valuable QA testing time later on. The practice cannot guarantee you will never have a problem with logic bombs or other serious problems, however it can help mitigate the risk of them as well as help prevent a myriad of other problems with your code.
