How Safe is the Rust Ecosystem? A Deep Dive into crates.io

• vulnerability
  • Meaning: A specific security vulnerability (CVE) has been identified in the dependency or in the crate itself.
  • Context: This is the most critical check. It indicates the crate version contains code that could be exploited (e.g., via memory corruption or denial of service). Users typically need to upgrade to a fixed version immediately.
• unsound
  • Meaning: The crate contains “unsound” code.
  • Context: In Rust, “soundness” refers to code that strictly upholds the language’s memory safety guarantees. If a crate is flagged as unsound, it usually means it uses unsafe blocks in a way that could lead to undefined behavior (like segmentation faults) under valid usage, violating Rust’s safety contract.
• notice
  • Meaning: An informational advisory.
  • Context: These are generally low-severity issues or notifications that do not fit into the other categories, such as warnings about future deprecation or minor issues that do not strictly qualify as vulnerabilities.
• unmaintained
  • Meaning: The crate (or the specific version/branch in use) is no longer actively developed or supported.
  • Context: While not an immediate security threat, relying on unmaintained code is a significant risk. If a vulnerability is discovered later, it is unlikely to be patched. This serves as a warning to investigate a replacement or a maintained fork.
• yanked
  • Meaning: The specific version of the crate has been “yanked” (retracted) from the registry by its authors.
  • Context: While yanked versions remain available for existing builds (to avoid breaking Cargo.lock), they cannot be added as new dependencies. Yanks often signal that a version was published by mistake, contains a severe bug, or has been superseded due to a non-critical issue.

Lets start with the general overview of the crates.io distribution based on their popularity (downloads column). In original download-distribution the distance between min-and max is big, so log-distribution is used instead.

As shown by the log-transformed download distribution, there is a spike at the lower end corresponding to packages with very few downloads. These packages are often experimental, inactive, or used by a negligible number of users. Since the goal of this analysis is to study vulnerabilities in packages that have a meaningful impact on the ecosystem, we restrict our focus to relatively more widely used packages and exclude this extreme low-download tail. So crates with less than 50 downloads have been cut, which corresponds to 7% or 14 019.

Based on the distribution and for the future reference, crates would be splitted into popularity groups based on the number of downloads.

The next step would be to analyze safeness and secureness of packages, based only on vulnerability and unsound advisories.

Note: The Failed count represents crates for which vulnerability or unsound failed at least once.

Failure Rate Distribution by Popularity:

Note: Failure rate represents the percentage of crates within a specific group that failed the check.

Average Failure Number by Popularity:

Note: Average failure number represents the mean value of vulnerability and unsound failures per a specific group.

Note: The Failed count represents crates for which vulnerability failed at least once.

Failure rate distribution across established popularity groups.

Note: Failure rate represents the percentage of crates within a specific group that failed the check.

Average failure number across established popularity groups.

Note: Average failure number represents the mean value of vulnerability failures per a specific group.

Note: The Failed count represents crates for which unsound failed at least once.

Failure rate distribution across established popularity groups.

Note: Failure rate represents the percentage of crates within a specific group that failed the check.

Average failure number across established popularity groups.

Note: Average failure number represents the mean value of unsound failures per a specific group.

Note: The Failed count represents crates for which notice failed at least once.

Given the negligible failure rate for this advisory, further detailed investigation is not required.

Note: The Failed count represents crates for which unmaintained or yanked failed at least once.

Failure rate distribution across established popularity groups.

Note: Failure rate represents the percentage of crates within a specific group that failed the check.

Average failure number across established popularity groups.

Note: Average failure number represents the mean value of unmaintained and yanked failures per a specific group.

There is a common belief in software engineering that code “rots”—that if a package hasn’t been touched in years, it eventually becomes a security liability. Is it true based on the collected data?

I wanted to test this hypothesis by looking at Release Recency. Put simply: Is there a correlation between how long a crate has gone without an update and its likelihood of containing vulnerabilities?

Using the date of the latest release (created_at column) as freshness characteristics, let’s see if stale packages really are more dangerous than active ones, based on vulnerability and unsound advisories.

The P-value of 0.0 across all tests confirms that the relationship is statistically significant—the pattern is not due to random chance. However, the correlation coefficients (ranging from 0.14 to 0.19) indicate a weak positive correlation.

Verdict: while older packages are slightly more likely to have issues, inactivity alone is not a strong predictor of insecurity. It is a contributing factor, but certainly not a definitive smoking gun.

There is a common sentiment in software engineering:

“Every line of code is a liability.”

By extension, every additional dependency you add expands your potential attack surface.

I wanted to test this by looking at the Total Dependency Count. Put simply: Does a higher number of dependencies directly increase the probability of a crate having vulnerability flags?

Using the full dependency tree size (all_deps column) as a measure of complexity, let’s see if “heavier” crates are actually more dangerous than lightweight ones, based on vulnerability and unsound advisories.

As in the previous analysis, the P-value of 0.0 across all tests confirms that the relationship is statistically significant—the pattern is not due to random chance.

However, unlike the previous analysis on freshness, the correlation coefficients here (ranging from 0.35 to 0.56) indicate a moderate to strong positive correlation. The Spearman coefficient of 0.56 is particularly notable, suggesting that as dependency ranks increase, risk ranks rise consistently.

Verdict: the data strongly supports the liability hypothesis. Increasing the size of the dependency tree directly and significantly increases the risk of inheriting a vulnerability. Complexity is a much stronger predictor of insecurity than age.