DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Software Design and Architecture
  3. Security
  4. Why You Should Reconsider Prioritizing High Severity Vulnerabilities in Your Fix Schedule

Why You Should Reconsider Prioritizing High Severity Vulnerabilities in Your Fix Schedule

Learn more about why you should reconsider how you prioritize vulnerabilities.

Laura Paine user avatar by
Laura Paine
·
Feb. 28, 19 · Tutorial
Like (1)
Save
Tweet
Share
3.78K Views

Join the DZone community and get the full member experience.

Join For Free

When it comes to vulnerabilities, there is a range of severity and exploitability, which often dictates how quickly a flaw is fixed upon discovery. Most companies prioritize high severity and critical vulnerabilities but ignore lower severity vulnerabilities. The highest severity flaws are less complicated to attack, offer more opportunity for full application compromise, and are more likely to be remotely exploitable — overall they tend to open up a wider attack blast radius.

In the State of Software Security Volume 9, we analyzed flaw persistence based on where vulnerabilities fall on our five-point severity scale, and we found that organizations hit the three quarters-closed mark about 57 percent sooner for high and very high severity vulnerabilities than for their less severe counterparts. In fact, our scan data indicates that low severity flaws were attended to at a significantly slower rate than the average speed of closure. It took organizations an average of 604 days to close three-quarters of these weaknesses.

Here's the catch: there could be a low severity vulnerability that is affecting your code and it could be used to exploit your application.Image title

Is the Vulnerability in the Execution Path?

There's another dimension that often isn't taken into account when prioritizing fixes, and that's whether the vulnerability is actually impacting the code. When it comes to open-source risk, for example, we know that it is multi-faceted and complex. Simply having a library with vulnerabilities in it does not mean that your app is at risk — you have to first understand if a vulnerable method is being called. When leveraging an open-source library, it's very common for a developer to only use a small subset of that library for a very particular function or capability. This means that it's very likely that your application never calls on a vulnerability in the library and, in essence, is not exploitable.

Rather than prioritizing fixing a high-severity vulnerability in a function that is not called by your application, it would be more advantageous to prioritize a medium-severity vulnerability that lies in the execution path and puts your customers at risk. When developers have this information, they are empowered to prioritize and immediately fix vulnerabilities that pose the highest likelihood of exploitation. Additionally, their remediation time is reduced by up to 90 percent. The time saved for your developers, and the decreased time the attack window is open, is crucial to protecting your data.

That being said, just because a vulnerability isn't in the execution path doesn't necessarily mean your application isn't exploitable — it may simply mean we were unable to identify an execution path for the vulnerability. It's still important to fix all of the vulnerabilities in your application, especially the high and very high ones. Vulnerable method information allows your team to know, out of all of the vulnerabilities detected, which ones have the highest likelihood of exploit.

Vulnerability Schedule (computer science)

Published at DZone with permission of Laura Paine, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Understanding gRPC Concepts, Use Cases, and Best Practices
  • Distributed SQL: An Alternative to Database Sharding
  • The Future of Cloud Engineering Evolves
  • Using the PostgreSQL Pager With MariaDB Xpand

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: