I agree with the author. I still think he makes some invalid points. 1. "Although Non-Production, these are sensitive in of themselves, as they have implementa

I agree with the author. I still think he makes some invalid points. 1. "Although Non-Production, these are sensitive in of themselves, as they have implementation details for our services, and as mentioned, certain things could be used outside of Capital One." Implementation details of your services shouldn't be a part of your security. Otherwise, you are relying on security by obscurity. I agree that you shouldn't necessarily share them publicly (if just for the sake of preventing people from relying on them as a public API), but declaring them as a security breach is far fetched (I'm assuming they are not actually relevant to your security). 2. Many of the points that the author attributes to 3rd party services actually also apply to local tools, if they are downloaded by something like npm. * it's not clear whether the code you are running is identical to the open source version of the code that you think you are running * you have to trust a third party you have no relationship with