Problem
cargo deny check advisories fails because a dependency is flagged as unmaintained.
Details: atty unmaintained (RUSTSEC-2024-0375). Replace with std::io::IsTerminal (stable since Rust 1.70). Also: potential unaligned read in a transitive dep.
Unmaintained crates receive no security patches, bug fixes, or compatibility updates. They represent a supply chain risk — if a vulnerability is discovered, there is no maintainer to release a fix.
Fix
Replace the unmaintained crate with its recommended successor or a maintained alternative.
Verification
cargo deny check advisories # must show: advisories ok
Five-Whys Root Cause Analysis
Why does cargo deny check fail?
Because the dependency graph contains crates with known vulnerabilities, missing licenses, unmaintained status, or wildcard version specifiers.
Why are these issues present?
Because dependency hygiene was not enforced at commit time — cargo deny ran only in nightly CI as an advisory check, not as a blocking gate.
Why wasn't it a blocking gate?
Because the deny.toml template was deployed without verifying each repo's dependency graph passes. The template was designed for the core sovereign stack (trueno, batuta, forjar, etc.) and deployed uniformly to all 89 Rust repos.
Why wasn't each repo verified?
Because the fleet grew from 25 core repos to 200+ repos organically. Non-core repos (cookbooks, POCs, course material) received CI tooling but not dependency audits.
Why did the fleet grow without audits?
Because there was no supply-chain gate in the PR workflow — the org ruleset enforces CI status checks (gate) but cargo deny was not a required check. The PR authorization gate (Phase 8) blocks unauthorized contributors but not unauthorized dependencies.
Root Cause
Lack of shift-left dependency enforcement. The supply chain security controls (deny.toml, cargo-deny) existed as tooling but were not integrated as blocking CI gates. This matches the empirical finding in Alfadel et al. (arXiv:2203.04520) that 69% of npm vulnerabilities persist because developers lack automated, blocking remediation workflows. Zahan et al. (arXiv:2112.10561) found that >50% of OSS projects have no dependency update policy, leading to systemic vulnerability lag.
References
- Alfadel et al., "Empirical Analysis of Security Vulnerabilities in npm Packages" (arXiv:2203.04520) — 69% of vulnerabilities persist due to lack of automated remediation
- Zahan et al., "Weak Links in the npm Supply Chain" (arXiv:2112.10561) — >50% of projects lack dependency update policies
- Ohm et al., "Backstabber's Knife Collection: A Review of Open Source Supply Chain Attacks" (arXiv:2005.09535) — taxonomy of supply chain attack vectors via abandoned/unmaintained packages
- Lauinger et al., "Thou Shalt Not Depend on Me: Analysing the Use of Outdated JavaScript Libraries on the Web" (arXiv:1811.00918) — quantifies dependency lag and its security implications
Problem
cargo deny check advisoriesfails because a dependency is flagged as unmaintained.Details: atty unmaintained (RUSTSEC-2024-0375). Replace with std::io::IsTerminal (stable since Rust 1.70). Also: potential unaligned read in a transitive dep.
Unmaintained crates receive no security patches, bug fixes, or compatibility updates. They represent a supply chain risk — if a vulnerability is discovered, there is no maintainer to release a fix.
Fix
Replace the unmaintained crate with its recommended successor or a maintained alternative.
Verification
cargo deny check advisories # must show: advisories okFive-Whys Root Cause Analysis
Why does
cargo deny checkfail?Because the dependency graph contains crates with known vulnerabilities, missing licenses, unmaintained status, or wildcard version specifiers.
Why are these issues present?
Because dependency hygiene was not enforced at commit time —
cargo denyran only in nightly CI as an advisory check, not as a blocking gate.Why wasn't it a blocking gate?
Because the deny.toml template was deployed without verifying each repo's dependency graph passes. The template was designed for the core sovereign stack (trueno, batuta, forjar, etc.) and deployed uniformly to all 89 Rust repos.
Why wasn't each repo verified?
Because the fleet grew from 25 core repos to 200+ repos organically. Non-core repos (cookbooks, POCs, course material) received CI tooling but not dependency audits.
Why did the fleet grow without audits?
Because there was no supply-chain gate in the PR workflow — the org ruleset enforces CI status checks (
gate) butcargo denywas not a required check. The PR authorization gate (Phase 8) blocks unauthorized contributors but not unauthorized dependencies.Root Cause
Lack of shift-left dependency enforcement. The supply chain security controls (deny.toml, cargo-deny) existed as tooling but were not integrated as blocking CI gates. This matches the empirical finding in Alfadel et al. (arXiv:2203.04520) that 69% of npm vulnerabilities persist because developers lack automated, blocking remediation workflows. Zahan et al. (arXiv:2112.10561) found that >50% of OSS projects have no dependency update policy, leading to systemic vulnerability lag.
References