Trust your software developers, but also verify
A talented programmer is a valued asset to any organization. But that doesn’t mean you shouldn’t take steps to protect yourself and your organization, writes Wayne Rash in his new article for PC Magazine, “Protect Your Business During Custom Coding Projects.”
Wayne begins the story with an uncomfortable anecdote:
On July 19, 2019, contract programmer David Tinley pleaded guilty to charges that he intentionally damaged computers belonging to Siemens Corporation. According to filings in the case, Tinley planted logic bombs into the code he was developing for Siemens at its Monroeville, Pennsylvania location. Those logic bombs, which were sections of code that were timed to create disruption weeks or months after a project was finished, were intended to ensure that Tinsley had a constant stream of revenue from having to fix the problems that were assumed to be bugs. When he was called in to fix a problem, Tinsley simply changed the date on the logic bomb so that it would go off again later.
Eventually, another programmer was called in to fix Tinsley’s code while he was on vacation, and it was then that the plot was uncovered. 62-year-old Tinsley had been working for Siemens for about 12 years before he was caught, but during that time, he was never under any suspicion. Sentencing is set for November 8, 2019, and Tinsley could spend up to 10 years in prison and pay fines up to $250,000.
The article quotes yours truly. Here’s part of it:
“A code review is probably a best way to find out what’s in your code,” said Alan Zeichick, Principal Analyst at Camden Associates, “including things like logic bombs, security vulnerabilities, or stupid errors [such as hard wiring the location of a database].”
“There are other reasons to do code reviews,” Zeichick added. “It helps your development team get a better understanding of how development works, helps junior programmers get a better understanding. Code reviews are also good for helping the team manager get a handle on the quality of the development team and get an estimate of how long it will take to finish the job.
Zeichick said that there are a couple of ways to conduct code reviews. “You can have a team where there are two people working on it or you can meet in a conference room to review code.”
Teams in which each member reviews someone else’s code are growing in popularity as programmers get harder to find. But in larger organizations, periodic meetings to review code are still useful because then several sets of eyes get to help in the review process. Zeichick said that even the most senior programmers should have their code reviewed.
