Developing an app is a lot like writing a non-fiction book. You’re bound to make a few mistakes, which is why you need an editor. But if you get the facts wrong, you’ll have a lot to rewrite. If you’ve made grammatical mistakes, you’ll have smaller edits to make. In the same way, if there's a functional problem with an application, you’d fix it immediately. Unfortunately, while security vulnerabilities come under the same category as other functional or non functional ‘bugs’, they’re not treated with the same urgency.
‘Build First, Fix Later’ is a mindset that most companies are learning to grow out of. But the question is this: if vulnerabilities were categorised and fixed with the same urgency as bugs, wouldn't it make for a regret-free experience for teams building it? The thing is, whether vulnerabilities affect your application’s data or your users’, it affects their sense of security, and therefore their experience of the application (just like if someone saw a bug in their soup).
Bug tracking in today’s world is a necessity. There are a number of tools that help you:
- Track bugs
- Name bugs found
- Retrieve information on what the user did, what they expected and what actually happened
- Assign priority to different issues
- Indicate the state of an issue
- Enable the user to search, sort and report on the bug
What these platforms can accomplish is quite impressive, actually. But their usage is unfortunately limited to the scope of functional and performance defects and not security defects.
Vulnerabilities ARE Defects
If you were to give it a rational thought, vulnerabilities ARE a type of bug. While bugs hinder the functionality of an application, vulnerabilities hamper the SAFETY of your users, as well as your own reputation. In this regard, it’s almost imperative that product teams treated both the same. But just like most other things, this differentiation too has resulted in the consideration of security as an afterthought in the SDLC...at least until now (where the realisation that security needs to be thought of earlier than as an afterthought.)
Bug Tracking Systems Sometimes Cry ‘Wolf’
While some might argue that logging vulnerabilities within existing bug trackers is just a matter of operational convenience and that this change in process can be easily made, it’s just half the solution. When it comes to vulnerabilities (and especially vulnerabilities generated in scale) what is equally important to manage is which vulnerabilities go into the (bug tracking) system.
The Issue of Too Many
Development teams are already flooded with a barrage of tickets flowing from testing in Dev, UAT, Pre-Prod and even from live environments. And these in most cases are just from functional (non security issues). The last thing we’d want is to add a truck load of additional tickets -- especially when there are potential false positives (or worse, when the same vulnerability is reported more than once). Sometimes, a single vulnerability is found across multiple instances in the same application, and there are multiple tickets being raised for every instance.
Only Comments, No Suggestions
Just like bugs get fixed in development, vulnerabilities should be fixed as soon as possible. This (as everyone knows by now), saves costs beforehand, rather than reaching out to users about a breach later.
A Vulnerability Management Platform
What is required, is an intermediate system that brings the necessary context to vulnerabilities. Not excel, not PDF reports. A professional system that helps manage vulnerabilities and transforms them into defects to mainstream product engineering. This way both developers and engineers are on the same page about how quickly these issues must be fixed.
It’s also a lot simpler for engineers if security professionals understood that certain patches might fix the vulnerability, but they also need the entire system to be rebuilt from scratch.
The solution to this: an holistic way to track and tag vulnerabilities that seamlessly integrates with developers’ cycle… or finding security engineers who can patch systems without breaking them down completely.
While finding such talent can be difficult given the current skill gap in the DevSecOps community, there are tools like Orchestron that help both developers and security engineers get on the same page. Integration with existing bug trackers means that Orchestron helps you receive reports on your application’s health, while also flagging false positives. It also lets you know how exactly to fix the problem, by pointing out what usually causes these issues. Tools like this one can help you address vulnerabilities just like you would a normal bug, and therefore secure your application.
So... are you ready to treat vulnerabilities like bugs?