Discussion: Mitigating supply chain & CI attacks via delayed dependency updates

[0xmuon]

Supply chain attacks (like those recently seen in npm) and AI-assisted CI cache poisoning are escalating. In Rust, a compromised "day-zero" dependency could execute malicious build.rs scripts or proc-macros during an automated PR build to poison shared CI caches or exfiltrate runner tokens.

To be proactive, a deliberate "cool-down" period(like 7 days) before bumping dependency versions in Cargo.toml. Waiting a week gives the wider community and automated security scanners time to detect and yank compromised packages. This keeps cg_clif and our CI infra out of the immediate blast radius.

Doubt:

How would a 1 week delay impact the workflow for pulling in crucial cranelift fixes or keeping up with rustc API changes? Would it make sense to apply this 7 day rule strictly to third-party transitive dependencies, while exempting high-trust core dependencies (like cranelift itself)?

[bjorn3]

I already rarely update dependencies other than Cranelift. And for Cranelift I do actually want to update as soon as possible to catch regressions. In fact I often already push an update branch when a new release branch has been made, but before the two weeks during which the new release is effectively in beta.

cg_clif intentionally does not depend on any proc macros, though a bunch of dependencies do have a build.rs.

[0xmuon]

Agreed!! It's great that proc-macros are entirely out of the picture. Since you mentioned build.rs is still present in some dependencies, would you be open to me looking into sandboxing those build scripts or setting up a minimal cargo-vet config just for those specific crates? Since you rarely update them anyway, the maintenance overhead would be near zero,but it would lock down that final attack vector.