cargo-auditable VS rust

Further we use cargo-auditable and cargo-audit as part of both our pipeline and regular scanning of all deployed services. This makes our InfoSec and Legal super happy since it means they can also monitor compliance with licenses and patch/update timings.

This exists, see cargo auditable.

The Rust community seems to have settled on a perfectly reasonable way to address bit-rot in statically linked binaries. https://github.com/rust-secure-code/cargo-auditable

Would you be open to integrating cargo auditable into this pipeline in some form? It seems like a great match.

> and static compilation probably just hides the problem unless security scanners these days can identify statically compiled vulnerable versions of libraries

Some scanners like trivy [1] can scan statically compiled binaries, provided they include dependency version information (I think go does this on its own, for rust there's [2], not sure about other languages).

It also looks into your containers.

The problem is what to do when it finds a vulnerability. In a fat app with dynamic linking you could exchange the offending library, check that this doesn't break anything for your use case, and be on your way. But with static linking you need to compile a new version, or get whoever can build it to compile a new version. Which seems to be a major drawback of discouraging fat apps.

1: https://github.com/aquasecurity/trivy

2: https://github.com/rust-secure-code/cargo-auditable

I have investigated a bunch of standardized formats - SPDX, CycloneDX, etc. All of them are unsuitable for a variety of reasons, chief of which are being way too verbose and including timestamps, which would break reproducible builds.

The fix for interoperability with cargo auditable has also shipped in the latest release of sccache. You can use the released sccache now instead of building it from git!

I've been working to bring vulnerability scanning to Rust binaries by creating cargo auditable, which embeds the list of dependencies and their versions into the compiled binary. This lets you audit the binary you actually run, instead of the Cargo.lock file in some repo somewhere.

cargo auditable solves this problem by embedding the list of dependencies and their versions into the binaries. But until it becomes part of Cargo and gets enabled by default, static linking will remain problematic.

> There are online Rust compilers and interpreters already if you just want to rapid prototype and develop ideas in Rust

You are responding to one of the key developers of Rust early on[1], who's been working with the language for 14 years at that point.

[1] https://github.com/rust-lang/rust/graphs/contributors?from=2... and he's still #16 in commits overall today, despite almost no activity on the rust compiler since 2014.

If you haven't dipped your touch-typing fingers into Rust yet, you really owe it to yourself. Rust is a modern programming language with features that make it suitable not only for systems programming -- its original purpose, but just about any other environment, too; there are frameworks that let your build web services, web applications including user interfaces, software for embedded devices, machine learning solutions, and of course, command-line tools. Since a custom GitHub Action is essentially a command-line tool that interacts with the system through files and environment variables, Rust is perfectly suited for that as well.

Here's an example of someone citing a disagreement between CRT and shell32:

https://github.com/rust-lang/rust/issues/44650

This in addition to the Rust CVE mentioned elsewhere in the thread which was rooted in this issue:

https://blog.rust-lang.org/2024/04/09/cve-2024-24576.html

Here are some quick programs to test contrasting approaches. I don't have examples of inputs where they parse differently on hand right now, but I know they exist. This was also a problem that was frequently discussed internally when I worked at MSFT.

    #include 

> instead of choosing a certain numbered version of the random library (if I remember correctly) I let cargo download the latest version which had a completely different API.

Yeah, they didn't follow the instructions and got burned. I still think that multiple things went wrong simultaneously for that experience. I wonder if more prevalent uses of `#[doc(alias = "name")]` being leveraged by https://github.com/rust-lang/rust/pull/120730 (which now that I check only accounts for methods and not functions, I should get on that!) so that when changing APIs around people at least get a slightly better experience.

Almost fixed the compiler: https://github.com/rust-lang/rust/pull/123325

Rust: A secure, efficient, and modern programming language (omitting ten thousand words). You can simply follow the installation instructions provided on the official website.

Recently did something similar in Rust but for generating SVGs. We've adopted it for snapshot testing of cargo and rustc's output. Don't have a good PR handy for showing Github's rendering of changes in the SVG (text, side-by-side, swiping) but https://github.com/rust-lang/rust/pull/121877/files has newly added SVGs.

To see what is supported, see the screenshot in the docs: https://docs.rs/anstyle-svg/latest/anstyle_svg/

We strongly believe in Rust as a powerful language for building production-grade software, especially for systems like ours that run alongside Kubernetes.