By
·
3 minute read
Mobb automated security
In the first blog of this series, I went through the evolution of the application security market as it tried to catch up with the fast-changing software world. I then briefly touched on the next step in the application security evolution, which many believe should be automatic secure code remediation and some of its challenges.
In this blog, I will go over technological advancements and other factors that best position us today to address the challenges and deliver on the promise.
For years AppSec vendors tried (and failed) to develop automatic remediation capabilities to add to their toolset. Not for nothing, their customers often asked for such a capability "if you can automatically detect issues, why can't you also automatically fix them?"
When I heard such customer requests years ago, I thought to myself that I would need to order boxes of fairy dust to sprinkle on the results, knowing in my engineering heart that it could never be done. "How can any tool automatically fix human code errors without breaking something?" For me, a security vulnerability was no different from any "regular" defect, and no one ever expected to have automatic defect remediation.
Over the past year working on Mobb, I learned I was oh so wrong on so many levels, definitely on that "never" part.
I learned that most security vulnerabilities differ from most "regular" defects. Fixing an SQLi or XSS usually doesn't involve changing any business logic or a significant architectural change. Unlike those defects, the set of security vulnerability types SAST tools can detect is well-defined and closed.
I also learned that building an automatic secure code remediation tool is achievable. It is challenging, of course, but not impossible. So, let's go over the challenges and how we mitigated them.
Why should we even try to fix something that is not really broken?
Static application security testing tools are notorious for presenting false positives (FPs). In his blog, Johannes Späth distinguishes between two types of FPs and the reasons behind them. Johannes refers to them as the technical, which modern SAST tools can handle, and the contextual false positives.
A contextual FP, a non-exploitable finding, does not pose a risk in its current usage, but at the same time, it is not good code. Replacing bad code with a correct best practice will only improve the code. While companies are usually reluctant to spend developers' time fixing these issues, they actually end up paying the most expensive senior developer's time in triage. Finding a way to eliminate those non-exploitable findings at nearly zero cost allows companies to distribute little work amongst all developers by simply sending the fixes to the relevant developer and ensuring their removal from future reports.
Making sure our automatic changes never break anyone's code
Most of the security vulnerability fixes developers implement only involve a few changes and do not impact the application’s business logic. An automatic secure code remediation solution should do the same.
But even with minor changes, errors may occur. We needed to ensure we formatted the code correctly and accounted for the language, frameworks, and styles in use. In the past, satisfying these requirements alone would have required us to spend a great deal of work, but these days, there are open-source tools that can help. In our case, we decided to leverage an open-source tool named Semgrep. Running our predefined proprietary rules with Semgrep allows us to pinpoint the exact line of code we need to fix and easily understand its different elements.
At first, we thought the only thing left would be to combine this information with our security best practice knowledge and compose a coded fix. But, as mentioned in my first blog, we didn't rush into this solution. We spent a lot of time early on listening and researching. It became apparent that the code would often miss significant context imperative to build a high-quality fix automatically. Our solution to this new challenge actually turned into a unique advantage which I'll describe below.
Developers won't accept our automatically generated code.
Remember when people said that developers will never trust automatically generated code? Guess what, according to tabnine and GitHub CoPilot, that ship has sailed. Millions of developers already do. From my few discussions, some developers couldn't be happier with their little AI assistant taking care of repetitive tasks. However, others still hold their ground, refusing even to explore the possibility.
Our goal is to relieve developers from the pain of dealing with security vulnerabilities, whether triaging them, fixing them, or even filing for exceptions for not fixing them. Any developer would want to avoid dealing with those, but most have such a strong bias against security tools that nothing assures us developers will trust our tool to change their code.
We addressed this challenge by providing a unique experience involving the developer in the creation of the fix. The developer sees the suggested fix and is quickly able to review the changes and confirm or change any assumptions made. Having the developer take part in the fix process allows us to gain the developer’s trust and assures the accuracy of the fix.
The next and last blog of this three-blog series will describe the how. I touched on it a bit in this blog but decided to leave the detailed description for another post.
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
