The concept of Shifting security left in software development life cycle(SDLC) is not new. As a software developer, all of us know, how important data security/ privacy is. Most of us must have known about it, in one way or another, even if in different words or phrases. In this post, I am going to talk about what does it mean by shifting security left(for those who haven't heard about it before) and what can we do, as developers to adopt this mindset.
In the standard SDLC, you develop, test, put the application in cloud, iterate the process and when its ready to release for production, all security/ compliance checks come into picture. And we know that farther the cycle, more expensive it is to identify the problem and fix it. Expensive in terms of money and expensive in terms of time and of course in terms of our sanity.
So, security should not be an afterthought.
Hence, came the concept of shifting security left. Which means that rather than checking for security at the very right of the process, shift it to the left. Start adopting security/ privacy measures from the very start of the development. This can be pushed further left, where we start to analyse this from requirement analysis and backlog grooming.
Shifting left means adopting security by design. Possible issues later in the development cycle cannot be predicted. Hence it will be very helpful to be proactive and think about making the application more secure from beginning, rather than being reactive.
Adopting this mindset means that we can reduce the security vulnerabilities in our application, saving us a lot of time, money and most essentially stress to ourselves. You must have heard about death by thousand paper cuts. Its not always one big blow which can lead to malicious hacks but it can be 100s of vulnerabilities here and there.
It all sounds very easy. But is it?
As a developer, when writing code/tests or doing code reviews, there are so many things you have to focus on... Implementing the feature, writing clean/maintainable/testable code, writing tests and writing documentations. Without a doubt, we always want to embrace secure coding practices when coding and doing code reviews. But, with time constraint/ pressure, it is easy to miss this out. That can be because, it’s not imprinted hard enough in our minds as having to write unit tests/ making sure that code is maintainable. Adding this perspective proactively in your mental checklist, might take regular remainders and can become a habit with time.
Being familiar with the OWASP top 10 vulnerabilities, OWASP's ASVS( (Application security Verification Standard) and knowing good and bad practices for writing secure code helps a lot to remind ourselves about the measures we can take to be “The Secure Developer”. In addition, decisions we make as a developer, dictates how we can improve security of our applications. Decision about persisting data, using external libraries and using external code.
Data:
We know that most of the malicious hacks, leads to leak of User’s private data – their name, address, date of birth, email address, credit card details and Social Security number. So we need to make sure that those data are properly encrypted before sending it over the network and persisting them, so that they are secure.
However, what is more secure than Secure data? Answer is, NO DATA
If these private details were not saved in the first place, they would not be leaked and exploited. So, before persisting any data, we need to ask, WHY do we need to persist them. DO NOT persist any data, unless its absolutely required. If you have to persist them, make sure that, you take necessary measures to secure them.
Open Source Libraries:
Most of the applications today uses at least 1 open source library. Why? because there is no point in reinventing the wheel. But when using these external libraries, we need to make sure that they are reliable enough. Its really important to ask, if the library you are going to use is credible enough, if its regularly updated., What kind of issues are reported against it in github.
Open source libraries are the most vulnerable ones which can be exploited. You never know, that the library you are using might be mining bitcoins in the cloud.
However, in case of vulnerabilities in widely used libraries like openSSL and struts, you cannot do anything, except updating the library as soon as the fix comes along OR face the consequences as Equifax did. There are many commercial tools available for this purpose, that you can use.
Stack Overflow Driven Development:
Copying the code from Stack Overflow and pasting it without understanding what it's actually doing, is a common practice. All of us have done it at some phases of our career and we still do it. There was a research which researched about accepted answers in Stack Overflow and found out that there are many accepted answers which are out of date or insecure. It is really important to understand what the code is actually doing, before reusing it.
All of these sounds very trivial and obvious. But sometimes we forget about them. As a developer, adopting this mindset is really important. You don’t need to be a doctor to know that you should wash your hands to prevent spreading germs. But sometime, those notes in the bathroom helps. So this post is just that remainder.
There might be many other tips which you can adopt to embrace secure coding practices and make secure decisions. If you have any, please share it in the comments.
Top comments (1)
Very precise and informative. Thank you for this amazing article.