4 ms·

Have seen the same pattern in the JS npm ecosystem. Npm audit predominantly cries wolf on security issues and rolling things in, license permitting, is one of

Have seen the same pattern in the JS npm ecosystem. Npm audit predominantly cries wolf on security issues and rolling things in, license permitting, is one of the most reliable ways of not getting inundated with bogus issues from users (who either don’t understand the context or who don’t care because their employers’ policies around these things was created in a space divorced from reality.) (No, that regex being used as a part of your build pipeline’s transitive dependencies’ codebase is not actually something which can be exploited for a DoS attack.) The ”issues” for deeply transitive dependency can be especially annoying to work around. Trouble is that the way things are structured you often can’t technically establish ”no, we will never enter that codepath so aren’t affected by flaws in it” or ”the only way we enter that codepath is with trusted input in an offline setting”, etc.

zozbot234 3y ago
> Trouble is that the way things are structured you often can’t technically establish ”no, we will never enter that codepath so aren’t affected by flaws in it” And even then, you could enter the problematic paths in future releases as your dependencies update.
icambron 3y ago
> No, that regex being used as a part of your build pipeline’s transitive dependencies’ codebase is not actually something which can be exploited for a DoS attack. Yeah, issues in dev dependencies are such a headache in the JS world. There exist scenarios in which these matter (a compromised build tool injecting malicious code into the lib you’re building) but they are vanishingly rare and hidden under the tidal wave of DOSable regexes that don’t matter at all when you just call them in your build. Couple that with typical build tools having a transitive tree of 50 gabillion dependencies and it’s a real slog. I think the tooling for reporting on these issues needs to differentiate “exploitable if you redistribute” vs “exploitable if you use in a build pipeline”.

zozbot234 3y ago

> Trouble is that the way things are structured you often can’t technically establish ”no, we will never enter that codepath so aren’t affected by flaws in it” And even then, you could enter the problematic paths in future releases as your dependencies update.

icambron 3y ago

> No, that regex being used as a part of your build pipeline’s transitive dependencies’ codebase is not actually something which can be exploited for a DoS attack. Yeah, issues in dev dependencies are such a headache in the JS world. There exist scenarios in which these matter (a compromised build tool injecting malicious code into the lib you’re building) but they are vanishingly rare and hidden under the tidal wave of DOSable regexes that don’t matter at all when you just call them in your build. Couple that with typical build tools having a transitive tree of 50 gabillion dependencies and it’s a real slog. I think the tooling for reporting on these issues needs to differentiate “exploitable if you redistribute” vs “exploitable if you use in a build pipeline”.