In today’s era of digital transformation, every organization must focus on application security. However, focusing on security vulnerabilities alone is unwise because it’s nearly impossible to prioritize what needs to be done.

“DevOps teams are sitting in front of a table with the keys to the kingdom on their computers,” said Jake King, co-founder and CEO of Linux security platform provider Cmd. “We need to think not only about the risks pertinent to the software that we build and the way in which we build that software, but also the way in which we access the systems that deploy that software. It becomes the weakest link in that chain.”

RELATED CONTENT: 
How to get DevSecOps right
Creating a DevOps culture
CI/CD pipelines are expanding

At the time of this writing, there were 130,969 Common Vulnerabilities and Exposures (CVEs) listed in the MITRE Corporation database. That database is synchronized and used by the National Institute of Standards and Technology’s (NIST) National Vulnerability Database (NVD). NIST’s NVD ranks vulnerabilities using NIST’s Common Vulnerability Scoring System (CVSS) which is an open framework for communicating the characteristics and severity of software vulnerabilities. CVSS v3.0 reflects five levels of severity (none, low, medium, high and critical) versus CVSS v2.0 which used three (low, medium, and high). 

Security professionals use the ratings to prioritize patching, and hackers know it. So, some hackers will exploit vulnerabilities that have lower ratings while security professionals are focusing on the high and critical vulnerabilities.

“I have a very strong allergy to any kind of risk management that relies on an ordinal scale, rate the risk from one to five,” said Charles Betz, global DevOps lead serving infrastructure and operations professionals at Forrester Research. “I think that kind of stuff is worse than useless. It leads people to believe they’re secure when they’re not.”

No organization has the money or human resources to manage the 131,000 published vulnerabilities (which does not represent the entire universe of vulnerabilities). So, there are two other things enterprise security professionals consider for prioritization purposes. One is the organization’s attack surface (software and hardware assets ranging from traditional to IoT). From a software development perspective, application composition, including open-source, third-party software and other dependencies, must be considered. 

The reason it’s important to understand the attack surface is because not all vulnerabilities apply to any one organization. If there were no Microsoft software anywhere (unlikely in an enterprise setting), then Microsoft-related vulnerabilities wouldn’t apply. Similarly, if only certain Microsoft products or versions of products are used by the organization, then the products or versions not in use would not apply. Essentially, understanding the entire attack surface allows security professionals to focus on the relevant vulnerabilities, which is still an overwhelming number.

Therefore, it’s important to also consider threats. Of all the vulnerabilities that apply to an organization’s ecosystem or DevOps supply chain, which are hackers actively exploiting? What security mistakes are people in the organization making that cause systems, software and data to become vulnerable?

“We’re never going to get bugs to zero whether they’re in open source or our own code. We need to get visibility into how people are actually attacking and abusing our services,” said Zane Lackey, former chief information security officer (CISO) at Etsy. “The critical ones are easy [because] they jump out at you. Every security team on the planet is [grappling with] a mountain of medium severity bugs that never actually get fixed because they’re the same severity, the same risk.”

Worse, security teams tend not to have visibility into what’s happening in production, so they don’t have a way to quantify or prioritize those risks.

“There have been a lot of major breaches due to client-side protection issues, API issues and third-party open-source issues,” said Sandy Carielli, principal analyst at Forrester. “Application security is to some extent a third-party risk issue because you’re bringing in all these third-party components and container images.”