How many steps are there in a secure development lifecycle?
For many years ago, cyber security was considered as a final product or job that you add when the application functionalities are correctly working. However, today the game has changed ...
In the last few years, I have worked with some companies in the market to implement security in their DevOps system, and it was really a good experience that let me understand what really works and what doesn’t in a DevSecOps environment. Here is a table that summaries the pros and cons of a DevSecOps environment:
pros | cons |
---|---|
Reducing vulnerability detection cost | Dev speed implies more missed vulnerabilities |
Developers are responsible for producing secure codes | Difficult to find design vulnerabilities |
ability to respond to change and needs rapidly | No documentations on early stages |
Automate the vulnerability detection process |
If you are interested in knowing more about this subject then, please just keep writing …
DevSecOps is one of the most trending software development methodologies that combine the power of DevOps and the need of producing secure code. However, after a few years of experience with this methodology, I can say that this methodology also has some disadvantages that I have personally noticed.
So the discussion that I am going to do in this article is only based on my own experience with this new methodology. In addition, of course, no scientific approach have been used to find those advantages and disadvantages.
One of the main reasons for the success of DevSecOps is by far, reducing the number of detected vulnerabilities at the end of the development life cycle. In fact, this is related directly to a number of tools used by developers and security experts at the early stages of the development to automate vulnerability discovery.
Therefore, finding vulnerabilities at the beginning of the development life cycle reduces dramatically the number of vulnerabilities that might be discovered at the end. Which mean less time and effort to fix them.
One of the reasons why automated tools are giving good results in vulnerability detection is that most of those vulnerabilities are pattern-based vulnerabilities. Therefore, it is way easy to look for them in a source code.
Making developers responsible for producing secure codes, push them to be more vigilant to vulnerabilities. In addition, a developer that has a deep knowledge of the app source code is the best one to correctly estimate the impact of the vulnerability.
What I have noticed after these years of experience working with developers and security managers, is that when they correctly understand the real impact of their vulnerabilities, they start thinking seriously about making a secure code.
However, this means that a training for the developers about the most common security issues is a necessary aspect in the DevSecOps.
What makes the DevSecOps method a powerful one is the ability to respond to changes and needs rapidly. The structure and the way this method is implemented make it more flexible to match the requirements for any future technology changes.
Of course, one of the most important goals of the DevSecOps, is the automation of the security checks. Many tools are used depending on the development stage. For example:
And more, even at the implementation stage there is tools that check the environment system to see if there is any vulnerabilities.
It’s true and an awesome thing that Devsecops methodology has sped the development of the application. However, this speed comes at the cost of more vulnerabilities are missed. I know I have said earlier in this blog post that DevSecOps has reduced the number of detected vulnerabilities, but this does not mean it reduced the number of business logic vulnerabilities.
Actually, most business logic vulnerabilities require more time and expertise and they cannot be found using automated tools. Therefore, accelerating the development process means less time for this kind of vulnerability, and more critical vulnerabilities are missed.
The DevSecOps methodology is mainly based on the Agile system and uses many techniques from it and one of the main principles of the agile development method is focusing on producing the first app as soon as possible. This comes from the fact that it is based on the client feedback to enhance the app.
Therefore, no documentation is made by developers at the early stages of the development process. In addition, the developers of the apps make no design before starting the development. Thus, finding design-based vulnerabilities is becoming more and more difficult and time-consuming.
Having no documentation on the early stages of the application development make finding vulnerabilities especially the business logic ones even more difficult. As the security expert will need more time to understand the application logic and what is allowed for every user profile and what is not.
Many people think that DevSecOps will eliminate the need for security experts in the development process as tools may do all their work. And this is a wrong idea by the way as tools cannot perform some deeper analysis to understand the app logic. Therefore, it will be very difficult for any tool now in the market to find this kind of vulnerability and explain its impact.
It’s just like saying that we don’t need developers anymore as there is tools that can make applications automatically.
Written by: Z. Oualid
I am a Cyber Security Expert, I have worked with many companies around the globe to secure their applications and their networks. I am certified OSCP and OSCE which are the most recognized and hard technical certifications in the industry of cybersecurity. I am also a Certifed Ethical hacker (CEH). I hope you enjoy my articles :).
blog Z. Oualid
For many years ago, cyber security was considered as a final product or job that you add when the application functionalities are correctly working. However, today the game has changed ...
Copyright © 2020 Getsecureworld.
Post comments (0)