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.
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).
7 comments
[ 3.3 ms ] story [ 33.8 ms ] threadeg) 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.
> 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