Audit of NPM/NodeJS module dependencies

Andreas Sommer andreas.sommer87 at
Fri Feb 2 21:17:28 UTC 2018

Hi everyone,

npm/node modules creeping into ports was already discussed in the forums[0] and cannot be a viable solution for tracking hundreds+ JavaScript dependencies. Nevertheless, I believe that usage of node is very popular – including use of React etc. for frontends in my company. If you build your software in the freebsd-ports/poudriere/pkgng style, there is no built-in way to detect vulnerabilities of npm modules since they are not tracked as pkg dependencies and therefore also not listed in the VuXML database, thus not checked by `pkg audit`.

I'd like to ask this list if there is at all interest in solving this problem (for FreeBSD Ports) and how to nicely integrate it without having to register every module as port.

Ideas to tackle this:

A) I've already ported OWASP's DependencyCheck tool[1] locally and can immediately open a PR to allow everyone to make use of it. The tool uses several online databases to detect vulnerabilities within a project's source code (namely package.json which lists those module dependencies). It can create both human and machine-readable reports and optionally `exit 1` if the vulnerability score is over a certain threshold (in other words: it's quite versatile). Alternatives include tools like `nsp` which I believe uses a database that OWASP DependencyCheck already covers among others, so I opted for a multi-database tool to cover as many vulnerabilities as possible.

B) My ideas for a solution:

   B1) Run DependencyCheck during the `fetch` phase (only one in poudriere that has Internet access) and spit out warnings or errors that we can react to (e.g. send alarms from CI)

   B2) Run DependencyCheck separately on each port and if vulnerabilities are found, mark that project's latest release version as vulnerable in a custom VuXML file. Patch `pkg` to support multiple `VULNXML_SITE` entries (official one for ports + the one for npm modules). Then production systems' `pkg audit` would detect when packages are vulnerable as usual. That would require an automated system (like portscout) to check all ports regularly and write VuXML entries. I guess false positives may occur, requiring a blacklist file and way to remove the false entries. This solution could also work with just one VuXML file – the official one. Introducing a second one has the advantage of making this feature optional (for the start), not breaking existing systems.

   B3) Both, since B1 is helpful for developers and B2 is helpful for sysadmins. Also, B1 would only error when building ports which *already have* vulnerable dependencies, but obviously dependencies might get a CVE *after* being installed as package, so B2 is needed to run the vulnerability check regularly.

   B4) Similar to B2: include npm module dependencies in package description (+MANIFEST:desc or new field) and then create some automated service to check those dependencies regularly. This has the advantage of not requiring fetch of the source code, so it's much easier to build an automated checker that quickly runs over all ports.

    *) <your suggestions very welcome here>

Looking forward to see if there is interest and great ideas! I also want to hear if someone has concerns and objections to solving this at the ports/package level. Whatever the outcome is, I will implement *something* within my company – but an open source solution would be preferable.


[0] (NodeJS modules creeping into ports)
[1] (OWASP Dependency Check)

More information about the freebsd-ports mailing list