[HN Gopher] GitHub Advisory Database now powers NPM audit
___________________________________________________________________
GitHub Advisory Database now powers NPM audit
Author : todsacerdoti
Score : 75 points
Date : 2021-10-07 16:06 UTC (6 hours ago)
(HTM) web link (github.blog)
(TXT) w3m dump (github.blog)
| hn_throwaway_99 wrote:
| NPM is down at the moment, so ...
| valkum wrote:
| looking at the latest illissued lodash CVE they seem to deliver
| CVEs that are withdrawn in GH Advisory Database
| ethomson wrote:
| Product Manager for npm here. That was correct. As part of our
| integration, we were not excluding withdrawn advisories. We've
| since corrected this. Apologies!
| AHappyCamper wrote:
| If Microsoft owns Github, then doesn't that Microsoft now
| controls all of npm audit?
| Spivak wrote:
| Microsoft controls all of NPM since NPM is owned by Github.
|
| https://github.blog/2020-03-16-npm-is-joining-github/
| weissed wrote:
| npm audit npm ERR! code ENOAUDIT npm ERR! audit Your configured
| registry (https://registry.npmjs.org/) may not support audit
| requests, or the audit endpoint may be temporarily unavailable.
|
| looks like everyone's trying it :)
| kronin wrote:
| Or NPM is having issues ;-) https://status.npmjs.org/
| sahkopoyta wrote:
| that's the point :-)
| samcgraw wrote:
| Dan Abramov has an interesting take on npm audit
| (https://overreacted.io/npm-audit-broken-by-design).
|
| Scanning through the vulns on GitHub Advisory Database, it looks
| like it still contains many that DA brought up as unhelpful at
| best (e.g. "Regular Expression Denial of Service").
| underwater wrote:
| The irony is that those useless "Regular Expression Denial of
| Service" alerts create their own denial of service attack
| against `npm audit` consumers.
| DeepYogurt wrote:
| I for one do like to know when I have a denial of service
| vector in my app.
| vorticalbox wrote:
| Just because there is a cve in a dependancie does not mean
| its exploitable in context of your application.
|
| Say there was a regex dos in nodemon, I only use this for
| local development and has no effect on my main application.
|
| Point is npm audit is an advisory as it doesn't know the
| context in which it used.
| [deleted]
| DeepYogurt wrote:
| > Just because there is a cve in a dependancie does not
| mean its exploitable in context of your application.
|
| Sure, but I'd rather be alerted to the issue so that I can
| investigate.
| gherkinnn wrote:
| Problem is, reacting to these alerts is a full time job.
| And when you're faced with endless false positives you
| stop paying attention and eventually disable it.
| ygjb wrote:
| Then, if you build a successful product, you get:
|
| * ransomware
|
| * free PR from haveibeenpwned (but not the kind you want)
|
| * a burning desire to put my (or one of my AppSec/IR
| peers) kids through college.
|
| That said, YMMV.
| runnerup wrote:
| I think we all agree with this. However, the semantics
| boil down to, if you use n:
|
| - with no advisory database/dependency scanning, you'll
| eventually suffer this parade of horribles
|
| - with an advisory database / dependency scanning which
| results in tons of false positives, you will also suffer
| from the same parade of horribles.
|
| A scanning system with relatively few false positives
| could change the result. But very very few groups can
| afford to follow up on all of these . And those which can
| tend to take ownership of their own dependencies, perhaps
| privately forking them (as Google did with Linux)
|
| Maybe dependency advisor will eventually grow into the
| role we want them to fill and become far more useful.
| It's probably better than nothing in its current form,
| but it's hard to say how much better than nothing.
| kevin_thibedeau wrote:
| Shouldn't there be a Node package where someone's opinion
| of what is a false positive gets automatically applied.
| colechristensen wrote:
| Many of these kinds of things are in places that could never
| actually result in a denial of service. There is a large
| problem with security reporting where people report issues
| which couldn't ever be exploited and then scanning tools and
| up showing hundreds of "vulnerabilities" which don't actually
| represent any danger.
| DeepYogurt wrote:
| I mean, you don't have to use the scanning tools if you'd
| prefer not to know.
| technion wrote:
| The risk that a person could potentially write an
| infinite while loop and commit it to a codebase is about
| the same as the threat posed by the DoS "vulnerabilities"
| that seem to have completely overrun the NPM audit
| system. Noone wants to know about the former risk.
| colechristensen wrote:
| It's not about not wanting to know, it's about wanting to
| know about real security issues and being buried in low
| quality reports which do not need to be addressed.
| Hallucinaut wrote:
| The problem is it gets weaponized. If you're unlucky you
| have a client who runs a scan naively on your software
| and demands these get addressed as critical priorities
| under SLA.
|
| I'm sure there are plenty out there with managers who
| will just run the report and demand these "security
| issues" are fixed and won't understand an explanation on
| why it's not relevant.
| bawolff wrote:
| This is a silly objection in my opinion - clients demand
| unreasonable things all the time. Its up to you to write
| a reasonable SLA that protects yourself.
|
| Dont get me wrong, i wish npm audit was better. But
| unreasonable people will be unreasonable regardless of
| the tools they have access to.
| gauravphoenix wrote:
| couldn't agree more- we built Dassana [1] so solve this
| problem by adding context to security alerts. Currently we
| support AWS Config/GuardDuty alerts but had been thinking
| of adding context to vuln scan results too.
|
| [1] https://oss.dassana.io/
| TameAntelope wrote:
| How do you feel about false positives?
| onion2k wrote:
| So do I, so when a tool tells me there's a ddos vector in a
| devdependency that never gets put on a live server I ignore
| it. If it happens a lot I start to ignore all those warnings.
| If that leads me to ignore a real warning then the warning
| has had a negative impact.
|
| If you ever heard the story of "The Boy Who Cried Wolf" as a
| child you should recognise what npm audit is doing wrong.
| Floegipoky wrote:
| This is kind of a long story but the short version is that
| the tooling isn't yet able to differentiate between
| dependencies which are packaged and deployed with your
| application vs dependencies which are only used in the build
| process. The canonical example seems to be regex DOS vulns
| reported in a test library. What does an "exploit" look like?
| One of my colleagues writes a bad regex in a test, now the
| test suite takes an offensively long amount of time to
| finish. That's not a vulnerability, that's a broken build.
| Even if they bypassed the automated tests and forced a
| deployment to production the offending regex would not be
| included.
| d4mi3n wrote:
| While I agree that regex DoS isn't a very useful thing to
| highlight in a build, there are risks that come with
| vulnerable code running in CI/CD systems.
|
| There's a whole topic in information security and
| infrastructure hardening that centers around SDLC (secure
| development lifecycle) and it covers such thrilling topics
| as:
|
| 1. Is the code from your SCM the same as the code that was
| built and deployed?
|
| 2. Has anyone tampered with your build or deployment
| artifact?
|
| 3. Who all actually has access to the boxes that do all
| this? Can you tell when folks access your build boxes and
| what has changed on them?
|
| 4. Does your CI/CD system have privileged access to secrets
| or other internal networks?
|
| 5. How confident are you that your digital supply chain is
| reliable and trustworthy? Would you know if someone fed you
| a poisoned dependency?
|
| The list goes on and on. There be dragons here. I'd love to
| see less focus on regex DoS and more awareness around the
| fact that build systems need just as much scrutiny and
| security as the production environments they feed into.
| xyzzy123 wrote:
| People act like tooling that promotes useless busywork is
| "free security advice". It's actively harmful.
|
| Prioritising security activities that aren't useful
| (fixing "regex dos" in dev deps) takes time and effort
| that could have been spent on real bugs or product
| improvement.
| bawolff wrote:
| I think the bigger issue is when people rate ReDoS as higher
| severity than code execution vulns.
|
| But ultimately, vuln lists are just lists not magic. You
| still have to apply them to your context.
| louissm_it wrote:
| Weird, it's breaking Vercel builds too.
| AkshitGarg wrote:
| That might be unrelated to the audit database change as NPM is
| currently having a service outage.
|
| https://status.npmjs.org/incidents/7pqfqvkwvb58
| louissm_it wrote:
| Probably yeah :) The builds fail at the "npm audit" command,
| so I incorrectly made the link.
| mirekrusin wrote:
| They "own" my workplace as well. My editor. My programming
| language. It starts to look bad.
|
| And yes, we have major deployment night and npm is offline,
| nice.
| efitz wrote:
| I wish there was equivalent functionality built into PIP.
| funklute wrote:
| not quite the same thing, but there is
| https://pypi.org/project/safety/
| eranation wrote:
| Is it me or dependabot has a bit higher rate of false positives?
| Does this mean that now npm audit === dependabot then?
___________________________________________________________________
(page generated 2021-10-07 23:01 UTC)