[carapace]

> Really? What about all the dependencies from those dependencies?...

Yep, all the way to the end.

I got the idea from a book called "Hollywood Secrets of Project Management Success" by James R. Persse. It's two books interleaved really, one is just a standard pitch for Agile methods (IMO), but the other is a presentation of the process that large film studios use to make movies. The movie industry is ~100 years old and mostly very good at bringing in projects on time and under budget.

Somewhere in there he talks about how they'll track their dependencies in a kind of "portfolio", I forget the details, but it translates in IT to a "dependency portfolio" and you would (if you're large enough) have an actual "Deps Dept." and a Deps Manager whose sole job is tracking dependencies and their updates and patches, etc.

> working on an app that has 82 npm dependencies

Ach! Well, see, there's your problem right there. :-)

Seriously though, one of the benefits of a dependency portfolio is to help you know when your system has gotten out of hand. The problems are still there even if you don't look at them, eh?

> It's absolutely ridiculous to investigate all of them... but it's also necessary if you want to be sure...

Ya feel. ;-)

[gitgud]

Thanks for the response, that's an interesting way to deal with it. How do you verify a dependency? Do you literally examine the source code? Make sure the build is reproduced? or just the meta data? (downloads, stars) has the portfolio actually prevented any vulnerabilities?

It's pretty common for JS projects to have thousands of transitive dependencies, I'm not sure keeping a private portfolio is much use. The entire open-source ecosystem is built on the foundation of trust, if I use a package that's being used by 500 other packages, I can have a high degree of certainty that the package is safe, and by locking the dependencies with yarn.lock I can prevent sneaky updates from entering the system.

Anyway maybe I'll look into the dependency portfolio, see how it goes.

[carapace]

Cheers!

> How do you verify a dependency? Do you literally examine the source code?

Yeah. It's part of the overhead of using the software. You also look at the history of bugs and how they were handled.

> It's pretty common for JS projects to have thousands of transitive dependencies

Yeah, I know, and it's bonkers IMO.

> The entire open-source ecosystem is built on the foundation of trust

In practice, yes, but in theory, no. The whole idea is that you get to see the code you're running, because the guys who wrote it are clowns. Free Software started when RMS wanted to fix his printer and Xerox said, "No."

> if I use a package that's being used by 500 other packages, I can have a high degree of certainty that the package is safe

I think history has shown that that reasoning is at best probabilistic, eh? You're gambling.

Now, of course, there are limits. Some things get a pass. Do we audit the source of the bash shell? No, despite the fact that it's maintained by a single volunteer.

> Anyway maybe I'll look into the dependency portfolio, see how it goes.

Check out that "Hollywood Secrects" book I mentioned.

[amoitnga]

Thanks for sharing. It would be very interesting to know some of the examples when it payed off. Could you please share?