No, most people don't, they even have a hard time keeping library versions up to date.
The best I've been able to come up with is to pick things that have minimal dependencies of their own. It doesn't eliminate the threat, but it does at least reduce it.
Edited: I reached out to some security people and it seems like the following are popular tools for this use case: Snyk / Dependabot / Whitesource.
It's not often I spot anything major, but I figure if I have the time I should do it just in case.
I often look at the code for PHP-extensions, npm-libraries, and similar that colleagues introduce. Just to be sure there's not anything blatently horrid going on.
If you work in a secure environment or support critical infrastructure there are teams whose sole purpose is to approve/deny releasing software regardless of who wrote it. Such teams will typically require source code, written justification, senior management signed approval, and test validation. In the case where source code is not provided, such as closed source commercial software, the vendor will be required to accept liability for all losses due to their software as ratified by a signed contract.
https://github.com/olegmikhnovich/News-API-ruby/blob/master/...
https://medium.com/hackernoon/im-harvesting-credit-card-numb...
It's very annoying, it's not free, and it affects what kinds of libraries I use. My projects have fewer and smaller dependencies than typical because of these self imposed constraints.
On the upside, borrowing a pattern or a dozen lines of code instead of pulling a dependency that will remain 90% unused is really underrated. As is understanding how things work under the hood.
There are definitely some things in React's dependency tree that are a bit questionable if you are sensitive enough to any given problem, beyond just security. For example, packages where the license being used is contradictory between the package.json vs the LICENSE file or the full license terms are not expressed within these but are clarified in the README.md.
Taking a look at your at your github projects and build.sbt... this is quite an understatement.
For example, our company is working on an app that has 82 npm dependencies and over 17,000 resolved npm packages...
It's absolutely ridiculous to investigate all of them... but it's also necessary if you want to be sure...
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. ;-)
0. A dev wants to use a new dependency, likely after experimenting with it a little bit.
1. Preliminary evaluation, which includes a transitive dependency scan. ("Too many dependencies" is a valid fail condition all on it's own.)
2. If everything looks good we bring it and it's deps into our internal repo. This includes the plumbing to add it to our dev|test|production envs. (Using Docker or whatever.)
3. Now the devs can use it in code destined for prod. There's a nice page in the company wiki that lists the exact version(s) with links to the docs, bug trackers, mailing lists, etc. and also the internal company lore for that package.
It's tight.
- - - -
This might seem like a lot of work up front, but think about all the work it saves down the line.
The time-opportunity cost isnt worth it on average
