Add Static Code Analysis tooling to CI pipeline

[wpank]

As this will use the controller seeds to nominate, some precautions should be taken so that code can't exploit these. Adding in Static Code Analysis tooling as part of the CI pipeline can help mitigate this.

Some possible solutions:

• JSPrime
• SonarJS
• NodeJsScan

@kirushik @dud1337 any thoughts on these?

[dud1337]

From our discussion, I can recommend trying both JSPrime and SonarJS (has a node.js module). Seeing what the load/timing from having both of them as CI is, and comparing if any is a strict subset of another.

[kirushik]

The cheapest way would be to extend existing ESlint with security plugin. It's not very smart (since it is pretty local in its view of the code, being a linter on the first place) — but will get us at least something for very little effort.

JSPrime seems to be unmaintained; taking in account Dudley's preferences above, SonarJS it is then?

EDIT: eslint-plugin-sonarjs seems to be a very limited subset of all 140 rules of SonarJS and probably shouldn't be considered a viable option.

[lsaether]

Should we consider this closed with the addition of eslint-plugin-security in #33 or keep it open until we add SonarJS?

[kirushik]

@lsaether set of rules for eslint-plugin-security vs set of rules for SonarJS.

I suggest us keeping this issue open till we plug in SonarJS; without it, we might forget — and it seems eslint only provides some very basic subset of all the checks we might want to ahve around our codebase.

[sascha1337]

static analysis definitely makes sense to have as some additional github action on top, scanning for known heuristic xploits and fraud patterns :) good idea +1