You know that feeling when you’re studying for a really important exam, and you’re running out of time, so you decide to skip a couple of chapters in your textbook that weren’t too important? And then when you see the questions on the exam and realise that literally a third of the questions are on those same exact chapters you skipped?
We’ll that’s sort of what it feels like when you develop an application without properly fixing vulnerabilities. You build all these fancy features and an amazing, super-efficient architecture and everything’s great, until release day when someone finds an exploit that makes the whole system crash within 24 hours of going live. Yeah. It’s not fun.
‘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.
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, especially the most severe and exploitable ones. 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 you can 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. Vulnerability correlation tools 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?