You may have heard about Github Security Alerts and received some for your projects (if you are an open source maintainer, probably a LOT of them!)
Well, that sounds so promising, doesn't it? But the truth is that most the cases are false-positive, non-effective or a security alert doesn't provide any solution! In this article, I will try to explain about reasonings why GitHub security is not good protection and a workaround to avoid spams in your email.
For npm package maintainers
Package dependencies are usually specified with a caret (^) or tile (~) range (learn more about semver). This means even if you don't explicitly upgrade to a patch or minor version of a dependency, fresh installs of your package receive the patch of the dependencies so you shouldn't worry.
dependabot (which is acquired by Microsoft/GitHub and now enabled by default on all repositories) tries to just update lock-file in the repository. This doesn't fix anything for your package users as lock file is not published with your package and will not be used by package managers when someone installs your package. So what's the benefit? Probably nothing! unless dependency is harmless itself by execution (for example running malicious code or leaking tokens) which in this cases npm security team will take fast action and remove tarball from the registry, before any disclosure. Also, many security alerts are usually related to devDependencies which are totally irrelevant as these dependencies are probably used for your local environment and not affecting end-users if there is a bug into them. (at least is not a security problem!)
For end-projects
If you have a GitHub project that powers a public website or an API, it really matters that you receive security patches ASAP and deploy them. But personally, still don't feel good about having GitHub eyes on all of my projects by default:
- Many of my personal GitHub repositories are temporary projects or examples and are not going to be updated. A regex DDOS is irrelevant for them and it is just annoying about GitHub that frequently requests me to update their dependencies.
- Many of security alerts are false-positive or related to
devDependencies. Like a potential bug in a jest dependency. Certainly, an attacker does not write a test that runs in CI to break it and it is not really a security alert.
I wish it could be enabled on only projects that I need, not everything! and also there were some options specifying behavior. I don't want to advertise but I had a much better experience and customizability by using Renovate Bot. Another option is snyk which regularly checks your project against known security alerts and more importantly, it provides automated patches for high-impact vulnerabilities (not just alerting)
Disabling GitHub Notifications
Go to the notifications section of your GitHub profile and change preferences according to your needs:
Skipping email alerts from inbox (Gmail)
Even by disabling notifications you will still receive LOTS of emails from GitHub security. You can label them to skip the inbox and go to a specific category or archive by default.
First, open Gmail and search for to:(Security alert <security_alert@noreply.github.com>). Using the dropdown button right to the search box, open more options:
Then click on Create filter to create a filter and configure it according to your preferences:
Disable automated pull-requests
Unfortunately, automated pull-requests are enabled by default for all of your repositories but the good news is that you can still disable them one by one by going to "Security" tab of each repository and selecting "Off: Automated security fixes" from the dropdown:
Conclusion
Never ignore security for your project. If you are the author of a popular npm package or critical website. In this article, I tried to explain why (current) GitHub security is not probably the best tool and provide a way to give back freedom choosing tooling for security checks.
GitHub platform is powering thousands of opensource projects and for sure there is a good intention about new integrated security checks. But it could be better, allowing more customization and considering the facts about semver versioning and also the freedom to opt-in for security alerts. Having lots of irrelevant security alerts makes it harder to observe real security bugs.
Top comments (4)
Thanks for this post!
I have two things that I want to talk about:
Just my thoughts. :)😇
About (1), Referring to Yarn docs:
Indeed, lock-file is necessary for a final project but not for a dependency,
I mentioned it in
For npm package maintainerssection. Let's saynuxtif has a vulnerable dependency (locked by lock file in nuxt repo) they should explicitly bump it. Updating the lock file is not effective for end-users. Also, end-users can bump all dependencies up to the specified range by usingyarn upgrade. This means it is not necessary to nuxt (but recommended) to even publish a new version. Your NPM dependency tree is self-healing thanks to semver ranges and lock file for nuxt is just for nuxt development.About (2), we can categorize
vulnerabilitiesinto two categories:a. Security bugs like a DDOS or Memory leak which can be possibly abused by hackers
b. Intentional malicious code published by one of the dependencies
Actually, you are certainly right about the case (b) but the fact is that GitHub security alerts are mainly for (a) and for case (a) devDependencies are not used for production but internal stuff or building project. If webpack uses lodash which is potentially vulnerable to a DDOS attack it is not a security concern.
For case (b) which is rather rare but really bad, it is the responsibility of NPM security team to unpublish them from registry as soon as possible! GitHub alerts are for public disclosures. Not even this is not GitHub's job when they make us aware is probably too late and they can almost do nothing. Such a vulnerable package should be removed from NPM CDN as soon as possible before anyone downloads it.
Chiming here again since the nuance of
yarn upgradeornpm upgradewouldn't impact your nested dependencies. So for example, if nuxt brings in a vulnerable version of say debug module, doing a yarn upgrade will not upgrade debug. Only if nuxt is up to date with its package.json manifest to bring in a fixed version of debug, then upgrading nuxt will fix the issue.I wrote in the past a more elaborate post about making sense of package lockfiles if it helps: snyk.io/blog/making-sense-of-packa...
Nice write-up Pooya. Love seeing how developers further embrace Security ✨
I wanted to point out a nuance with regards to the relevancy of security fixes to package maintainers, and essentially those authoring libs and not end-user applications - where-as GitHub/Dependabot will update the lockfile directly, Snyk updates the package.json manifest as well, and so if a security fix for example is provided via a change from a nested dependency of say
5.2.1version to6.0.0then this directly affects your end-users, as a next install will actually be grabbing the fixed nested dependency.