Micro Focus is now part of OpenText. Learn more >

You are here

You are here

The top 5 vulnerability management best practices for developers

public://pictures/Robert-Lemos-Technology-Journalist-Lemos-Associates.jpg
Rob Lemos Writer and analyst
 

Data from the National Vulnerability Database (NVD) shows an increasingly complex vulnerability landscape—one in which developers face a greater number of issues in across an expanding number of vulnerability types that they will need to triage and fix. So what's the best approach to deal with them?

The first step is to understand the scope of the problem. The sheer number of vulnerabilities, according to the NVD data, exceeded 17,300 in 2019, up from 16,500 in 2018. That sounds like a relatively small increase, percentage wise, but consider that the top 10 classes of vulnerabilities—referred to as "weaknesses"—today account for less of the overall landscape: 59%—down from 85% back in 2010, according to TechBeacon's National Vulnerability Database Analysis Special Report. These vulnerabilities are caused by a more diverse set of weaknesses. That's the challenge.

Casey Ellis, CTO and founder of crowdsourced security firm Bugcrowd, sees the impact of these two factors—more vulnerabilities across an expanding number of categories—all the time. 

"If you think of vulnerabilities as a function of the number of lines of code written, then it makes a lot of sense, because we are building a lot of [apps], and it is accelerating."
Casey Ellis

With software cycles shortening as more companies adopt DevOps-style development methodologies, developers who do not take security seriously will end up adding more vulnerabilities to the NVD.

And while vulnerabilities are becoming more numerous in more categories, the security issues associated with those vulnerabilities are often more serious as well, because affected software is used in increasingly critical systems, said James Rabon, director of product management for Micro Focus Fortify.

"If you are going to win in the market and you are going to release 15 or 20 times in a day, you can potentially deal with more vulnerabilities in something like a streaming service. But the ramifications are significantly higher in other industries, such as automotive and healthcare, which are also trying to speed up development."
James Rabon

Here are five lessons for developers from TechBeacon's National Vulnerability Database Analysis Special Report.

1. Limit your focus to your software assets 

While the overall number of vulnerabilities is increasing, so is the number of software products covered by the NVD. Products have an average of 2.5 vulnerabilities each. So for a company with a limited number of products, the total number of issues you'll face won't necessarily change.

A good first step, then, is to perform an assessment of you software projects and programs so that you can determine which vulnerabilities you need to consider as potential security issues.

2. Inspect the software components you do use carefully

Developers should be checking the security and patch level of any open-source components used to build the company's software, and of course consider implementing vulnerability management tools

By checking whether software components are up to date—and whether their dependencies are also up to date—developers can know whether they need to update to patch a security issue or, in the worst case, put a virtual patch in place using a web application firewall or other runtime measure.

Many companies have tools to help developers manage the components on which their projects depend. The basic OWASP Dependency-Check project is a free software composition analysis tool that has a command-line interface, as well as plugins for Maven, Ant, and Jenkins.

Software component analysis is akin to "brushing your teeth," Micro Focus' Rabon said.

"It is not complicated, and it's easy to do on a daily basis."
—James Rabon

3. Decide which vulnerabilities to break the build over

While limiting the application security team's focus to the necessary assets is a start, development teams also need to decide which types of vulnerabilities should cause a build to be rejected. Developers and app sec specialists should get as proactive as they possibly can with how they treat certain types of vulnerabilities, said Bugcrowd's Ellis.

By slowly expanding the definition of what software breaks the build, software development teams can gradually increase the number of security checks and coverage.

"Companies should proactively develop a thesis around what is going to be important to them. You are going to learn things on the fly, but you should draw a line in the sand of things that are going to be most important to you."
—Casey Ellis

4. Speed matters, but focus on accuracy

Developers hate waiting around for code to compile—it's one of the largest productivity sinks they face. Adding to that time by placing an inline security check for their code will frustrate them if those checks add more than a minute or two to the total build time.

One way to resolve this is to move your slow security checks out of band, with notifications piped back to developers through the standard channel, whether that's a collaboration messaging environment, such as Slack, or a bug-tracking system, such as Jira or Bugzilla. But what really slows down—and often halts—security is inaccuracy—populating the ticketing system with too many false positives.

"Security has to be frictionless. It has always been about what not to do, but we regularly see that, if the developers do not like your security solution, they will not use it."
—James Rabon

5. Be able to answer 'Are we vulnerable?'

The test of your DevOps team's preparation comes when attackers begin exploiting a new vulnerability. When that occurs, will your team be able to answer the seemingly simple question, "Are we vulnerable?" In the case of Equifax's data breach in 2017, the company had worked to patch a critical vulnerability in Apache Struts 2, but because of process failures, they missed the issue on some web properties.

Being able to attest 100% that a vulnerability has been patched and that scans of your infrastructure did not find anything is critical, said Bugcrowd's Ellis. If you have something that you can pretty reliably say is in use in the wild, "you need to be able to take care of that first," he said.

Get your teams ready for a busy year

This is shaping up to be another banner year for vulnerability disclosures. Make sure your developers are ready.

Read next: Special Report: National Vulnerability Database Analysis 

Read more articles about: SecurityApplication Security