The Developer's Tool Kit to Regulated Industries
Whether you're a game developer or a devops professional at an e-commerce site, it's your job to ensure that your software runs exactly as it is intended to. But there are a handful of regulated industries where code reviews and/or testing aren't just important, they're required by law.
In these regulated industries, the government has ruled that maintaining a certain level of software quality is so important that companies creating software in those industries must follow strict processes - including code review in the development lifecycle.
The SmartBear Research Team has examined some of the most regulated industries and has created a breadth of content, from blog posts to eBooks, about code requirements in these regulated industries. Specifically, the team looked into the medical device industry, finance industry, aerospace and e-commerce and have written technical documents about each of them.
While these whitepapers are always readily available on our website, I wanted to pull together all the content from these niche groups and publish links to them here on our blog to give you all visibility into the methodologies that are used to maintain quality in each of these regulated industries. I apologize for them being palced behind forms, but I do believe that anyone who truly has an interest in software quality best practices will find each of these documents well worth their time.
The V-22 Osprey helicopter uses a tilting wing and rotor system, which allows it fly like an airplane and land like a helicopter. In one test flight, the hydraulic system failed as the pilot was tilting the blades to land. A previously undiscovered bug in the aircraft’s control software caused it to decelerate each time the pilot attempted to reset the software. The aircraft had a built-in back-up system to handle such failures, but it had not been tested under those precise conditions, and the defect in the back-up system’s software had not been found. The uncontrollable aircraft fell 1,600 feet and crashed in a forest. For the second time that year, the V-22 was grounded.
As systems become more capable, it becomes harder to test all of the ways they will be used in advance. Once you test software and fix all of the problems found, the software will always work under the conditions for which it was tested. The reason there are not more software tragedies is that testers have been able to exercise these systems in most of the ways they will typically be used. But all it takes is one software failure and a subsequent lawsuit to seriously damage a company’s reputation.
Two years ago, a well-known software security expert demonstrated how he could hack into an insulin pump created by one of the world’s largest medical device manufacturers. Once inside the pump, he was able to remotely command it to release a fatal dose of the drug to anyone within a 300-foot radius.
Fortunately, the incident took place on stage at the annual Black Hat Briefings conference. Still, it was enough to cause an investigation by the House Energy & Commerce Committee to determine the safety of modern medical devices. Their conclusion was that some devices are not safe and that many of the issues could be isolated to the software code. In fact, the Food and Drug Administration determined that 24% of all medical devices recalled in 2012 were as result of software failures.
The securities industry has gone through significant changes in recent years. None of these changes has had more of an impact than the development of technology systems designed to handle ever-increasing speed and capacity. In fact, these systems are so complex and work at such high rates of speed that if something goes wrong, it goes wrong in a hurry.
Take what happened during the Flash Crash of 2010. In just a matter of minutes, certain equities experienced volatile price movements with more than 20,000 trades executed at prices more than 60% away from their actual market values. In a matter of minutes, nearly $1 trillion in market value evaporated before making a partial recovery.
Take what happened with Heartland Payment Systems. In one of the largest data breaches ever, this company's software fell victim to a malware infection. The PCI DSS includes a weekly minimum requirement for file-integrity checking, so investigators concluded that a problem with the software allowed the malware to remain unnoticed long enough to do the damage.
The impact for Heartland was far-reaching. After the breach, the company was removed from Visa’s list of PCI-compliant service providers. In effect, Visa was virtually shutting down their business by cutting them out of the loop. The result? Heartland now does everything it possibly can to ensure their software not only meets Federal Guidelines, but exceeds them.
Stories like that are enough to make people lie awake at night asking, “Did I do everything possible to ensure our software is as good as possible?”