Exposed or not, vulnerabilities are dangerous

著者:
Tim Kadlec
Tim Kadlec

November 8, 2017

0 分で読めます
dock-illustration

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 a while 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.

Patch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo Segment

Snyk (スニーク) は、デベロッパーセキュリティプラットフォームです。Snyk は、コードやオープンソースとその依存関係、コンテナや IaC (Infrastructure as a Code) における脆弱性を見つけるだけでなく、優先順位をつけて修正するためのツールです。世界最高峰の脆弱性データベースを基盤に、Snyk の脆弱性に関する専門家としての知見が提供されます。

無料で始める資料請求

© 2024 Snyk Limited
Registered in England and Wales

logo-devseccon