5 ms·

Dan isn't the first person to notice: https://www.voitanos.io/blog/don-t-be-alarmed-by-vulnerabilities-after-running-npm-install/ https://www.voitanos.io/blog/

Dan isn't the first person to notice: https://www.voitanos.io/blog/don-t-be-alarmed-by-vulnerabilities-after-running-npm-install/ 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 mostly focus on critical ones. [1] https://docs.npmjs.com/cli/v7/using-npm/config#audit https://docs.npmjs.com/cli/v7/using-npm/config#audit

x0x0 5y ago
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't high priority enough to P0 through, we needed some way to ignore either permanently or temporarily specific vulnerabilities. Given the enormous dependency sets eg react create, you'd think the tools would be better at managing them.
- dane-pgp 5y ago
  > Very annoyingly, npm audit doesn't have ignore functionality I can't believe no one here has mentioned the fantastic tool "better-npm-audit" which can be included as an npm dependency[0] and lets you add specific vulnerabilities to an ignore list. The ignore list is actually a JSON config file stored alongside package.json in the repo, so only one developer ever needs to see the npm audit warning and can mute it for everyone else (after getting their PR approved). Even better, the config file lets you specify an expiry date for each entry in the ignore list, and provide a note, such as a link to the upstream issue being worked on, so that you can periodically be reminded to go back and check if a new version is available which can give more confidence that your code really isn't affected. I think that developers might have to be instructed to use the "--no-audit" option to "npm install" if they don't want to see the (false positive) warnings that the default behaviour produces, and that's a bad habit to learn if not all projects they work on are using "better-npm-audit". I don't know if there is a way to make that option the default on a per-project basis. [0] https://www.npmjs.com/package/better-npm-audit https://www.npmjs.com/package/better-npm-audit
  - x0x0 5y ago
    Thank you! edit: we're going to move to this. My implementation is a is a file with cve to ignore | reason | jira ticket but I think we can slam all that in there. And our expiry is manually checked monthly, so this is a big improvement.
- underwater 5y ago
  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.
  - x0x0 5y ago
    we do daily deploys, so we're mostly using this as a way to check cves across rails and react in a way that fails loudly and doesn't require anyone to step outside their standard workflow. Regardless of whether the new commits introduced the cve or not.
prionassembly 5y ago
Having hundreds of developers work on the same code repository seems insanely complicated. What are the advantages? Where can I read more about monorepos?
- SOLAR_FIELDS 5y ago
  Google is probably the most (in?)famous example of monorepo. All of their code is in a single monorepo. You can read a bit about the approach’s benefits and drawbacks from someone at Google here: https://medium.com/@Jakeherringbone/you-too-can-love-the-monorepo-d95d1d6fcebe https://medium.com/@Jakeherringbone/you-too-can-love-the-mon...
  - x86_64Ubuntu 5y ago
    Does monorepo mean that if I checkout Google Wave, I also checkout the GMail source too?
    - esprehn 5y ago
      Sort of, the google3 monorepo is so large that all checkouts are sparse checkouts. So you have a virtual checkout of everything but specify the subset you actually need. Once you have the tooling to do this you can use the monorepo to store all kinds of interesting things, like built artifacts or the contents of the CDN, since it's basically just a giant hierarchical KV store with a global version.
    - spullara 5y ago
      Yes. And if you improve something used by both of them and have to refactor across the source tree you can do that in a single commit. https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...
    - suhas_rd 5y ago
      yes
- 5y ago

x0x0 5y ago

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't high priority enough to P0 through, we needed some way to ignore either permanently or temporarily specific vulnerabilities. Given the enormous dependency sets eg react create, you'd think the tools would be better at managing them.

dane-pgp 5y ago
> Very annoyingly, npm audit doesn't have ignore functionality I can't believe no one here has mentioned the fantastic tool "better-npm-audit" which can be included as an npm dependency[0] and lets you add specific vulnerabilities to an ignore list. The ignore list is actually a JSON config file stored alongside package.json in the repo, so only one developer ever needs to see the npm audit warning and can mute it for everyone else (after getting their PR approved). Even better, the config file lets you specify an expiry date for each entry in the ignore list, and provide a note, such as a link to the upstream issue being worked on, so that you can periodically be reminded to go back and check if a new version is available which can give more confidence that your code really isn't affected. I think that developers might have to be instructed to use the "--no-audit" option to "npm install" if they don't want to see the (false positive) warnings that the default behaviour produces, and that's a bad habit to learn if not all projects they work on are using "better-npm-audit". I don't know if there is a way to make that option the default on a per-project basis. [0] https://www.npmjs.com/package/better-npm-audit https://www.npmjs.com/package/better-npm-audit
- x0x0 5y ago
  Thank you! edit: we're going to move to this. My implementation is a is a file with cve to ignore | reason | jira ticket but I think we can slam all that in there. And our expiry is manually checked monthly, so this is a big improvement.
underwater 5y ago
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.
- x0x0 5y ago
  we do daily deploys, so we're mostly using this as a way to check cves across rails and react in a way that fails loudly and doesn't require anyone to step outside their standard workflow. Regardless of whether the new commits introduced the cve or not.

prionassembly 5y ago

Having hundreds of developers work on the same code repository seems insanely complicated. What are the advantages? Where can I read more about monorepos?

SOLAR_FIELDS 5y ago
Google is probably the most (in?)famous example of monorepo. All of their code is in a single monorepo. You can read a bit about the approach’s benefits and drawbacks from someone at Google here: https://medium.com/@Jakeherringbone/you-too-can-love-the-monorepo-d95d1d6fcebe https://medium.com/@Jakeherringbone/you-too-can-love-the-mon...
- x86_64Ubuntu 5y ago
  Does monorepo mean that if I checkout Google Wave, I also checkout the GMail source too?
  - esprehn 5y ago
    Sort of, the google3 monorepo is so large that all checkouts are sparse checkouts. So you have a virtual checkout of everything but specify the subset you actually need. Once you have the tooling to do this you can use the monorepo to store all kinds of interesting things, like built artifacts or the contents of the CDN, since it's basically just a giant hierarchical KV store with a global version.
  - spullara 5y ago
    Yes. And if you improve something used by both of them and have to refactor across the source tree you can do that in a single commit. https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...
  - suhas_rd 5y ago
    yes
5y ago