Disappointed there's no mention of vendoring. Anyone with _proper_ security concerns should cargo vendor by default.
Last I looked supply chain attackers don't respect semver and you are all one casual offhand cargo update away from catastrophe.
Last I looked supply chain attackers don't respect semver and you are all one casual offhand cargo update away from catastrophe.
What helps is having provenance information, signing and SBOM. One example. https://sigstore.dev (vendor neutral effort from the Linux Foundation).
> The cargo-outdated tool must be used to check dependencies status. Then, each outdated dependency must be updated or the choice of the version must be justified.
Especially for open source projects, there are also some other arguments against vendoring, see e.g. https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packag...
If there's something that's missing mention, it is imho that the Cargo.lock files should be committed, and also included e.g. in docker builds. (I don't believe in offhanded "cargo update". And even if you did accidentally type it, nothing will be built/executed yet. There's ample opportunity to git restore Cargo.lock.)
> one casual offhand cargo update away from catastrophe
There is a scary amount of libraries who don't even bother specifying patch levels and will auto update everything upon request without question, even worse cargo doesn't make it explicit and as such version "1.0" is equivalent to "1.0.*" in the cargo manifest. Please refer to my previous comment about bad actors not respecting semver as much as many would love them to.
`cargo audit` can be compromised by bad actors. `cargo update` also. If you have a security first application then always vendor, this isn't rust specific.
Sure, "cargo update" will update the dependencies – that's what it's meant to do. The point of Cargo.lock is to ensure that all compilations use the same known set of versions, otherwise it's possible for developers to use one library and the users to use a different one. With Cargo.lock a new version of library won't be used without an explicit "cargo update".
Scoping does not really solve injecting malicious code into the dependency tree in some update. Scoping is more of a defense against typosquatting via new crates.
You can run your own crate registry if you're particularly concerned over what gets published on crates.io.