The article doesn't actually talk about preventing injection attacks, but rather identifying potential attack surfaces by doing an AST search for eval/exec in combination with mutable variables. The article does not explain what limitations exist for their runtime check:

> This results in 5 false positives (out of 56 benign inputs), which are caused by limitations of the static analysis (3/5) or node types outside of the safe set (2/5).

Besides that, it's good to see more security tools - especially when the research is open source: https://github.com/sola-da/Synode

Re-writing dependency source files with another dependency is a much worse idea than vetting your dependencies before you add them to your project IMHO

If the only other solution is creating your own custom version of a vulnerable dependency, I can see how this could be useful. Not the "best" solution, but certainly practical as far as making code more secure.

Maybe there's a setting to roll back the install if it finds vulnerable dependencies, rather than trying to fix them?

Everything old is new again. Just when you thought we where done with all the PHP injection madness...

why not add an android-style permission flags on nodeJS?

eg) nodejs profile with:

- exec disabled

- file write access limited to ./tmp, ./docs, ./tests

- file read access limited to ./tmp, ./docs

- network listening: port 1000~11000 allowed

And why not have a 'sesame points' system for dependencies?

eg)

- ownership-change within 3 weeks: -20 points,

- static analysis finds something wrong: -20 points

- badges: 'file-read badge', 'exec-badge', etc.

Isn't the first part of your suggestion handled on OS level anyways? Aka. restricted user access, SELinux, AppArmor etc.