sumstrem

The risk with relying on notifications is that it's retroactive and you are already exposed. Instead of attempting to stop threats before they enter your supply chain.

The idea is that the safety delay would protect your organization from automatically (and in many cases unintentionally) updating to a new compromised dependency version, where you are unaware of a problem.

In the case with security fixes and patches, you would be aware that a security issue exists and, if needed, could manually add the security patch either to the same registry or to another registry where you have complete control over the versions allowed.

Hey HN,

In light of this week’s discussion on the corrupted NPM packages colors/fakers ( https://news.ycombinator.com/item?id=29863672 ) the article describes one of our security features that enforces a delay before new versions from upstreams (like npmjs) are allowed in an organization’s private registry.

This puts a safety barrier between your organization and “the latest” versions, allowing you and the open source community time to react when things like this happens.

Most people seem to agree that something needs to be done in regards to how npm dependencies are managed, the problem is finding a solution that people can agree on…

We believe this solution comes with a lot of security benefits, without creating massive barriers that negatively impact developers day-to-day work.