Ya. That's a tough one. Philosophically, I totally support vetting. I don't know we'd make it useful.

Pondering...

One past team had a weekly formal "log bash" ritual. I LOVED it.

That ops team kept track of everything. Any unexplained log entry had to be explained or eliminated. They kept track of explained entries on their end, so we wouldn't waste time rehashing stuff. I imagine their monitoring tools supported filters for squelching noisy explained log entries.

Maybe the security team which owns XRay could do something similar.

But.... We're right though? I mean there is some wiggle room, if some lib has a security hole in some functionality that's not actually being used, but it's all about risk. We gate deploys to prod over something like XRay or LifeCycle and the frustration it causes our devs is much cheaper than deploying something we know is insecure to prod and would cause us to fail an audit or something (let alone get pwned).

There was a recent discussion on HN about `npm audit` and its overwhelming number of false positive vulnerabilities [0]. I can see a policy like this being frustrating in the case of `npm dependencies`. Is this something you deal with?

[0] https://news.ycombinator.com/item?id=27761334