add support/notifications for compromised modules

[pdehaan]

Not sure how trivial (ha) it would be to ping the https://nodesecurity.io/advisories db when displaying modules to show a big scary warning if a user's currently installed module version is known vuln.

It wouldnt necessarily need to integrate with badges, although it may be nice to see a flashing red banner on your GitHub page if one of your modules is suspicious.

https://nodesecurity.io/validate/qs/0.9.9

[
  {
    "title": "qs Denial-of-Service Extended Event Loop Blocking",
    "author": "Tom Steele",
    "module_name": "qs",
    "publish_date": "Aug 6 2014 09:10:23 GMT-0800 (PST)",
    "cves": [],
    "vulnerable_versions": "<1.0.0",
    "patched_versions": ">= 1.x",
    "url": "qs_dos_extended_event_loop_blocking"
  },
  {
    "title": "qs Denial-of-Service Memory Exhaustion",
    "author": "Dustin Shiver",
    "module_name": "qs",
    "publish_date": "Aug 6 2014 09:10:22 GMT-0800 (PST)",
    "cves": [],
    "vulnerable_versions": "<1.0.0",
    "patched_versions": ">= 1.x",
    "url": "qs_dos_memory_exhaustion"
  }
]

[alanshaw]

YES! Will add ASAP!

[pdehaan]

[olizilla]

👍 🔥 🎉

[fhemberger]

But calling the validate endpoint will only check the package itself, not any possibly vulnerable dependencies of that package. E.g. https://nodesecurity.io/validate/request/2.39.1 shows no issues, still this version uses the vulnerable qs@0.9.x.

That's the reason I started working on https://github.com/fhemberger/nodesecurity-badges. It's not in production yet, mainly because we're trying to figure out caching/performance needs (discussion over here: https://github.com/nodesecurity/nodesecurity-www/issues/8#issuecomment-50435354). Maybe you can help with your experiences on david-dm.

[alanshaw]

People will typically use version ranges in package.json for their project dependencies so david doesn't know exact versions being used. Sending a request for each version found in the range isn't scalable from either party's point of view so at the very least I'd be interested in altering the API to also accept ranges.

Secondly, david knows versions and ranges for all dependencies of a project, of which there may be many. It'd be much better (for david at least) if we could query a batch of dependencies and version numbers/ranges in one request. I'm definitely interested in collaborating on an API change to allow this.

The really tricky part is informing users of a vulnerability in a dependency of a dependency (or deeper). David determines the full dependency tree on demand when the user clicks on the "tree" view on a status page (and even then only goes 10 levels deep), so david would only realistically be able to show vulnerabilities of immediate dependencies on the status page or on a badge, unless the user specifically requests the tree view.

From the discussion you've already had (https://github.com/nodesecurity/nodesecurity-www/issues/8), I'd like to chat more about what david can do to inform users of a vulnerable dependency. Off the top of my head a david badge could appear RED if a vulnerability is found in any one dependency. This shouldn't be a tricky thing to implement if node security are prepared for the request barrage it might generate - we should definitely talk more about that! I don't think david has the same problems of misleading users into thinking their dependencies are secure in this respect...:S

[alanshaw]

Initial integration with NSP advisories has landed in david-www@5.2.0 e.g. https://david-dm.org/alanshaw/vulnerable

Next step is to have a badge theme with NSP padlock or something that turns red when vulnerable dependencies are required by a project.

[pdehaan]

[alanshaw]

Insecure badge now served if immediate project dependencies contain vulnerabilities.

e.g. https://github.com/alanshaw/vulnerable/blob/master/README.md

I've also created a PR for shields.io (badges/shields#282) so anyone using them instead of from david-dm direct will also get the goodness.