3 ms·

This sucks. Supply chain is such an issue. Even tho we don't currently target any npm releases, I make use of socket.dev to monitor my project by creating an n

This sucks. Supply chain is such an issue. Even tho we don't currently target any npm releases, I make use of socket.dev to monitor my project by creating an npm release for it. But my project BrowserBox (lightweight virtualized web browser) only uses ~800 dependencies including all descendents, with only 19 top-level deps (cool your heels non-JavaScript folks, this is comparatively lightweight for a full stack boing). I'm considering just snapshotting all 800 deps into a @browserbox namespace at npm. And then tracking any vulnerabilities discovered and patching the fixes. It sounds crazy, but that's where we are. At least that way I "own" all the dependencies and can guarantee (up to company security at least) that we don't have supply chain vulns on the Node/JS side. https://socket.dev https://socket.dev https://github.com/BrowserBox/BrowserBox https://github.com/BrowserBox/BrowserBox

galangalalgol 3y ago
I'm not sure what of this is available in npm, but with crates io and cargo, there are crates like cargo audit and cargo deny that your pipeline can use to check for cve in your dependency tree. Your lock file maintains the sha256 of everything in the tree, so there is no need to mirror things to ensure they aren't modified if their repo gets hacked. Pinning a version a few months behind the newest seems to be the sweet spot that avoids new cve and avoids big chunks of rework from sitting on ancient versions then upgrading all at once. Download count seems like a decent way to gauge top level deps against others with similar purpose, but that's just my subjective opinion. Austral uses linear types to give fine grained permissions to dependencies. A graphics library doesn't need file io, a network transport library doesn't need microphone access. That is just a mitigation, but it would be nice to see in other languages.
- chuckadams 3y ago
  npm has “npm audit” which throws out so many warnings on nonsense like ReDos “vulnerabilities” in dev packages that everyone has learned to ignore it. It does active harm to the security of the ecosystem.
bunderbunder 3y ago
"only uses ~800 dependencies" slightly horrifies me. I was horrified to see how much time I started spending fussing with dependency hell after I moved from .NET to Java about 10 years back. And I am currently horrified by how much time I have to spend doing vulnerability updates and fussing with dependency hell in both Java and Python projects nowadays. I think maybe the reason I didn't have this problem to nearly the same extent in .NET is that .NET was relatively late to the automated package management scene. NuGet is relatively young, and, as of the last time I got paid to do .NET work, very few of the projects I worked on had actually adopted it yet. So, at least back then, .NET had a stronger culture of well-focused projects that didn't take on enormous transitive dependency trees. I would also compare this to the recent news about Boeing. Theories abound about why it's gone down the tubes. The one that I find most compelling, though, is that, over the past couple decades, they have focused on moving more of their production out to third-party suppliers, and also cost optimizing their outside supply chain. And that has made their supply chain increasingly difficult to actually manage. The details are different, but in broad strokes it looks a lot like modern software engineering culture regarding supply chain - and some have even argued that this is where Boeing got the idea. Meanwhile, the place I've worked where I found dependency management to be the least annoying - and where we had the fewest problems with quality - was a financial firm that had banned package managers for supply chain security reasons. There's something to be said for code that absolutely will not change unless you explicitly change it. I've heard similar sentiments expressed by friends and acquaintances who work at Google. We did write a lot of stuff for ourselves where others would just import a package, and that was good, too. The in-house implementation would do just what we need, and be held to a higher coding standard. So it was easier to understand, easier to debug, and easier to modify as requirements change. And here's the thing: writing it in the first place is a one-time cost, and one-time costs have good amortization characteristics. The recurring costs of dealing with code that's trying to be everything to everybody can easily be greater in the long run. They generally don't amortize; they compound. Rich Hickey really got me to see how this kind of phenomenon works in his talk "Simple made Easy." Long story short, simple is different from easy. The simpler option tends to look harder up front. But it also tends to be easier in the long run, after you give second-order effects some time to take their toll.
- 3y ago

galangalalgol 3y ago

I'm not sure what of this is available in npm, but with crates io and cargo, there are crates like cargo audit and cargo deny that your pipeline can use to check for cve in your dependency tree. Your lock file maintains the sha256 of everything in the tree, so there is no need to mirror things to ensure they aren't modified if their repo gets hacked. Pinning a version a few months behind the newest seems to be the sweet spot that avoids new cve and avoids big chunks of rework from sitting on ancient versions then upgrading all at once. Download count seems like a decent way to gauge top level deps against others with similar purpose, but that's just my subjective opinion. Austral uses linear types to give fine grained permissions to dependencies. A graphics library doesn't need file io, a network transport library doesn't need microphone access. That is just a mitigation, but it would be nice to see in other languages.

chuckadams 3y ago
npm has “npm audit” which throws out so many warnings on nonsense like ReDos “vulnerabilities” in dev packages that everyone has learned to ignore it. It does active harm to the security of the ecosystem.

bunderbunder 3y ago

"only uses ~800 dependencies" slightly horrifies me. I was horrified to see how much time I started spending fussing with dependency hell after I moved from .NET to Java about 10 years back. And I am currently horrified by how much time I have to spend doing vulnerability updates and fussing with dependency hell in both Java and Python projects nowadays. I think maybe the reason I didn't have this problem to nearly the same extent in .NET is that .NET was relatively late to the automated package management scene. NuGet is relatively young, and, as of the last time I got paid to do .NET work, very few of the projects I worked on had actually adopted it yet. So, at least back then, .NET had a stronger culture of well-focused projects that didn't take on enormous transitive dependency trees. I would also compare this to the recent news about Boeing. Theories abound about why it's gone down the tubes. The one that I find most compelling, though, is that, over the past couple decades, they have focused on moving more of their production out to third-party suppliers, and also cost optimizing their outside supply chain. And that has made their supply chain increasingly difficult to actually manage. The details are different, but in broad strokes it looks a lot like modern software engineering culture regarding supply chain - and some have even argued that this is where Boeing got the idea. Meanwhile, the place I've worked where I found dependency management to be the least annoying - and where we had the fewest problems with quality - was a financial firm that had banned package managers for supply chain security reasons. There's something to be said for code that absolutely will not change unless you explicitly change it. I've heard similar sentiments expressed by friends and acquaintances who work at Google. We did write a lot of stuff for ourselves where others would just import a package, and that was good, too. The in-house implementation would do just what we need, and be held to a higher coding standard. So it was easier to understand, easier to debug, and easier to modify as requirements change. And here's the thing: writing it in the first place is a one-time cost, and one-time costs have good amortization characteristics. The recurring costs of dealing with code that's trying to be everything to everybody can easily be greater in the long run. They generally don't amortize; they compound. Rich Hickey really got me to see how this kind of phenomenon works in his talk "Simple made Easy." Long story short, simple is different from easy. The simpler option tends to look harder up front. But it also tends to be easier in the long run, after you give second-order effects some time to take their toll.

3y ago