Producing Secure Software — Is it Possible?
Hardship in producing a secure software
Not a single developer, analyst, project manager or business owner want to own an insecure software. Just like customers would never want to trust any insecure application with their valuable data. Having or using a rock solid secure application is a desired thing, but is it possible at all and what can we do about it?
This is Bedirhan from the CodeThreat team, and in this post I’ll try to pinpoint difficulties of producing a secure software. First thing first; the number of new vulnerabilities published each year has a quite disturbing but factual outcome;
It is pretty hard to write and maintain a secure software.
I don’t need to iterate that these numbers are just published vulnerabilities of known software for a stronger effect. We very well know that there are many, many more unpublished or unknown publicly or internally produced software.
Now lets concentrate on some of the answers for the question of why is it hard to develop a secure software.
Inherent Complexity to Coding
Here’s a quote from T.Bollinger from one of his publication in 1997 that shed some light on the complexity of producing software;
… both the physicist and the software developer to ride the wave of earlier thought and enter the domain where science, art, and insight interplay effectively.
He’s resembling the idea of software development to theory of physics rather than engineering principles. Moreover, he adds art into the equation, which makes things even harder and unpredictable. In parallel, sometimes software developers are seen akin to craftsmen rather than engineers, perhaps because of the that art piece in play.
Tom DeMarco also points to this very same idea in his controversial article “Software Engineering: An idea whose time has come and gone”.
What I’m trying to say is; if writing code is that complex that we even compare it to producing an art piece, then writing secure code surely can’t be an easier task simply because complexity and unpredictability are perfect enemies for any kind of control and measurement.
As a practical side note, this complexity also results in the lack of reflection on your own code, which is a great way to spot potential bugs.
Incomplete and Ever-changing Requirements
Let’s here see what E. Dijsktra stated in 1972;
The requirements are getting more and more complex and changing rapidly.
Nearly half a century later has passed and we have more advance foundations, methods, notations and tools for software development but the above line still holds.
Incorporating the time pressure now more than ever, it’s hard to keep up with the security processes and controls we, developers, have to abide. Things are missed in this midst of feature mayhem and hackers eagerly exploit them.
Lack of Security Experience
Just like developers, security professionals are more like craftsmen than engineers. They come up with crazy techniques to by-pass existing security controls and/or find zero-day exploits. A ton of new malicious techniques are crafted each year and it’s no way near for an average developer to keep up with this fresh information.
Let me give you two numbers to elaborate this idea.
There are 418 unique weakness items in Common Weakness Enumeration(CWE) published by MITRE in one of its views. This specific view organizes the existing weaknesses around concepts that are frequently used or encountered in software development. So these 418 weaknesses are related to development.
Application Security Verification Standard (ASVS) v4 published by OWASP contains 286 control items that should be intact to make a software has a Level 3 security. This is the highest security level suitable for most of the critical applications; performing high value transactions, containing sensitive medical data, or requiring the highest level of trust.
These numbers point to an average effort required for a developer to master secure development. I am suspicious about the extent of the knowledge most of the security professionals have on all these items individually, including myself.
So, yes, it is hard to master vast number of security controls we have to know. And here’s more. Knowing a security weakness doesn’t mean knowing the right way to mitigate it. In fact, I frequently come up with developers who understands the popular SQL Injection or better Cross Site Scripting (XSS) weaknesses, but have insecure knowledge of fixing them.
3rd Party Dependencies
A decent application is deployed with lots of third-party plugins or libraries. We might be using these external libraries for both server-side or client-side software. Apart from the security of the code written exclusively for the application, the security problems of these libraries are usually missed out.
Worse yet, the security problems of these external libraries are mostly published and open to everyone. Not surprisingly, malicious actors monitor these resources as well. They produce attack payloads and try them on target applications using vulnerable external libraries. So, if we use one of those insecure libraries in our software, our product automatically becomes the target of those attacks.
Obviously, it is not an easy task to upgrade the libraries as soon as the owners release a new security or non-security related version. This is due to backward compatibility. Unfortunately, this is the task we comply to take when we decide to use the external libraries in the first place.
Security is a Low Priority
A some kind of cultural shift is necessary in order to integrate security into any software development life cycle to get results. But this is not impossible but hard.
Given generic software qualities like; Features, Usability, Code Quality, Security and Performance, business owners or even developers most of the time prioritize Security as the last or one before the last item. I consistently applied this on my secure coding training sessions with a quite similar results over 1500 developers.
This perspective alone tells us a lot for our current overall security, or insecurity, posture. This is the main reason for lack of security actions, lack of security testing, security measuring or even security peer reviews.
Should We Quit Then?
Why trying when we have such a hard problem at our hands? This is a ridiculous question because the stakes are too high for quitting and doing nothing for security. While it seems an awful amount of effort and resources are needed to produce a secure software, it is not the case.
There are a handful of actions, which we will cover in another post, that you can integrate to your development process that makes you more secure. Now, “being more secure” may sound like a wrong statement since either you are secure or not. This is all theory. In reality, no one can be %100 secure. There are known risks that are accepted and there will always be unknown risks.
Over the spectrum of being completely insecure and %100 secure, all incremental actions to get us more to the latter end are wise to undertake.
Software security is an inherent part of software development. The methods of having quality software also governs the rules having secure software. So, as we go about the project incrementally, we have to make sure security controls are there by teaching, testing and building.
