3 ms·
Ive contracted on a project where another, IMO better, solution was employed. This was ruby. The only allowed package (gem) server was one ran by the project.
by berkes 4y ago
Ive contracted on a project where another, IMO better, solution was employed. This was ruby.
The only allowed package (gem) server was one ran by the project. This package-server scanned, vetted and manually checked any version of a lib before "publishing it".
If you wanted to e.g. upgrade a package, you'd have to do this on this server first. It would then go through some steps, -automatic scanning, risk analysis, sometimes even needing the eyes of someone from a security team. After that the package was published on this server, and you could pull it onto your dev machine and use it in CI/staging/test/prod etc.
Similar steps, to get a new package listed.
IMO this is better, because it stops supply-chain attacks before they hit your code, not after they've (potentially) infected the system.
Edit: for clarity "only allowed package" wasn't enforced very strictly. A linter and CI would catch any changes to code that would want to fetch packages from elsewhere. It wasn't to protect against rogue developers, but against "stupid me, accidentally upgrading to a version that is infected" and such.