RustSec integration

[tarcieri]

Hello from @rustsec! 👋

We have a long standing issue (rustsec/rustsec#21) to use call graph analysis for false positive elimination.

Right now our advisories sometimes contain (unvalidated) information about functions affected by a given vulnerability we could use to "taint" a call graph. This would be particularly useful for transitive dependencies where we can say none of the immediate dependencies ever call an affected function in any of the transitive dependencies.

My immediate question would be what would be the best way to store/query this information so it could be consumed by a tool like cargo-audit? Could the database be made online somehow, either as a service or some sort of flat file format broken down by crates and versions?

[tarcieri]

An immediate integration that might make sense is integrating with our advisory linter to ensure the call graph information is valid, i.e. that the affected functions in the advisory actually exist in the enumerated release(s)

[walterhpearce]

I'd say this is basically the main and first thought beyond the tool! Right now, the big issue is finding a way we can serve queries against the database and pay for that. I see that as three paths that could really be independent.

1. We (The Foundation) are working on the ability to fund the cost of the server to host the graph database and provide an API for querying against it. This is the end goal, so we can just provide the community with some endpoints to investigate the data.
2. Provide a nightly snapshot of the raw neo4j database or some subset consumable dump of the graph.
3. We could create and provide a nightly snapshot of the data specifically tailored for cargo-audit consumption by end users, so we wouldn't need to query the graph specifically; just export the pre-determined information.

You already mentioned option 1, basically, but I'd also like to bring up number 3 as something to discuss - as we are mainly wanting to think "What is the minimal subset of information cargo-audit or RustSec needs?

I think it may also bring up the need for a more unified formation for RustSec advisories to index the function and exploitability path for this.

[tarcieri]

You can view the information we already collect here, although at present it isn't validated: https://github.com/search?q=repo%3Arustsec%2Fadvisory-db%20functions&type=code

It's effectively a UFCS path to the affected functions for a given advisory, where each function is also annotated with a set of SemVer selectors for which releases that function existed (allowing the function to be renamed between releases but still identified as vulnerable)

[jacks0n9]

alright, can we just close this issue. it's been almost a year and i don't think anyone cares about this issue

[tarcieri]

I would still love to use information from painter to at least lint the affected.functions fields in RustSec advisories in our CI process, but perhaps we could make a separate issue(s) for what concrete functionality is needed on the painter side for that sort of thing, i.e. some sort of API (or flat file naming convention) that lets us query call graph information for a particular version of a crate which has been released on crates.io.

[epage]

We (The Foundation) are working on the ability to fund the cost of the server to host the graph database and provide an API for querying against it. This is the end goal, so we can just provide the community with some endpoints to investigate the data.

Why does this require a central database to query rather than running the analysis locally?

[walterhpearce]

@epage this is mainly speaking to the ecosystem wide datasets. For the entire ecosystem, local runs take approximately 36 hours and the storage requirements are prohibitive. As it exists today this can all be done offline independently absolutely.

So as time has been available, we've been working on the following:

1. Migrating away from neo4j and exporting in a generic format for ingestion (capslock) and hosting that data
2. Hosting a graphdb service for some invite-only consumption
3. A separate cargo subcommand for single-project graph generation.

Hope that helps answer.