5 ms·
Webpack generates code which might be loaded by users and additionally it's very common to run it on a CI server (which can sometimes have network access out to
by lhnz 6y ago
Webpack generates code which might be loaded by users and additionally it's very common to run it on a CI server (which can sometimes have network access out to other machines at a firm).
In general, it's quite strange to me that vulnerabilities in `devDependencies` are considered less important than those in `dependencies`. These dependencies are generally for tools that are run within your company network, and contrary to what people insist, that seems quite risky to me.
- falcor84 6y agoWhat would be the attack vector in this case? Assuming that it's a vulnerability rather than an actually malicious package, how would an attacker exploit something running on your CI server? The only way I see is if they already have the ability to modify your source code, at which point it's of course already game over.
- beardedwizard 6y ago"It's already game over", a favorite phrase of many, but a sign you are giving up before the race has even started. Security and insecurity theater at once.
- bdamm 6y agoWhile it's not always considered a risk, there are many cases where being able to run code on a CI server is a vulnerability.
- inbx0 6y agoBut ReDoS does not give them that ability
- deleted 6y ago[deleted]
- franciscop 6y agoYou don't install your dependencies' devDependencies, so by definition 100% of the devDependencies on your the libraries you use are not a concern! I'm talking as a library author here (thought that was clear?), when a random vulnerability scanner marks one of my devDependencies as having an issue, that in principle won't affect the people using my library (except in some very very rare extreme cases).