Securing apps: scan code for vulnerabilities or rewrite from scratch?

The U.S. Department of Homeland Security (DHS) states that 90% of security incidents result from exploits against defects in software.

”The SANS Institute 2015 State of Application Security Report” states that many information security engineers don’t understand software development—and most software developers don’t understand security.”  Frank Zinghini knows a thing or two about both topics. He is founder and CEO at Applied Visions, a 40-person secure software development firm headquartered on Long Island, N.Y., with another office in Clifton Park, N.Y. Zinghini has been writing code, managing software engineers, and building security products for more than two decades. He shed more light on how to bridge application development and security in a recent interview.

How long has security been a problem – as it relates to software development?

Zinghini: Insecure code has always been there, but it became a significant problem on the very first day we connected our computers to the Internet. In pre-connected days there were isolated incidences of people taking advantage of software flaws in order to break into computer systems or disable devices, but that required the attacker to have direct access to the system. Once we hooked everything together, we invited the entire world to attack our systems — and on that day, we developers took on the responsibility for making sure that those attacks would fail.

Is all software code then at risk?

Zinghini: Knee-jerk reactions are counter-productive: the fact that some software are at risk does not imply that all software is at risk. Developers need to become adept at threat modeling: learning to think like an attacker so you can understand which parts of your system are truly vulnerable, and focus your attention on securing that code. While it is admirable, and desirable, to adopt the philosophy that any new code you develop should be secure code, in real life we are faced with the need to prioritize our efforts.

What are the biggest (security) mistakes made by software developers?

Zinghini: The biggest mistake that developers make, every day, is to say “We’ll worry about security later, after we make our deadline.” If you don’t build security into your day-to-day development process, you will find yourself doing 10 times the work trying to “harden things up” after the fact. And the sad truth is, you probably won’t do that, because once you make this deadline you’ll likely already be behind schedule on the next deadline, so you’ll never actually get back to dealing with security issues. Deferred security is no security.

What best best practices should software developers adopt now – if they have not already?

Zinghini: The best thing to do is accept that security is just as critical to building software as safety is to building airplanes, and make a conscious decision to build security into your software development process. Worry about software security before you even start writing code, incorporate vulnerability scanning tools into your continuous integration system, and integrate security testing with your quality assurance process. If you need help convincing your management of the importance of this, use resources like the Department of Homeland Security’s Build Security In initiative to communicate the seriousness of this issue.

Is it better to try and find vulnerabilities in apps, or better to rewrite them?

Zinghini: There’s no clear-cut answer as to whether it’s easier to remediate an existing app or rebuild it to be more secure. It all depends on the quality and complexity of the existing application, and just how bad the security issues are. That said, there are risks involved with rebuilding (it’s generally harder to replicate the functionality of an existing app than to build a new one), and there are emerging technologies (like application firewalls) that make it easier to “build a wall” around an app to make it more secure. In the end, it’s a judgement call, but I tend to lean towards securing the existing app.

Do mobile apps bring the same challenges?

Zinghini: There’s an odd misconception that somehow mobile software is “different”, and you don’t need to worry about security. That’s not true. It’s a bit easier to secure mobile apps simply because they are generally smaller in scope than web or cloud apps — a good mobile app should focus on doing only a few things, and doing them well — but security is no less important.

What about code written for Internet of Things (IoT) devices?

Zinghini: We’re all getting excited about the Internet of Things, and we have to remember that when you connect your “things” to the Internet, you’re opening a new attack vector into your network. You need to secure that device just as surely as you would make sure that the new window you install in your home has a lock on it.

Should CEOs be involved with security?

Zinghini: The growing awareness among the software development community that security is important is very encouraging. But this is a grass-roots movement that all too often meets resistance from decision-makers in the organization. The product people want to release “yesterday” and are not receptive to the argument that security takes time, and the budget-makers are not willing to invest in the people and tools that are necessary to ensure the security of their product. The only way that change will happen is to lead from the front: CEOs need to make clear to everyone in their organization that security is “job one”, and they need to back that up with time, people, and money.