Atlassian’s New Features and the Shift Left Revolution

“All scanners list out security vulnerabilities but does the developer know what to fix first and how to go about it?”

Early last month, Atlassian introduced many new features in its DevOps platform. It promised the developers ‘less context switching, fewer meetings and more time to code’.

Succinctly put, the new DevOps platform integrates Jira issue tracking along with the Bitbucket cloud code version control system providing them an audit trail for recent deployment and Jira related tickets.

Significantly, the platform also brings together scanning, testing, and analysis tools together for a code review process. Atlassian is integrated with many scanners to highlight critical security vulnerabilities that heralds a positive move towards Shift Left automation.

But are the scanners providing the developers with actionable data?

Ram Swaroop, the President and co-founder of Securin said, “While automating and integrating these features will save the developer’s time, there is no context to threat and prioritization of vulnerabilities in most scanners.

This brings us back to a fundamental question of a developer’s understanding of vulnerability and its corresponding threat context.

Giving more perspective to Ram’s quote, Arun Prasad, an Engineering Manager at Securin says,

“When a developer gets vulnerability information, he/she will find it difficult to understand it without the help of a Security Analyst for some scenarios and with result can’t act on it immediately. That said, some developers might understand the context if they are familiar with the terms, but most would still need guidance from a security analyst to fix it.”

We conducted an experiment by running our source code against some popular scanners for SAST & DAST and the results were illuminating.

When the results were in, we spent no less than 8 hours looking through the vulnerabilities and 8 to 12 hours in prioritizing critical vulnerabilities.

For example, when we have 40 critical vulnerabilities, which ones should a Developer fix first?

While prioritizing the vulnerabilities takes an enormous amount of time, understanding the nature of some errors is time-consuming.

“Each vulnerability detected by the scanners comes with explanations, examples to reproduce the error, use cases, and recommendations to fix the issue but they are too generic to be of any use. For example, a use case like the one given below is of no help.”

There are scenarios where developers spend over 5 hours researching a fix for a specific vulnerability as we did for JPA SQL Injection to satisfy scanner requirement, although it is handled in code. (We highlighted the scanner solution and what is implemented below).

This is yet another common issue that most developers face. They spend an inordinate amount of time reproducing and validating an error just to satisfy the scanner.

While performing OSS, we got the following vulnerability – Spring Boot Framework Dependency Violation.

Despite the reference provided here, the remediation for this vulnerability can confuse the developer because the “PATCH” method is never used in our code. The developer will wonder as to why an upgrade is required when we never use that function. There is no possibility to reproduce or validate the error even after the upgrade suggested, so consequently, one has to depend entirely on the platform to check whether the error has been fixed or not.”

What we have attempted here is to present a day in a developer’s life – trying to make sense of vulnerability results, attempting to fix issues that are already rectified, and struggling to recreate errors.

Automation will certainly ease out many of these pain points and reduce the time spent on each vulnerability.

In an ideal scenario, the developer will get details of the fix with clear directions and directives. Once the fix is completed, validation will be automated saving the developer at least one to two hours for each vulnerability.  And not just that, including a feedback loop is also important so that the developer does not make the same coding error again.