This is the introduction to a series of articles where I will discuss secure coding and software engineering best practices with you.
A few days ago, I was asked to participate in this blog. Really? What could I say? I love to chat and to question everything but the answers always lead to new questions!
As you can see, I said yes with a big smile to sharing my thoughts about Secure Coding—obviously because people tend to think that Software Architects are always procrastinating and I wanted to prove them right! I only started to think about my article yesterday and I got insomnia because my head was swirling with so many questions (again). I typed the words “secure coding” into Google and after 3-4 suggestions for possible alternate searches I found my inspiration:
This is where it all started and where I maybe began to be a Software Engineering aristocrat, because I saw bids for $40 USD that would take me 5 hours of work to do properly. Even without looking at the submitted code, I assumed that the quality would not be there and the project owner would receive a sub-optimal app for the price of a lunch for 2 at Mickey D’s.
This brings me back to the old times (1980-90) when IT was not a commodity, when doing Software Development/Engineering was only available to geeks (the weirdoes of that time), when a 246-Meg Hard Drive was 500$. Nobody had the idea to build applications without following strict rules, patterns, frameworks and structures. It was too costly, risky and unthinkable. In fact, the ROI was very important for almost all projects. When the decision was a “go” —then they hired very qualified analyst-programmers and architects with many years of experience because failure was not an option.
As geeks, we all know the great Jade Raymond, the Montreal girl who produced Assassin's Creed 1 and 2. But very few of us geeks know the work of the old men like Parnas, Dijkstra, Alan Turing and Michael Jackson (not the one with one glove and tight pants!). Though it was possible to ignore them for a long time, we can no longer afford to do so.
Less Focus on Security
For sure, the new technologies, the fast growth of the Internet, the hackers and script kiddies, the Internet of Things and the new apps appearing each day in the app stores are signs of change. Who would rent an apartment without water and electricity today? Tomorrow an "Internetless" place will be a source of shame! However, I really think that today more than ever, learning how to build good code cannot be done without security at the forefront. The risk is higher, the exposure to threats is growing exponentially and we don’t seem to really take care of it. We see security bugs disclosed and data stolen almost daily but we still act like it is nothing.
It reminded me of something I read last week about a programming language. The title included the attractive words "Mastering the x language". As a normal guy, I just looked at some pages here and there and I found 3 major SQL injection vulnerabilities that could let an attacker gain control of an application within seconds. I was so surprised that I wrote them an email about it. No response yet! I’ll let the readers of this blog know if I get one.
Who/What is Responsible for This?
Shorter deadlines for projects? Engineering schools with lower budgets? Reduction of costs with the arrival of hobbyists in the market? Incompetent teachers? Indolence? Honestly, I would put the blame on lack of awareness. People ignore the risk or avoid it because they don't know how to handle it. I truly believe that people don't intentionally build vulnerable applications and systems.
I hope that I do not seem to be a man of the past because I love evolution and of course I understand that the rules were different. Code security was not such a big deal during those years because the structure of good programming practices was there to mitigate the risk and this risk was not at the same level as today with all the new technologies and opportunities.
Was the Old Man Right?
Finally, the old man IS still right! Today's secure coder's toolkit should look like the one owned by the old weirdo with the big beard... it should include: design patterns, frameworks, best practices, tests, education, an understanding of the past and knowledge of new risks.
What do you think?