Amphtml: Clarify processes or guidelines around introducing devDependencies

[cathyxz]

While we have a pretty thorough process around security and license vetting for shipped dependencies, we don't currently hold our dev dependencies to the same standards and also assign Renovate PRs to the build cop (who might not have a whole lot of context on our dependencies) to auto-upgrade all of our dev dependencies.

One idea is that given the history of security incidents related to npm dev dependencies (e.g. event-stream), we should introduce guidelines and processes to either limit dev dependencies where possible, version-lock vetted dev dependencies, or have a re-vetting process for upgrading Renovate PRs. Publishing a custom version of our dependencies under our own amphtml npm namespace is also an idea to guard against left-pad-like issues.

Context:
https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/
https://blog.npmjs.org/post/180565383195/details-about-the-event-stream-incident

/cc @ampproject/wg-infra

[rcebulko]

We've been having a parallel discussion about dependency ownership in the context of owners. Notably, if a package version needs to change, who should be required to give approval? Some thoughts here revolved around looking at what files depend on the package and who owned those files. It mostly addresses the general ownership, not the need for a real security review, but linking here for relevance.

[rcebulko]

Does @ampproject/wg-security-privacy have any opinions/thoughts on this? Renovate PRs frequently update our dev dependencies and are generally approved without intense scrutiny.

[molnarg]

Unfortunately we wouldn't have the capacity to security review each new version of all dependencies. Do we have examples of what other organizations do with this issue?

[rsimha]

What we have in place today is an alerting mechanism at the top of amphtml for any security vulnerabilities in one of our dependencies:

These alerts are typically dealt with via renovate upgrades, or via manual resolutions until an upgrade is available (#25445, #28121).

This isn't a perfect mechanism, but it's likely the best we can do right now. In the absence of any new ideas, I think we should close out this issue.

[molnarg]

Yeah, that's probably the best we can do for now. There are some initiatives that might improve OSS supply chains in the future, worth revisiting later.