Hi everyone! Ok, talking about supply-chain security we’re usually talking about external forces injection malicious code. In this case we have a maintainer who decided his protest would hit the right people if he deletes data on Russian and Belarusian servers. Is there any tool or process, other than a direct code review of any version upgrade (not really feasible) that would have prevented data loss here, i.e. stopped the update before it can cause harm? https://www.bleepingcomputer.com/news/security/big-sabotage-famous-npm-package-deletes-files-to-protest-ukraine-war/

that's an interesting question. things like sonatype nxrm/iq, jfrog, etc. would flag "known vulns" but a legit repo's code owner making changes wouldn't be detected until flagged. eventually it could be noticed and certain versions marked malicious, but that's not preventing harm...it would seem to need some sort of heuristic/behavioral type approach in a local repo/scanning-type tool e.g. not just comparing to author reputation, repo metadata or known vuln DB but "X percent of code changed" or "changed in X way which has malicious POSSIBILITY (local file overwrite)" etc. to be useful in these cases before analysis.

Yeah, it’s not really feasible to have a sandbox for every dependency change. In the meantime I’ve read that snyk.io has a normal delay of 3 weeks before they recommend an update. That seems to be a good enough time frame to collect feedback.

A caching proxy with a long refresh period as a buffer. The unfortunate reality of a lot of package scanners is that they compare yours to known-vulnerable packages. The only safety in a model where there has to be a failure first, is try not to be the first one.