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.
03/21/2022, 11:23 AM
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.
03/24/2022, 5:32 PM
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.