https://snyk.io/wp-content/uploads/blog-head-default.png

Exposed or not, vulnerabilities are dangerous

November 8, 2017 | in Vulnerabilities
Tim Kadlec
| By 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.