3 ms·

You say that as if you even know your full dependency chain. Reality doesn't quite work that way. No one knew their codebase even relied on leftpad until it bro

You say that as if you even know your full dependency chain. Reality doesn't quite work that way. No one knew their codebase even relied on leftpad until it broke millions of applications the world over when it got pulled. Some projects have the benefit of notoriety (log4j falls in that category) but plenty of projects are just "plumbing" and the only thing you know is the name of the dependencies you have in your dependency list. I can guarantee you that except for security audits, no one knows their full dependency tree, and that they have a deeper dependency with itself a dependency on a utility that depends on a thing that no one's even heard of, and no one's looked at for years, and you would never have looked for. While also being one of the critical pieces that your software runs on top of, capable of bringing down your entire product even if _what it does_ is literally trivial. Best case, it fails. Your product/server is now broken (hopefully, for only a short while). But worst case, it has a 0-day exploit. And now your entire company is at risk to the tune of "depending on how bad, you may have just gone out of business because you can't afford what is necessary to both legally and professionally deal with the fallout". (Did your product/service have a database that comes with rather massive fines for leaking that data? Good luck, that might bankrupt you. Does your company have contracts that are void on significant service interruption? Good luck, you may have just lost all your big clients. Etc.)

ohgodplsno 5y ago
> plenty of projects are just "plumbing" and the only thing you know is the name of the dependencies you have in your dependency list. Maybe in the web world. .Net/Java/C/C++/etc projects have a well understood dependency chain, most of the time. Mostly because there is an actual stdlib and having dependencies upon dependencies upon dependencies is very rare. Projects I've worked on with over 150 dependencies (which is an awful lot for an Android project as it was) had a dependency tree that wasn't that deep (5 at most), and all of that was on standard, well known modules (androidx, etc.) The shitshow that is JS dependency management is a self-inflincted wound. Knowing your dependency tree _is part of your job_ as a software engineer.
whateveracct 5y ago
> You say that as if you even know your full dependency chain. Reality doesn't quite work that way. No one knew their codebase even relied on leftpad until it broke millions of applications the world over when it got pulled. We're professionals - we in fact simply can do that with some elbow grease. Doesn't take a genius to understand how software is built.
- charcircuit 5y ago
  There is too much information out there to know all of it. Sure everyone knows how to do it, but it's often not worth the time to do so.
  - whateveracct 5y ago
    My point is it's your collective job as a professional software dev shop to do so. It's a relatively fixed cost too - incrementally knowing your toolchain once you've done it the first time isn't that bad.
- kube-system 5y ago
  The only professionals who actually do this are in heavily regulated industries that require it, which are often criticized as being stuck with "ancient tech". It seems there's currently two ways to tackle this issue: move fast and break things, or move slowly and don't break things.
  - whateveracct 5y ago
    I'm not saying you need to audit every line of code. I'm saying it should be trivial to fork any dependency in your tree. Every project I've ever worked on has met this - but I'm a Nix guy.
deleted 5y ago
[deleted]

ohgodplsno 5y ago

> plenty of projects are just "plumbing" and the only thing you know is the name of the dependencies you have in your dependency list. Maybe in the web world. .Net/Java/C/C++/etc projects have a well understood dependency chain, most of the time. Mostly because there is an actual stdlib and having dependencies upon dependencies upon dependencies is very rare. Projects I've worked on with over 150 dependencies (which is an awful lot for an Android project as it was) had a dependency tree that wasn't that deep (5 at most), and all of that was on standard, well known modules (androidx, etc.) The shitshow that is JS dependency management is a self-inflincted wound. Knowing your dependency tree _is part of your job_ as a software engineer.

whateveracct 5y ago

> You say that as if you even know your full dependency chain. Reality doesn't quite work that way. No one knew their codebase even relied on leftpad until it broke millions of applications the world over when it got pulled. We're professionals - we in fact simply can do that with some elbow grease. Doesn't take a genius to understand how software is built.

charcircuit 5y ago
There is too much information out there to know all of it. Sure everyone knows how to do it, but it's often not worth the time to do so.
- whateveracct 5y ago
  My point is it's your collective job as a professional software dev shop to do so. It's a relatively fixed cost too - incrementally knowing your toolchain once you've done it the first time isn't that bad.
kube-system 5y ago
The only professionals who actually do this are in heavily regulated industries that require it, which are often criticized as being stuck with "ancient tech". It seems there's currently two ways to tackle this issue: move fast and break things, or move slowly and don't break things.
- whateveracct 5y ago
  I'm not saying you need to audit every line of code. I'm saying it should be trivial to fork any dependency in your tree. Every project I've ever worked on has met this - but I'm a Nix guy.

deleted 5y ago

[deleted]