4 ms·

Just because a dependency isn’t deployed to production doesn’t mean it’s safe. Remember when eslint tried to steal people’s npm credentials? https://news.ycomb

Just because a dependency isn’t deployed to production doesn’t mean it’s safe. Remember when eslint tried to steal people’s npm credentials? https://news.ycombinator.com/item?id=17513709 https://news.ycombinator.com/item?id=17513709

deleted 6y ago
[deleted]
inbx0 6y ago
Sure, but the reported issues are usually not nearly that severe. Most of the time what I see is "A dependency of a dependency of a dependency of Webpack is vulnerable to a Regular expression Denial of Service attack" or prototype pollution or something like that.
- 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 ago
    What 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 ago
      While 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 ago
        But ReDoS does not give them that ability
    - deleted 6y ago
      [deleted]
  - franciscop 6y ago
    You 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).
- silverwind 6y ago
  Also, many times those "vulnerabilites" are not really applicable because the application code can not trigger it if it never ends up in the vulnerable code path (for example when a vulnerable regex is never passed untrusted input). I imagine those cases could be detected using static analysis but the current vulnerability reporting tools that do not even look at actual code are completely useless in that regard.
  - deleted 6y ago
    [deleted]
  - beardedwizard 6y ago
    How many of your customers, who can detect these same vulnerabilities, care about whether or not it's triggered? What about the fact that these are all latent bugs waiting to be hit with an approach like this? It needlessly accumulates risk when you prioritize explaining why things don't need to be fixed rather than just lowering the bar to fixing them

deleted 6y ago

[deleted]

inbx0 6y ago

Sure, but the reported issues are usually not nearly that severe. Most of the time what I see is "A dependency of a dependency of a dependency of Webpack is vulnerable to a Regular expression Denial of Service attack" or prototype pollution or something like that.

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 ago
  What 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 ago
    While 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 ago
      But ReDoS does not give them that ability
  - deleted 6y ago
    [deleted]
- franciscop 6y ago
  You 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).
silverwind 6y ago
Also, many times those "vulnerabilites" are not really applicable because the application code can not trigger it if it never ends up in the vulnerable code path (for example when a vulnerable regex is never passed untrusted input). I imagine those cases could be detected using static analysis but the current vulnerability reporting tools that do not even look at actual code are completely useless in that regard.
- deleted 6y ago
  [deleted]
- beardedwizard 6y ago
  How many of your customers, who can detect these same vulnerabilities, care about whether or not it's triggered? What about the fact that these are all latent bugs waiting to be hit with an approach like this? It needlessly accumulates risk when you prioritize explaining why things don't need to be fixed rather than just lowering the bar to fixing them