Why Vulnerability Scanning Isn't Enough To Protect Your App

Protecting your app from being infiltrated by a hacker is pretty simple. Just don't deploy any code or infrastructure or anything, EVER! While that is one (extreme) way to protect yourself, it isn't really protecting your app because if an app never ships is it really an app? An age-old existential question we won't attempt to answer here. Plus, not deploying your app just feels like giving up. And you're not a quitter are you? I didn't think so.

So, what are your other options then? Your best option sounds pretty similar to the first but with a not so minor addition: Just don't deploy any code or infrastructure that contains vulnerabilities. It still sounds simple but we all know that it most definitely is not.

To keep vulnerabilities out, you have to be vigilant. But is depending on vulnerability scanners being vigilant enough?

Before I address that question, let me first state that the scope of this article is application code, from proprietary code developed within your organization to open source packages that help bring your application to life. I don't discuss protecting other components of your application stack, such as infrastructure, databases, networks, and other potential attack vectors.

Now, back to the fundamental question at hand, which is whether software or application vulnerability scanners are vigilant enough to protect you and your app from vulnerabilities. The short answer is no. At least not how vulnerability scanning systems work today. If they were called ‘known' vulnerability scanners, I would have a different answer. As you likely already know, these solutions only scan your application code for known, well-documented vulnerabilities published in public databases, such as the CVE List and National Vulnerability Database (NVD). They do not scan for unknown vulnerabilities. And unfortunately, all vulnerabilities start out unknown, most remain unknown for a long time, and typically become known only once they have wreaked havoc on unsuspecting applications across the globe.

While known vulnerability scanners reduce the risk of known vulnerabilities finding their way into your app, they also introduce a new and extremely dangerous risk - overconfidence.

Overconfidence in known vulnerability scanning solutions leads to an over-reliance on them, which in turn leads to reduced vigilance in protecting apps from unknown vulnerabilities. Most organizations incorrectly assume that if scans pass then the code is secure or at least as secure as it can be because everything that can be done, has been done. But has everything been done? If I had to hazard a guess, I'd bet developers whom, just last November, blindly updated coa, the popular command line option parsing library, to the latest version that included unknown vulnerabilities, wish they had done more.

What could developers have done to better protect themselves from the coa malware attack? Turns out there were several suspicious signals that a bit of vigilance would have uncovered. The fact that the package hadn't been updated in several years prior to the November update was a pretty strong signal in and of itself. That should have inspired further inspection, which would have revealed more suspicious signals like the addition of preinstall scripts and obfuscated code. Yikes!

What does being vigilant truly mean? Being vigilant means not putting all of your eggs in the known vulnerability scanning basket. It means reviewing proprietary and open source code for insecure practices, whether introduced accidentally or with malicious intent. It means reviewing the code of your entire open source supply chain, including all dependencies. It means researching the maintainers of open source projects and their licensing, security practices, and update cadence. Being vigilant means performing these security reviews each time new or updated code, proprietary or open source, enters your app. It means continuously checking existing, unchanged code for newly discovered insecure practices. It also means you know what to look for and continue to evolve your security reviews as technology changes and new cracks in the armor emerge.

If you're like me, you're starting to count just how many open source packages you leverage. And all of their dependencies. And how often packages in your open source supply chain are updated. It's daunting. And frankly, reviewing code for security vulnerabilities is not why I became a software engineer. But the way I see it, as developers of applications we are responsible for the code we ship, whether we wrote it or chose to include it. I will do everything in my power to keep my applications free from known and unknown vulnerabilities.

Luckily, there are tools like Socket that automate the end-to-end hunt for unknown vulnerabilities throughout your open source software supply chain. I guess it's not as daunting as I thought.