Shifting Leftest
Get hold of your own code security
A secure application is a team effort, sure. Every stakeholder should be part of it. But this little write-up relates only to the developers; a simple mindset change will have an enormous positive effect on the security of your code.
There is a fundamental teaching that students are taught in medical schools. In Latin it goes like;
Primum non nocere.
It more or less means “Above all, do no harm”.
Well, it seems this is a pretty intimidating and restricting thing to teach. The reason is I believe there is always some risk of doing harm in any treatment. If none of the medical people apply their profession based on this premise, we were doomed. 😮
So, let me elaborate more on this. The phrase is actually meant to say,
Don’t start a treatment with expected benefits until you are sure that it doesn’t come with outweighing harmful effects.
Of course the above claim comes with a few prerequisites. First, a medical professional should know the benefits of a treatment. Second, and it seems more importantly, she has to know the harmful effects of the treatment she applies. 😉
I think that’s why the medical students are deep into the books and contemporary results for all their careers. This is a LOT of information to posses for an individual, however, it’s fair. It is fair because the risk of lives are at stake.
The World of Developers
The number of people who are deeply and negatively effected because of an IT problem is enormous and rising. The problems related to hacking due to weak security are also in this category.
Think about ransomware attacks or power outages due to critical systems being successfully hacked. Some of these problems stem from our, the developers’, mistakes. Because, 99 percent of the time we are not taught any “primum no nocere”s in our work environments, let alone through out our educational periods.
However, the advantage of learning and applying the security pillars while we are designing, coding or testing is immense. A security-aware developer is a foremost and pretty solid leverage against successful hacking incidents.
Drawing the Attention
Writing secure code needs a mentality change and that’s hard to do. However, on the bright side the security topic itself is exciting. So, it’s easy to draw a developer’s clear attention when you show a popular hack and its repercussions especially targeting their own project.
This is learning through fear, but as long as it plays an effective role of increasing the initial awareness it’s acceptable.
There are, of course, other action items with a similar effect, incentives such as hacking/bug bounty competitions, gifts, games and bonuses etc.
Actions to Take
Everything starts with a change in the corporate or project team mentality towards more secure coding, however, let us assume it’s already somewhat there.
Then, it’s always a good idea to start with an awareness training with demos included. This is to light some curiosity. However, perhaps the most important thing to get out of a training program is to spot one or more interested developers. Those developers can be secure coding catalyzers that I believe every team needs on some level.
These developers can join happily on efforts of doing security research on the code base, giving insightful information about the software and building static/dynamic analyses processes. The knowledge they will gain through this course will really step up their game on development as well as they will increase the overall security of the software all along. A win-win situation.
Another well-known practice is to integrate a security static code analysis tool that will aid in locating potential weaknesses as soon as the coding starts.
But in order to shift the security mentality to the leftest (earliest), a team needs to provoke the developers to be suspicious when they are coding. The developers should be able to ask themselves reflective security related questions as they usually and intrinsically do when coding a business logic flow or an algorithm.
Another practice that can get things running is called Threat Modeling. Albeit not popular enough, when executed it’s one of the earliest source action for locating and prioritizing security risks without even writing a piece of code.
Ignite the Developers
Generally there are two kinds of security risks in a software; syntactic and semantic issues. The first one is similar to grammar mistakes in a novel. The second one is mistakes in a plot presented in the novel.
There are editors which can spot both and get them fixed. However, as you become a good on writing the less “bugs” you will introduce on the text you produce.
Let’s hear from one of the greatest writers of all time, Hemingway himself
The most essential gift for a good writer is a built-in, shockproof, shit detector. This is the writer’s radar and all great writers have had it.
There’s no doubt that this is also true for good developers. The nice thing for us is that we don’t have to be born that way. It is possible to build a detector not through birth but through learning and practicing. Not that it wouldn’t help if you were born with a suspicious character. :)
