Same place where we've always been, and where we're ultimately going to be with any dependency management solution, automated or manual: risk assessment.
Any time we depend on third party dependencies we're making a choice to trust the vendors of said dependencies (and by extension anyone they trust, and also anyone who might have access to the "pipeline" in between us and those vendors). Whether the benefit is greater than the risk is what matters.
(Sorry for going a bit philosophical with this ?)
As for Composer vs. npm, my opinion is that the situation with Composer is slightly less problematic, simply due to the ecosystem. I don't have numbers to back this, so please take it with a grain of salt, but in my experience relying on numerous interconnected dependencies is more common for npm projects. ProcessWire modules, for an example, tend to have relatively few dependencies, which can be a good thing (in this particular context).
One solution, mentioned in that Reddit discussion as well, is roave/security-advisories. I would recommend adding it to your setups, just in case. It's a super simple package that defines a list of "conflicts", each of those being a package + version with known vulnerabilities. When running composer install or composer update, these conflicts crash the process. This may well be the only "positive use case" for conflicts I've come across ?
It's not a fool proof solution, but a good start — and pretty much a no-brainer, in my opinion.
Another thing that can help is private packagist, which provides automated security audits, alerts, and more. Private packagist is not free, but for commercial users it's definitely something to consider (and not just for the security features).