Anyone can publish their Node.js package to open Node Package Manager (npm) pool.
Is there any security checks for published packages so that I can be sure that a new package won't contain any harmful code?
Also it's interesting to know if there is any voting system for node packages so that I can pick out the most voted package from a bunch of similar node packages?
The Node Security Platform is a tool designed to help developers do just that! You can test your project dependencies for known vulnerabilities in a variety of ways - from the command line, integrated with your CI system, or integrated with github.
The vulnerabilities are discovered via two sources:
A team of seasoned node.js security professionals actively auditing modules on npm.
Submissions from community members, which are verified by the aforementioned team.
It's also free to use the command line tool, as well as integration with open source github repositories.
If you are using npm enterprise, nsp is also partnered with npm to provide sidebar integration. This allows you to see vulnerability information right from the npme web ui, which sounds like what you are looking for.
As far as module popularity goes, there is a website that does this to some degree at nodejsmodules.org. I use it from time to time, but beware - they've got a very expired HTTPS cert.
Disclosure: I am an employee of ^Lift Security, the company behind the Node Security Platform.
You can also use https://nodesecurity.io/ to add security checks into your GitHub pull request flow.
If you perform a search on npmjs.com before pulling a module into your system the index of all packages on npmjs.com takes into account maintenance, quality, etc."
npm search is also a good option for npm package voting.
The npms analyzer continuously analyzes the npm ecosystem, gathering as much information as possible from a variety of sources, including GitHub, David and nsp. Using the collected information, a final score for each package is calculated based on four different aspects: Quality, Maintenance, Popularity, and Personalities
Related
Q. How can the generator-jhipster leverage an internal distribution point, e.g., Nexus NPM, &tc. for jhipster blueprints?
Background
We are adopting JHipster for several major application and service initiatives building on the Java and Angular integration and tooling. We will have changes to some of the standard behaviors and will introduce an internal blueprint and a corporate theme (meeting branding standards).
What is not clear in the documentation is distribution of the blueprint and theme. Our blueprints and theme are not, naturally, suited for distribution on the JHipster marketplace.
A .blueprint folder is an option but not ideal for multiple teams and what may be many projects. npm link is not a shared configuration, requiring each team member, across multiple teams, working in different sprints cadences, &tc., to execute. I've given some consideration to git submodules, and while recently improved in Git, has dev workflow friction—and is esoteric enough—that adoption and maintenance might have to high a threshold at scale (and don't get me wrong, I loved—loved—the "vendor branch pattern" seen in SVN, coupled to SVN exports.)
Is there a hook into the generator to point to an internal distribution point?
Thanks!
I think I answered my own question reviewing other blueprints.
The JHipster Marketplace is optional and promotes blueprints for wide use. A blueprint may or may not desire this visibility.
Blueprints are NPM packages
As an NPM package, the "namespace" consists of the prefix generator-jhipster-, e.g., generator-jhipster-myblueprint and is resolved from a registry.
Given #3, if your organization has an NPM registry, e.g., Nexus, Artifactory, other, generator-jhipster --blueprint myblueprint resolves normally.
Feedback is appreciated.
I am developing an app that needs to use Binance API. I found an NPM package https://www.npmjs.com/package/#binance/connector
But I am not sure if it is an official one or created by someone else. What are the criteria to identify a good npm package by good I mean not containing any malicious code.
The NPM package links to a GitHub repo. The GitHub repo readme links back to the NPM package. So far so good.
The GitHub repo is published under the binance organization, which has the verified tag with comment:
We've verified that the organization binance controls the domain: www.binance.com
So assuming that we can trust the GitHub verification process, this particular NPM package is legit and really comes from Binance.
General rules of thumb to roughly identify a level of trustworthiness of an NPM package:
Published by a verified organization.
Downloads amount. A package with 1k weekly downloads is more likely to be legit, compared to a package with 1-2 downloads a week.
Size of a community around this package. Look for the number of contributors and, official website, support forum with active users. These are the signs that the package is probably all right.
If the package is business critical for your case, always do your own due diligence and look through the code.
i recently built an electron app using node js , html ,css , js
and have been wanting to compile it ive npm installed all options ifound (packager,build,forge) but npm says all have security issues is there asecure way to compile? (compile for windows)
most of the security vulnerabilities are mostly in "build" packages, things that are run during compile time only, and not when the electron/nodejs app is in use, only when it's built/minified/etc, but they are not included in the final product.
Then also are most of those security vulnerabilities usually highly hypothetical, with a high threshold of prerequisites for the weakness to occur.
If you wish to be certain, read the security risk descriptions, what is required, and evaluate if it applies to your system, if it's in a build time package, or a runtime package, and what kind of vulnerability it represents.
if there is a vulnerability in a package that gets included in the app, and it is one that you need to fix because it would pose a serious threat to your end users, check the repository for the package, to see if someone already submitted a pull request for a fix that hasn't made it to the main branch, and merge that into your version that you use.
My Node application needs to be deployed on Windows and Linux. The main deployment package is built on a Linux CI server.
When this package is deployed to Windows, it crashes immediately due to missing native bindings, such as those for sqlite. Only the bindings for the build platform (Linux) are restored.
With a deadline approaching, we just set up a Windows build configuration which outputs a Windows specific package that contains the appropriate bindings, and we choose the appropriate artifact to bundle in the installer.
This works but feels fragile, as we would need to keep the Node versions in sync between the two otherwise unrelated environments. I would like to be able to do this with a single build configuration.
I couldn't find any guidance on how this is done. I'm imagining a command-line option like --platform=windows to npm ci, or a modification to package.json but I couldn't find any information about this. Presumably this is a reasonably rare requirement, and perhaps there is no tooling around this, which would be a shame.
Another requirement is that the application must be installed without an internet connection. We cannot run npm ci or npm install when we install it as some of our clients do not permit their servers to access the public internet.
Based on your requirements it sounds like building a package on each required platform would be the safest bet, with the least number moving parts to go wrong.
As the comments have suggested most projects rely on an npm install on the required platform so you are stepping into not that common territory.
This works but feels fragile, as we would need to keep the Node versions in sync between the two otherwise unrelated environments. I would like to be able to do this with a single build configuration.
Node uses NODE_MODULE_VERSION (displayed on the releases page) to track ABI compatibility for native modules. This only changes with a new major Node release number.
The CI builds would need to create app packages for each major version of Node you run on each platform. Keeping the Node.js major versions in sync for the application a good thing in any case. Running Node N and N-1 builds until that can be achieved is good cover and probably the best option with the air gap requirements.
NPM Cache
If the air gapped clients are largely on common networks, an NPM cache/proxy (nexus/verdaccio) may be of use. The NPM cache will need a process to snapshot the repo after a production npm install on all required platforms, to be pushed out to your endpoints. Unfortunately binary modules are often distributed out of band from NPM so won't be stored in regular NPM caches. Each client instance will need a complete build environment to build any native modules from source which can sometime present it's own difficulties on Windows platforms.
Alternatives
Node.js is not a great platform for distributing packaged applications to many diverse clients, especially if you need to distribute Node itself. Any language with an external VM requirement presents difficulties. Nodes package management choices and reliance on native modules exacerbate this.
I've given up in the past and converted clients (albeit thin) to Go, as it lends itself to cross platform distribution a lot better by removing the external runtime requirement and having less variables.
Does npms internal npm audit command use the OWASP security standards when assessing packages for vulnerabilities?
Is there any background information on how npm's packages get audited?
OWASP security standards, as its name suggests, is only a compilation of standards security checks for web applications.
In fact, the npm audit command check for outdated dependencies or known issues. That command doesn't accomplish an audit on the fly. Security issues are raised from several sources, like Node.js security team or Ubuntu security notices for example, or by users like you.
Based on the information we have from npm, it's actually hard to tell if the npm security team in charge of evaluating packages vulnerabilities follow all the recommendations about security from OWASP organisation, but I'm sure a large part of it stays in their minds as security professionals.
Note that NPM also rely on Google cloud security scanner and AWS Penetration testing platform to evaluate security issues in packages.
I know it's late, but the Node Audit Analyzer of the OWASP dependency-check toolset actually uses the NPM Audit API for analysis.
Here is a post from the npm blog that describes the npm audit command. I couldn't find any valid resource that describes how npm audits packages, but I think it might have a connection with The Node Security Platform.