Agreed. I have been trained by npm to ignore its audit messages.
Npm Audit: broken by design?
161–170 of 268 posts
Re: Npm Audit: broken by design?
#162> Inline all dependencies during publish… From a maintainer’s point of view, the upsides are clear: you get faster boot time, smaller downloads, and — as a nice bonus — no bogus vulnerability reports from your users. And when you inlined a version that later really does have a vulnerability, it is not easily flagged or fixed by your consumers. The tension between "upgrades (especially of indirect dependencies) might…
> That npm dependency trees are often insane doesn't help though. I'm not totally sure why they are so insane, but I increasingly think that npm's ability to have multiple versions of same dependency in the dependency tree -- often seen as a huge advantage over other platforms -- is in fact part of the problem. Aren't npm dependency trees so large because JavaScript doesn't have much of a standard library? And also,…
Big part of the insanity is also how projects introduce dependencies for very simple things like padding a number or a string.
Re: Npm Audit: broken by design?
#163I found that much of the underlying cause is those mass reporting regex denial of services as being high severity bugs. So many people are reporting these in tons of different projects: https://github.com/search?q=regex+denial+of+service&type=iss... Anyhow it is just annoying and they broke NPM Audit based on these reports. It is good to fix all possible bugs, but many of these are not anywhere close to the level of…
Isn't this an area where gamification and machine learning could actually be useful, if applied carefully? If people are competing for CVEs, then why not work out a way to better differentiate them them through scoring and make this visible. The goal would be for attention to shift to the scoring instead of only a CVE count. Offer both views of the world, so tools could still fall back on the problematic listings the…
We're kind of already doing scoring in that CVEs are usually graded on severity, but researchers are motivated to inflate the severity of CVEs they find. So the question you'd need to tackle is how does one apply a universal standard to measure the real impact of a CVE?
I suspect it's an impossible challenge, but I only dip into this domain casually so maybe someone has better ideas.
Re: Npm Audit: broken by design?
#164Earlier quoted context omitted.
Slightly related to the lack of a standard library is that a lot of these 3rd party packages come from random people in the community. It’s great that people are so willing and able to share code, but it also means that as a community we put a lot of trust into code that may not be vetted or funded properly. I think we assume that because these packages are open source that someone is making sure they are safe to con…
You only support corporately funded open source?
That’s not at all what I said. C/C++, Python, and Rust are examples of languages that are not owned by a single company yet they are funded enough to be able to provide a stable standard library.
Re: Npm Audit: broken by design?
#165Earlier quoted context omitted.
> That npm dependency trees are often insane doesn't help though. I'm not totally sure why they are so insane, but I increasingly think that npm's ability to have multiple versions of same dependency in the dependency tree -- often seen as a huge advantage over other platforms -- is in fact part of the problem. Aren't npm dependency trees so large because JavaScript doesn't have much of a standard library? And also,…
Big part of the insanity is also how projects introduce dependencies for very simple things like padding a number or a string.
https://www.npmjs.com/package/is-odd
447,211 weekly downloads for what can be done in vanilla JS with foo % 2 === 1;
Re: Npm Audit: broken by design?
#166Dan isn't the first person to notice: https://www.voitanos.io/blog/don-t-be-alarmed-by-vulnerabili... We disable [1] audit entirely because it's not a good default behavior within a monorepo. It spams the hundreds of developers with the list of "vulnerabilities" on every install, but only a few folks should really be upgrading packages. We then run audit in non-blocking CI and track the total number of issues and mos…
We also wanted to use npm audit in our CI process so, instead of humans being careful, we could assert any known CVE stops a staging or prod deploy. Very annoyingly, npm audit doesn't have ignore functionality, at least when I was last forced to use it. I had to hack something together with bash scripts. For vulnerabilities that we determined weren't an issue ever (vuln in frontend framework we didn't use), or weren'…
Wouldn't you want to only stop a deploy if the commit introduced the vulnerability (i.e. the deploy changed the dependency tree).
From my experience most audit flags happen because a new vulnerability is discovered, which means stopping a deploy doesn't actually do anything helpful.
Re: Npm Audit: broken by design?
#167So I don't work as a security professional but what I remember from IT-sec class in uni is that in order to craft an exploit you need to be vulnerable and the vulnerability needs to be exploitable.
If I put a database with default credentials on the internet, there is both a vulnerability and it is exploitable. Bad. If I run a database with default credentials on my dev machine, it is vulnerable, but not exploitable. Perfectly fine.
For real security work you also need to think about impact. Hacker dropping production database = we all lose our jobs. Co-worker connecting to my computer and dropping database as a joke = no real harm done.
So three things to think about: - Vulnerability - Exploitability - Impact
What I really don't like about npm audit is how it presents itself as "security tool" and how vulnerabilities are presented. "6 critical, 10 high vulnerabilities" with a red color screams "fix me now!!!". This is not fair to users because npm has no idea of either the exploitability or the impact of the vulnerability.
Why present users with a prompt "please fix me now!!" and not even mention that exploitability and impact need to be measured first? Seems like they forgot that prompt...
Re: Npm Audit: broken by design?
#168So I don't work as a security professional but what I remember from IT-sec class in uni is that in order to craft an exploit you need to be vulnerable and the vulnerability needs to be exploitable. If I put a database with default credentials on the internet, there is both a vulnerability and it is exploitable. Bad. If I run a database with default credentials on my dev machine, it is vulnerable, but not exploitable.…
Vulnerabilities reported to CVE carry a risk score (CVSS) that conveys this information in standard way.
Re: Npm Audit: broken by design?
#169Earlier quoted context omitted.
Well said. I would add that I think the devDependencies solution is underrated. Not using it is a bad practice. npm has a nice feature, `npm prune --production` which will remove all the dev dependencies for you resulting in a clean build of the program. You can easily have things set up so that none of the development dependencies that have all these audit issues are ever present on your production machines if you d…
If there's a vulnerability in Webpack (a devDependency) that injects malicious code into your bundle, `npm prune --production` won't save you.
This is not a vulnerability (ie. security bug) it's an attack (ie. malicious).
Re: Npm Audit: broken by design?
#170Earlier quoted context omitted.
Big part of the insanity is also how projects introduce dependencies for very simple things like padding a number or a string.
https://www.npmjs.com/package/is-odd 447,211 weekly downloads for what can be done in vanilla JS with foo % 2 === 1;
Which itself depends on is-number package.