How does it do either of these two things, exactly?
> and locked down
It doesn't lock anything down, in fact it only serves a purpose if your CI isn't locked down. Your npm token should not be visible to anything except npm. If it is, then you've got far bigger problems.
At best, this only serves as a reactionary warning / damage control in case your CI is compromised, i.e. after you've already been pwned. Which is all well and good, don't get me wrong, but pretending it "protects" you from anything is giving a false sense of security.
Fair points — this isn’t a preventative control and it doesn’t “lock down” your CI. If an attacker has your NPM token, you’ve already been pwned.
The goal is to stop the spread. This will quickly unpublish a library and alert you, so no one else is downloading the compomised package, like what happened with posthog.
> keeps your release process clean, reproducible
How does it do either of these two things, exactly?
> and locked down
It doesn't lock anything down, in fact it only serves a purpose if your CI isn't locked down. Your npm token should not be visible to anything except npm. If it is, then you've got far bigger problems.
At best, this only serves as a reactionary warning / damage control in case your CI is compromised, i.e. after you've already been pwned. Which is all well and good, don't get me wrong, but pretending it "protects" you from anything is giving a false sense of security.
Fair points — this isn’t a preventative control and it doesn’t “lock down” your CI. If an attacker has your NPM token, you’ve already been pwned.
The goal is to stop the spread. This will quickly unpublish a library and alert you, so no one else is downloading the compomised package, like what happened with posthog.