Keep Applications Secure While Keeping Your Distance

In these times of social distancing and remote work, those who have created automated AppSec workflows beforehand have the edge over those who handle tasks manually.

When automated processes are in place, physical distance from colleagues no longer becomes an obstacle for remediating AppSec vulnerabilities.

In AppSec, the dependence on software developers for the remediation of vulnerabilities requires constant interaction between security engineers and the software developers.

One question immediately comes to mind with the rising trend of remote work ;Could physical distance from one another result in longer times to fix vulnerabilities and more risk exposure ?

Our answer is, that depends on the internal processes from the identification of the vulnerability until the remediation and each sub-process could have a substantial impact on the overall risk exposure.

Let’s take a glance at some questions that you need to answer to figure out which processes you have already perfected and in which there is still room for improvement.

1) HOW ARE ISSUES CREATED ON ISSUE MANAGERS?

Poor : You send test results to development teams via pdf reports or spreadsheets and they try to find the right person to fix the vulnerability. Once they do, an issue is manually created by the team lead. Precious time is lost during analyzing vulnerabilities, trying to find the right person to fix and manually opening issues.

Using your scanners’ integration capabilities with issue managers or adopting a vulnerability management tool that takes care of these integrations could come in handy to automate the issue opening process involved in the remediation of vulnerabilities.

Average : All vulnerabilities discovered by the scanner are automatically sent to issue managers either by the scanner itself or by a vulnerability management tool without any prioritization and assigned to a specific team member all the time.

However, sending all vulnerabilities discovered by your scanners can overwhelm your software developers and create an environment of distrust if developers think they are bothered by irrelevant vulnerabilities.

On top of this, if you already know the developer who has written the flawed piece of code, assigning issues to a different team member will only prolong the remediation process. Those who are quickest at fixing broken pieces of code are those who wrote it in the first place.

Excellent : Taking into consideration the project architecture, automated workflows created on your scanner or vulnerability management tool open issues only for vulnerabilities that meet predefined issue opening criteria.

When assigning issues to team members, your scanner or vulnerability management tool automatically identifies the developers responsible from the vulnerabilities coming from SAST scanners and assigns issues directly to those developers instead of generic team members to speed up the remediation process.

2) HOW IS THE REMEDIATION PERFORMANCE TRACKED?

Poor : You do not have standard remediation times (SLA levels) for vulnerabilities and have not shaken hands with developers to on the delivery of fixes within the accepted time frames. While you wait for developers to fix vulnerabilities, neither the developer nor you as a security engineer have an idea on the deadline.

Without historical data on average time to fix vulnerabilities, monitoring the positive or negative changes in the remediation performance becomes too difficult if not impossible.

Average : You have SLA levels in place but still keeping track of actual remediation performance manually via your issue manager. Analyzing the remediation performance of hundreds or thousands of vulnerabilities separately easily gets out of hand. Even worse, you make an honest mistake in the calculation and you make decisions looking at a distorted reality.

Excellent : Both you and developers are aware of the SLA levels of vulnerabilities and they know it is their responsibility or even a KPI to fix vulnerabilities within the agreed-upon time frames.

You have set up SLA levels on your vulnerability manager and it automatically keeps track of your mean time to fix vulnerabilities and sends notifications in case SLA levels are breached or when there are vulnerabilities whose deadlines are upcoming.

3) HOW DO YOU SUPPORT DEVELOPERS DURING REMEDIATION?

Poor : Developers do not have an internal resource where they can learn how to fix vulnerabilities based on prior experiences of peers or security engineers. Along with their reluctance on fixing vulnerabilities, it easily creates another bottleneck where vulnerabilities can not be fixed due to lack of knowledge on how to fix them.

Average : Knowledge transfer is carried out through verbal communication or through separate online or offline documents between security engineers and software developers. Developers need to flip through different documents to find the remediation advice from other developers or from security engineers.

Excellent : Your vulnerability management tool offers an internal knowledge base where knowledge is transferred from security engineers to software developers and between software developers. The remediation advises are shown on the issues opened on the issue manager so that developers do not need to be dragged away from their native environment to see the remediation advises.

Takeaway

No matter how good you or your AppSec scanners are at discovering vulnerabilities, what really matters is what you do afterwards to remediate them. Having automated and smart processes of prioritization, issue opening, remediation tracking and knowledge sharing is key to drastically shorten the average life of vulnerabilities without being affected by the new norms of social distancing and remote work.