Exposed or not, vulnerabilities are dangerous

Tim Kadlec's avatar Tim Kadlec
An illustration of a wooden dock with a broken board
Illustration by Lou Reade.

Imagine you have a pond in your backyard, with a wooden dock. One day, as you’re walking out on the dock, you discover a board is cracked. It’s close to breaking. You’re faced with the decision to either fix it or let it sit for awhile and get to it later. Now, if you’re the only one who goes out on the dock, it’s not necessarily a big deal. You know the board is broken, and you’ll look out for it (assuming you remember).

But what about the rest of your family? Or the friends that come over? There’s no guarantee that, even if you tell them all, they’ll all remember. Eventually, someone is going to step on that board and get an unwanted bath. All it takes is one person, one step.

Often a library may have a known vulnerability, but unless the site or application in question is using a particular method call, that vulnerability is not exposed. In this case, you would be forgiven for ignoring the vulnerability—it just doesn’t impact your current system.

But the key word there is current. The thing about vulnerabilities is that they’re usually not very obvious. It’s not like the vulnerable method is clearly named “notSafeDoNotUse”. Vulnerabilities are subtle things, typically. One change in your settings, one innocent-seeming method call—that’s all it takes to go from safe to insecure.

Whether or not a vulnerability is exposed today matters, but not as much as some may think. It can absolutely be a determining factor in terms of priority. If you are faced with two vulnerabilities to address, and one is exposed and one is not, you prioritize the one that is exposed.

But it’s critical to address the unexposed vulnerabilities quickly as well. Until you do, it’s a weakness in your application, a chink in the armor. You’re one developer making one code change away from it being exploitable. Resilience matters, and an unexposed but unaddressed vulnerability adds an unnecessary level of fragility.

So much of security is reactive as those doing defense try to keep up with the myriad of ways an attacker will try to attack their system.

Known vulnerabilities that are not yet exposed in your application are not things to be ignored. What they are is a rare opportunity for you to stay a step ahead and lock things down before things go wrong.

With all the challenges we face in trying to defend our sites and applications, we should jump at any chance we get to be proactive in ensuring the security of what we build.

Announcing the 2017 State of Open Source Security Report

November 16, 2017

Today we're excited to launch the 2017 State of Open Source Security Report! The full report is available as a free PDF, and the highlights are collected online.

Why triaging might be going away

November 02, 2017

One of the biggest bottlenecks in security is 'triaging'—the process of validating if a security alert is actually impacting your organization, sizing up the estimated impact, and figuring out how to resolve it. In this article, we'll make the case that we should all be striving to skip triaging and focus on fixing vulnerabilities instead.

Subscribe to The Secure Developer Podcast

A podcast about security for developers, covering tools and best practices.

Find out more

Interested in web security?

Subscribe to our newsletter:

Get realtime updates and fixes for JavaScript, Ruby and Java vulnerabilities that affect your applications