3 ms·
You could "just" 1. stand up a private package mirror that you control, that uses a whitelist for what packages it is willing to mirror; 2. configure your pro
by derefr 5y ago
You could "just"
1. stand up a private package mirror that you control, that uses a whitelist for what packages it is willing to mirror;
2. configure your project's dependency-fetching logic to fetch from said mirror;
3. configure CI to only allow outbound network access to your package mirror's IP.
The disadvantage — but also the point — of this, is that it is then a release manager's responsibility, not a developer's responsibility, to give the final say-so for adding a dependency to the project (because only the release manager has the permissions to add packages to the mirror.)
- NAHWheatCracker 5y agoThat's an interesting approach. I'm not keen on the bureaucratic aspect, which leads to more friction than it's worth in my experience. I guess that's beside the point if your goal is only to reduce risk of compromised CI/CD.
- mulmen 5y agoYou can compromise and give the developers the ability to add dependencies as well. In a separate “dependency mirror” package. But those have to be code reviewed like anything else. So you have a paper trail but adding a dependency is lower friction. And you still can’t accidentally (or maliciously!) pull in an evil dependency without at least two people involved.