'tptacek and I were just discussing this the other day for dependencies (both libraries and vendors). ICs in technical and non-technical roles ask us if a parti

'tptacek and I were just discussing this the other day for dependencies (both libraries and vendors). ICs in technical and non-technical roles ask us if a particular dependency is OK, and we evaluate it. Examples include the privileges a browser extension wants, the OAuth scopes a vendor wants, and the general security posture of a new library. Individual evaluations don't capture risk you get from just having a lot of dependencies. "What happens if this gets compromised" is something we consider individually, but it becomes more actionable when you look at your dependencies globally. Examples: someone loses their Chrome Store credentials, or someone accidentally pushes AWS keys to GitHub, or someone loses their npm creds in an eslint-scope style problem. Now the dependency itself is malicious. If it's a library, that means code execution on your developer laptops, CI systems, and possibly customer devices. Individual dependency requests are not the right place to push back on introducing a dependency. You need a second speed to address those by teaming up with e.g. the VPEng and usually someone in PeopleOps/HR/Sales/Marketing (for things like calendar mgmt, sales tools, ad-hoc CRMs) to periodically pare that list down.