It will be hard to escape 2017 without a new-found respect for the importance of application security. The Equifax breach, resulting from an exploit of a well-known vulnerability in Apache Struts, and which affected 143 million individuals, was the headline-grabber.

But Node had some vulnerabilities of note too. In July, a flaw in the build configuration of Node made it possible to exploit a bug in the hash table implementation to create a denial-of-service attack. In September, a flaw in Node 8.5.0 makes it possible to access the underlying filesystem. And in October, a change in zlib created an easy to exploit denial-of-service vulnerability.

But of course, the most well-known incident in the Node world was the August discovery that NPM typosquatting led to the potential for exfiltrating secrets. As we’ll see, it maybe isn’t surprising that developer trust in third-party dependencies is extremely low.

Yeah, that’s right. We have some data. In September and October, in conjunction with NodeSource, we asked over 250 Node developers their opinions on the state of security in the Node world. And we found things. Unsettling things.

Let’s dig in, shall we?

On the basis of the survey results, it’s pretty clear that we Node developers understand that we live in rough times. Nearly three-quarters (71%) of us believe that our job requires taking security seriously.

We also rate the likelihood of a large-scale attack against our organization within the next six months at something like 1 chance in 3 (average 34%). Put another way, we believe that over the course of the next 6 months, one-third of our companies are going to get attacked. Not little tiny attacks, but large-scale attacks. One-third of us. This is a little bit paranoid. In a good way.

In short, we recognize that as Node developers, we work in an adversarial environment.

We know also that writing secure code is hard work — web apps are complex beasts with many moving parts. So it’s no surprise that we aren’t very confident in the security of the code we write and run. Only 40% of us are confident in the security of our applications as a whole, and only 31% of us are confident our own code doesn’t contain vulnerabilities. That’s not a lot of confidence.

Of course, other people’s code is always worse than our own. We do have a lot of faith in the Node Foundation—84% of us have at least a moderate level of confidence in the security of Node Core.

On the other hand, 40% of us believe that third-party modules pose the greatest risk to application security. Merely 17% of us are confident the third-party modules we depend upon are vulnerability-free.

Turns out, not much.

Given this healthy skepticism around the security of the code we’re using, it would seem logical for us to seek out the best possible tools to help secure our applications. But surprisingly, that’s not what happens.

There’s a lot of great tooling out there for us to use. But less than a third (30%) of us use combined manual and automatic code reviews to search for flaws in our code. Despite our strong concerns about third-party modules, less than a third of us (30%) use automated tools to discover vulnerable modules in our dependencies.

So while we consider security to be an important part of our roles, we don’t prioritize identifying vulnerabilities in our own code or in third-party modules.

One lingering question: Why? Why the disconnect between our beliefs and our actions? Why don’t we step up and work harder to ensure our apps aren’t vulnerable?

Scarier yet is that we’ll never see that large-scale attack coming, the one that frightens us so.

Prevention is a key piece of the security puzzle, but identification and remediation of attacks is also critical. How do we know if our application is under attack? Most of us (44%) look at the logs—but logs are not especially useful when looking for attackers, as they don’t contain enough information. More to the point, if your app sees heavy traffic (hockey-stick growth, Y’all!), finding a comparatively rare event like an attack is nearly impossible for a human to do in real time.

Over a tenth (11%) of us rely on our APM to help us find attacks. APMs are great at helping us identify spikes of 500 activity, which is a good sign that someone is trying to break in, but they can’t tell us when someone is exploiting a zero-day.

Unbelievably, over one third of us (35%) simply admit we have no way of knowing we are under attack. Y’all, come on! We can do better.

Only 9% of us are willing to admit we use a security information and event management (SIEM) tool, a tool designed to monitor our application’s security.

What does this mean? Ignoring those who rely on APMs (which are dubious for security monitoring at best), the vast majority of us (79%) are basically flying blind, and have no way of knowing when we are actually under attack.

Which might be OK if we were using some kind of real-time protection tool. But less than a quarter of us (23%) use any form of real-time protection against attacks. So that’s no good either.

In short, we understand well the risks of operating in the open internet. We understand the complexities of building reliable, secure code (because we are pessimistic that we are actually doing that). But we are unwilling to take advantage of tools that can help us identify and mitigate threats. We don’t even know if we are under attack. It’s hard to square these facts. It’s time to put actions to our beliefs, and take charge of our security!

 

 

The post State of Node.js Security 2017 appeared first on Sqreen Blog | Modern Application Security.