I personally hate the posts that include "considered harmful"…and yet, here we are. My first "considered harmful" post. Hopefully my last, but we're still young on the web.
Github has launched security alerts recently, and as much as I hate to write, I think the first swing at it is considered harmful.
READER DISCOUNTSave $50 on terminal.training
I've published 38 videos for new developers, designers, UX, UI, product owners and anyone who needs to conquer the command line today.
$49 - only from this link
Before I start
Before I go slam some feature, I want to start by saying that the developer (or developers) that worked on this project should still be super proud. I don't like myself any better for posting a negative thing about some hard work that other people have done. For that: I'm sorry.
This post is in the context of a Node developer, and I'm unsure if any of the issue even applies to the other languages that Github are supporting.
Potential security vulnerabilities…
To be clear: Github is suggesting there's the potential for a vulnerability. Except that this notice is now starting to appear across a lot of my repos (in fact, it's appeared on most of my repos that I've visited lately).
In the top right of the alert is a "dismiss" button. I want to click it, but I'm worried that if I do, I'll be dismissing something serious.
Following the link to review the dependencies, here's what I see, for the nodemon repository:
There's two problems I face here:
- These two particular modules are not dependencies of nodemon. Actually they're deep dependencies (i.e. dependencies of dependencies of dependencies…).
- Worse still, I've no idea how those dependencies made it into my repo, and Github's UI doesn't give me any clues either.
The problem with Github's vulnerability check is that it's based on the
package-lock.json file. Which from an engineering point of view makes sense
from a simplicity point of view as it's shallow and includes all the
dependencies right there in the file. However, this is the full dependency
graph, and not something the author has complete control over.
Finding the source of the dependencies
As it happens, when I was working on Snyk I learnt about
npm's ls command and related grep argument (in fact, in my previous work I've
had to
walk the dependency tree),
so I do have tools at hand to discover where handlebars and uglify-js were
coming from:
The missing option
Although Github is able to identify potential threat inside my software, it doesn't offer any kind of actionable remediation. Remediation, for instance would be to upgrade out of the vulnerable dependency. I appreciate that remediation is possibly outside the scope of what Github, a source control service, can or should do, but without some kind of positive action, we project owners are left with the last resort: ignoring.
Ignorance as an option
Github does allow me to dismiss a vulnerability as "vulnerable code is not actually used", which in my particular case is true. Both these dependencies come through developer tooling that isn't ever exposed to users (in my case: through semantic release and code coverage).
So I select to ignore…but then it just vanishes.
What if I made a mistake? How do I retrieve that notification or undo it? What if the same vulnerability is introduced via another dependency later on in the project's life – is the vulnerability ignored or is Github's algorithm smart enough to know it's introduced through a new path?
This worries me because all of a sudden I'm blind to the decision I made. Ignorance being bliss and all that…
"Not my responsibility"
The other options in the Github dismiss list are interesting too. Since I can't find how to undo I've not tried them out.
I wonder what "This project is no longer maintained" does, and whether this marks the project somehow? That could be interesting as functionality inside of Github, but as for (potential) vulnerabilities, this seems like just another way to ignore the problem.
Harmful
Yes, harmful, really. The harm is in negative the long term effect, certainly for node developers out there. The long term effect (I fear) is apathy and blindness towards security notifications.
My main concern is that in many cases, there's nothing the owner of the repository can do about the vulnerability which only leads to a default position of ignoring the security issue.
This reinforces an anti-pattern of: security is hard to fix, so I'll hide it away, ignore and eventually forget about it.
What is the right thing to do?
Again, this is entirely from a Node perspective. I think, the right thing to do is to blanket ignore and dismiss any and all warnings from Github. Importantly though, this does not mean the potential vulnerability has been addressed nor ignored. It means that the notices from Github have been ignored.
Actionable remediation or intentional ignoring with an explanation is, I think, the right thing to do. Having worked on Snyk (a code security project) and having dabbled with NSP (Node Security Project), I know that both of these tools offer actionable remediation, and both offer integrated pull requests into your projects.
Both these projects also have a much more comprehensive vulnerability database (and IIRC they share intelligence about vulnerabilities).
If you're a developer working on any size project (small to large-team based), I'd make this my recommendation for security: disable/ignore Github, and put in place Snyk or NSP.
Disclosure on vulnerability database
Github does say in their announcement blog post that they're using the National Vulnerability Database (though surely national doesn't quite cover our global web…!), but what I found interesting, is that in the particular project I was looking at Github identified two potential vulnerabilities in two separate dependencies: both were development dependencies.
However, upon testing with Snyk, the snyk command line tool found two
vulnerabilities in my production dependencies. By default, Snyk doesn't test
development dependencies (since they'll typically remained offline). This is
understandably because Github's database of vulnerabilities is still new and
needs maturing.
The wider anti-pattern
One of the speakers (I can't remember which, sorry) from ffconf 2017 mentioned
in their talk that we (as web developers) tend to ignore the warnings that spew
out of an npm install process. Certainly I could identify with this. I ignore
the messages because often they're something I can't do very much about, or
don't care very much about.
Except after a while, I become blind to these messages, ignoring them and even going so far as to tell others "just ignore those messages". This is far from good.
Since ffconf and that passing observation about littered console messages, I'm
trying to be hyper aware of warnings and notices that are shown. If they need to
be actioned: I should action them, or certainly file some kind of issue so that
at least I won't forget. If I have deprecated modules in my project: I need to
upgrade. If I have security vulnerabilities (notified through snyk test), I
need to remediate. If I can't remediate: I need to purposely ignore and ensure
there's a reason.
I suspect I'm rambling now, but you get the point: let's make our warnings actionable.