Automating Issue Assignment In Vulnerability Management

If the title of this post has attracted your attention and you have started to read it, you are probably aware of the fact that your security team is only as effective as your development team.

Regardless of how effectively your security team is identifying vulnerabilities, getting rid of the vulnerabilities always boils down to the capability and the willingness of the developer who is going to fix the issue.

Speaking of the willingness of developers, we all know it can deteriorate pretty quickly when they are asked to log in to disparate tools to perform different tasks.

“It falls on our shoulders as orchestration platforms to find a common ground where security teams make sure vulnerabilities are fixed and developers keep using their favorite tools without having to learn new ones.”

One major pitfall in the traditional vulnerability management process is to give developers pdf reports or spreadsheets full of hundreds if not thousands of vulnerabilities, which is a terrible way to kick things off.

To get what we want, we need to play ball with developers and let them use the very same tools they keep using on a daily basis to track and fix vulnerabilities.

In an ideal world, if an issue manager (Jira, Github etc.) is already used in the organization, then any vulnerability meeting certain criteria (severity being critical or high, certain CWE ID etc.) identified by AppSec testing tools should automatically be directed to the issue manager, preferably assigned to the developer who has committed the flawed piece of code or to a specified user.

For SAST findings, automatically assigning the issues created on issue managers to the relevant developers is a time-saving and tension relieving feature built by the application security testing orchestration tools.

Thanks to the integrations built with software development platforms (Azure, Github, Gitlab etc.), it is possible to pinpoint in which commit the vulnerability has emerged and to identify the developer who has committed the code.

With these automation features, it is possible to remove the tension that comes with the reporting of vulnerabilities, with team leads or security champions not needing to spend precious time on figuring out who is responsible for the vulnerability and the developers not forced to work on tools they have no or little experience with.

For DAST findings, a specific developer in each team can be held responsible for fixing the vulnerabilities and issues can be assigned to those specific developers for each project.

We need to keep creating more win-win situations like this and another particular problem we have observed in the field is that the issues opened on issue managers can be left open for a long period of time without developers attending to them.

Tracking the status of issues and introducing custom notification criteria when issues are left open for more than a specific amount of time is also taking a great deal of manual work off security engineers’ plates through automation.

As an example, you may require different SLA’s for different types of vulnerabilities based on their severity, window of exposure (the number of days the issue has been open for), CWE ID, file or path.

Once introducing custom criteria for different scenarios, you can rest assured that anything out of your desired structure will be sent as a notification to whom you need and will be escalated if needed.

Taking things to the next level, quite often times an issue marked as closed on an issue manager can still persist which might be misleading for the security departments.

To ensure that the issue does not exist anymore, running a validation scan to validate the fix is a good idea to give security engineers 100% assurance that the issue is resolved. In case the issue is identified one more time in the validation scan, the issue can be reopened on the issue manager.

The opposite is also a quite possible scenario where an issue ceases to exist in the next scan but the issue created in the previous scan remains open on the issue manager.

This typically happens when the communication level between security and development teams is low and results in an extra conflict when development teams find out they have been working on issues that actually have not been reported in the latest scan.

In this case, automation also comes to the rescue by automatically marking the issue as closed on the issue manager and preventing developers from squandering time on non-existent issues.

It is an undeniable fact that there is a lot of friction between security and development teams due to different skill sets, concerns and priorities of the people working in both departments.

Even the smallest requests from one department can lead to great disturbance in the other and these minor issues keep snowballing in time.

To keep our business safe from the negative impacts of this never-ending conflict, and to use our limited resources in an optimal way, we need new solutions and approaches that will minimize the contact and maximize the cooperation between the two teams.

That naturally sounds counter-intuitive but our experience in the field indicates that the more well-thought and automated processes we have in place instead of verbal requests, the more likely it is that these two teams will flourish together. It is like the old saying; “Actions speak louder than words”, and words can be misunderstood pretty often between these two teams.