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.
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.
Originally published on Remy Sharp's b:log