By
·
3 minute read
Mobb automated security
I like listening to music while I work. It helps me disconnect from my surrounding and focus. Most of the time, I don't even notice what is being played, but as I was about to start writing this post, Spotify began playing Dylan's "The Times They Are A-Changin’" which I found to be very relevant to this topic. You'll soon see why.
Think about the past 20+ years of application security and its remarkable evolution to keep up with the changes in the software world.
First, there were the penetration testers. A small, elite group of experts tasked with evaluating applications for security vulnerabilities. They were armed only with their wit and skills and used manual techniques and custom-made tools. As the software world grew, so did the need to examine applications, and that elite group could not handle the growing task, so commercial scanning tools appeared.
Then, there were the application security experts. An elite group of experts tasked with evaluating the growing number of applications for security vulnerabilities using commercial and open-source application scanning tools. Operating these tools required a high level of skills and significant manual intervention. With the adoption of DevOps, that elite group could not handle the shift-left and speed requirements, so faster and DevOps-friendly tools appeared.
If your time to you is worth saving
Then you better start swimmin' or you'll sink like a stone
For the times, they are a-changin'
Today, there are the DevSecOps experts. An elite group of experts tasked with evaluating the continuous-deployed applications for security vulnerabilities by integrating commercial and open-source application scanning tools into the development pipeline.
So, we are all good now, right? We have developed processes and tools to find security vulnerabilities at the speed of DevOps.
Let us look at the other side of the wall now.
First, there were a small number of vulnerabilities that developers needed to address and long development cycles in which to fix them. Then, the number of vulnerabilities grew, but development cycles were still long. Still, some risk management began, knowing developers could not remediate all findings. Now, development cycles have been shortened as far as possible, but we find more security vulnerabilities than ever before. So how does that work?
It is easy to think that the mountains of non-remediated security vulnerabilities today are simply a resource problem, but the reality is that it is not. You will not solve it by adding developers. It is not even a process problem. The sheer volume of reported findings makes it impossible to handle through risk management or manual steps. It is a technological problem.
Your old road is rapidly aging
Please get out of the new one if you can't lend your hand
Application security’s next significant evolution will have to come from the remediation side. It has already started with tools that automatically upgrade vulnerable third-party libraries to a safer version. The next step needs to focus on remediating vulnerabilities in proprietary code.
There is much skepticism around the feasibility of auto code remediation, and for good reason. Some very strong teams have tried and failed before. Auto code remediation faces some very obvious challenges, from technology limitations, through the poor quality of reported findings (false positives), to the lack of developer adoption due to existing bias against security tools.
But it was too big and important problem for us to ignore, so we decided to try solving it ourselves.
We approached this challenge in the humblest way. Ignoring all our prior knowledge, and any conceptions, and expectations we had. We wanted to learn first. We reached out to individuals who were involved in trying to solve this problem before and interviewed dozens of security practitioners and developers who use application security tools today and we simply listened. The core problem was clear and matched our expectations, but we noticed a few interesting subtleties that we didn’t foresee. These observations allowed us to better scope the problem and understand our users’ pain and suddenly the solution revealed itself to us.
We learned not to look at an automatic secure code remediation as a finite product, but instead as a long journey with many incremental steps, each of which adds more value to our users. And we learned how involving developers and their knowledge in the remediation process will both assure our accuracy and get them to embrace the solution.
This is the first of a three-blog series. In the next blog, I will go over technological advancements and other factors that best positioned us to address the challenges and deliver on the promise.
If you want to learn more or see our automatic remediation in action, register to see our demo. Jonathan or I will be happy to deliver one.
Mobb automated security
