New check: Include info about the ratio of memory-unsafe to memory-safe code

[noncombatant]

Something like 2/3rds of vulnerabilities in common software are due to memory unsafety. (See e.g. https://alexgaynor.net/2020/may/27/science-on-memory-unsafety-and-security/)

It'd be cool if Scorecard would score dependencies on how much safe/unsafe code they have.

For example, https://github.com/rust-secure-code/cargo-geiger does this for Rust.

[inferno-chromium]

Maybe also need to add [can open a new bug if needed], how much unsafe code is called from memory safe code. E.g. native c extensions from python, JNI from java, unsafe rust, cgo in golang [came from @oliverchang discussion]

[oliverchang]

The current thinking with https://github.com/ossf/package-analysis is that this should be implemented there instead. Perhaps then scorecards can then read from that results of that.

[naveensrinivasan]

The current thinking with https://github.com/ossf/package-analysis is that this should be implemented there instead. Perhaps then scorecards can then read from that results of that.

I concur with that.

[afmarcum]

Is this something that is still important to implement (read from package-analysis)?
If there is no feedback in the next 7 days on whether this remains important for the project, then this issue will be closed.

[noncombatant]

Especially for software that has easy-to-reach attack surface, its arguably the single most important consideration. A scorecard rating for (for example) a web server that doesn't mention that the product is written in C++ would be be eliding a super important fact about the product's security.

So, I'd still like to see this implemented.