Mitigate supply chain attacks w/ WASI link-time capabilities + Cargo shenanigans

[shielded-nate]

Problem

Software supply chain attacks, where malicious open source maintainers insert backdoors into common dependencies, are becoming more and more prevalent and dangerous. This is especially clear in the NPM ecosystem, where attacks are growing and ongoing¹. It is likely to affect other ecosystems, such as Rust.

Motivational Related Solution

The LavaMoat dependency management system for JavaScript mitigates these attacks by relying on an object-capabilities approach. It starts by assuming the runtime has actively malicious dependencies, then seeks to attenuate the scope of their malicious behavior by capabilities and attenuation so that well-written applications can prevent many of the worst impacts of malicious dependencies.

Rust Status Quo is Vulnerable

When considering how the Rust ecosystem is vulnerable to software supply chain attacks and pondering how it could attenuate the access malicious dependencies have at runtime, it seems like WASI with its Capabilities model[^3] may be the most feasible and practical target.

From my limited experience in writing WASM hosts and guests in rust, my impression is that rust WASM guests are typically linked by rustc into a single statically linked WASM module, except where the rust programmer explicitly declares and binds extern interfaces that map to WASM module linkage metadata for use by a host.

This means the standard Cargo/rust development path for WASM modules is still vulnerable to supply chain attacks. By contrast, it seems a tweak to a rust build process could leverage WASI-style capabilities to provide fine-grained per-rust-crate capabilities and attenuation. This would likely come at several costs such as runtime overhead and preventing rust from doing static-link-time optimizations, but IMO for any non-performance critical code that cares about security, it may be worth it.

Organizing a Prototype Solution for the Rust Ecosystem

This ticket is a wide-open can of worms simply to draw attention to the potential for a Cargo+rustc 🤝 WASI w/ Capabilities build flow that can mitigate software supply chain attacks.

Brainstorm of next steps:

• Link to discussions or pre-existing knowhow among the WASI subgroup and capabilities-aware devs around supply chain attack mitigation.
• Crosslink to cargo issue tracker; see Supply Chain Attack Mitigation: Add a mode to build and separately link every crate as a WASI-capability-aware WASM module rust-lang/cargo#15782
• Document any other known approaches to supply chain attack mitigation in the rust ecosystem.
• Prototype a change to Cargo and/or rustc which builds every crate as a separate WASI module, then links them with WASI link-time capabilities.
• Raise awareness of the prototype; test that build pipeline against real world rust applications.

Why this Repo?

Although the main effort for this issue theoreticaly belongs over in rust dev toolchain land, I am guessing this community may be more focused and motivated to shepherd this process, or at least be alpha-/beta- testers because of the reliance on WASI and the capabilities buy-in by this dev community.

Footnotes

1. Because X does not share content with the open web, I've provided relevant screenshots below. 🤬

   Screenshot exports of X threads about NPM supply chain attacks:

   https://x.com/zooko/status/1948131551763440104

   

   https://x.com/naugtur/status/1947593007202766980

   

   https://bsky.app/profile/checkmarxzero.bsky.social/post/3luil36jjgr2i

   

   https://bsky.app/profile/jordan.har.band/post/3ludlbnstr22w

   ↩