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

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)?

Start by reviewing Cargo.toml and the repository's CI configuration, focusing on how dependency updates and automated pull-request builds are handled. Compare the proposed seven-day delay for third-party dependencies with exemptions for cranelift and rustc-related updates. Done would require an agreed policy and a clearly specified implementation scope, which this discussion does not yet define.