I recently got in a friendly debate about how I refuse to import open zeppelin npm packages into my production level solidity code. It is great for speed and such but I have supply chain attack issue concerns, I go on a rant in this tweet.
I personally pull the github folder down and copy it into the repo, moving all files I modify out of it somewhere else. I also periodically delete unused files for faster compilation.
Just wondering what the best practices here would be.
Hi @JesseAbram,
Welcome to the community 
Thanks for kicking off the discussion. I’m interested to hear community views.
Copy paste can lead to users making modifications of the OpenZeppelin Contracts directly rather than extending, with potential to make modifications that are dangerous/unsafe. It could also be a challenge to change to a later release of OpenZeppelin Contracts.
I can understand wanting to have strong control over what you import and potential concerns around npm. Also it is slightly less transparent about what the contracts are.
npm install @openzeppelin/contracts0 voters
This is what kicked off our conversation: https://blog.openzeppelin.com/metal-token-audit-d7e4dbf17bcf/
The advice from the audit suggests no vendoring and prefer npm
Great topic. Andy’s points on maintainability are valid but supply chain attacks do exist. I don’t have strong opinions on the security if developers and auditors are ok with doing thorough reviews of vendored code.
I wonder to which extent is this a protection considering all the other packages/software in your supply chain, e.g. solc compiler.
OpenZeppelin team members are instructed to use strong unique passwords and two-factor auth for both GitHub and npm, which we monitor or enforce when the platform permits. (GitHub can enforce it, npm can’t.)
With vendoring the contracts I’m concerned about the difficulty of verifying that those contracts are not custom-modified. However, installing from npm is also not such a strong guarantee once the contract is verified on Etherscan, because the source code will be inlined there.
Auditors can and should verify that vendored contracts were not modified, but it’s harder for the general public who may also be interested in knowing.
There is also the issue that, as far as I know, audits are performed on the code as found in the repository and not as published, although this is a neutral argument because it affects all approaches the same. I guess what this means is that Etherscan would benefit from a feature that verifies the integrity of contracts from OpenZeppelin Contracts, or even the correspondence with a repository.