Granularity finer than crates

[vi]

Shall cargo-audit, like cargo-geiger, track which functions are used and which are unused by the target crate and filter out vulnerabilities in unreferenced functions?

Otherwise there will be a stream of vulns in seldom used functions in deep dependencies, which would train users to shovel them away without much consideration, as most of then are not to the point. Or, if there would be little advisory traffic, will "penalize" crates or authors by figurating in a report even though the vulnerability is just in a tiny experimental doc-hidden non-default-feature-cfg function which almost nobody knows about (or be a reason against filing such advisories as insignificant).

[tarcieri]

cargo-audit isn't presently equipped to do a complicated analysis of a project: it just looks at Cargo.lock files.

Perhaps it could in the future, but so far no one has specifically reported being inundated with too many false positive security reports from cargo-audit.

Doing this analysis incorrectly runs the risk of false negatives: failing to report legitimate vulnerabilities because the analysis was incorrect (or the vulnerability metadata was incorrect).

Personally I think a KISS approach makes sense for now until spurious vulnerability reports become a real problem (we only have 8 vulns in the DB as it were).

Happy to leave this issue open for further discussion though.

[vi]

Another idea is ability to include a checker in minor advisories. The checker would scan the code and report the issue conditionally.

[tarcieri]

Another level of granularity to consider is individual cargo features.

That said, I'm not sure how much sense this makes to micro-optimize. The best course of action is to upgrade. Ideally crate authors make that easy.