Maybe too strict to give a 0 for missing fuzzing tooling for memory safe language

[sbernard31]

Currently when you didn't have any fuzzing tooling available scorecard give you a 0 score.

When reading open ssf best practice, I understand this is only needed for memory unsafe language. (like C or C++)

See passing criteria

It is SUGGESTED that if the software produced by the project includes software written using a memory-unsafe language (e.g., C or C++), then at least one dynamic tool (e.g., a fuzzer or web application scanner) be routinely used in combination with a mechanism to detect memory safety problems such as buffer overwrites. If the project does not produce software written in a memory-unsafe language, choose "not applicable" (N/A). {N/A allowed}

See silver criteria

If the software produced by the project includes software written using a memory-unsafe language (e.g., C or C++), then at least one dynamic tool (e.g., a fuzzer or web application scanner) MUST be routinely used in combination with a mechanism to detect memory safety problems such as buffer overwrites. If the project does not produce software written in a memory-unsafe language, choose "not applicable" (N/A).

So maybe for a memory safe language we should not have a fuzzing tooling score at all. (I guess this means a ? score)

If we want to have a score for fuzzing tooling for memory safe language, the score should not be disadvantageous :

• either this note should be taking into account only if this will increase the total score,
• or this is just a kind of absolute bonus score like +0.5 point.