3 ms·
If you auto merge those PRs you're back to square 1 as you're not vetting your dependency updates. And if you don't, you incur operational overhead unless you p
by mmarian 6mo ago
If you auto merge those PRs you're back to square 1 as you're not vetting your dependency updates. And if you don't, you incur operational overhead unless you put in a fair amount of effort centralizing. Wrote a couple of posts that touched on this https://developerwithacat.com/blog/202604/github-actions-supply-chain-commit/ https://developerwithacat.com/blog/202604/github-actions-sup...
- arionmiles 6mo agoValid point. We have minimum age requirements set on some rules to avoid absorbing every latest change instantly.
- mmarian 6mo agoHow would that solve the problem though? You're still bringing compromises in, just with a delay. And the fixes will come in after the compromise, in accordance with the delay policy. To make matters worse, you'd lose getting alerts on vulnerabilities. Dependabot won't send them, and neither will Renovate last time I checked.
- jamietanna 6mo agoBoth Renovate and Dependabot will raise PRs for a security fix, regardless of minimumReleaseAge/cooldown config
- mmarian 6mo agoAre you saying that Dependabot/Renovate... - raises PRs for security fixes immediately, regardless of cooldown configs - flags the PRs as security fixes - does the above when actions are pinned by commit SHA ? If so, mind sharing some documentation and examples please? I don't mind being proven wrong, but I genuinely couldn't find anything that demonstrates this happens. Dependabot docs actually point to the contrary (see my blog posts).
- pabs3 6mo agoHow many people actually audit the code changes in their dependencies when updating them?
- mmarian 6mo agoFew, if any. Which is why I'm highlighting that you can't just use commit SHA + Renovate then call it a day.