"CII-Best-Practices" should be turned off by default when forks are analyzed by the scorecard action

[evverx]

This check isn't applicable to forks so I don't think it should trigger alerts in the "security scanning" tab there.

This was discussed in #1074 (comment)

I'd go as far as to say

Regarding "CII-Best-Practices" I think it shouldn't affect the score at all and if it should be promoted for whatever reason it would make sense to make it informational. The problem is that all that check shows is that at some point in the past some projects followed the practices CII considers "best practices" and generally they aren't kept up to date so looking at a badge I can't be sure that whatever it says is up to date. For example, at some point the systemd project used only Coverity Scan and when it was down for almost half a year the badge kept saying a static analysis tool was used. When projects migrate from one hosting service to another they tend to lose a couple of jobs where code is covered with sanitizers for example and their badges don't reflect that. This static nature of the CII badges I think isn't exactly in line with scorecard being able to show the actual state.

[evverx]

With ClusterFuzzLite released though the Fuzzing check can in theory be applicable to forks in the sense that if a workflow where it's used is run on a regular basis it should be safe to say that code is kind of fuzzed. At this point though to pass the check projects have to be fuzzed on OSS-Fuzz and that's applicable to upstream projects only.

[evverx]

I somehow overlooked #1148. Looks like only "CII-Best-Practices" should be turned off

[laurentsimon]

Thanks. Not sure we'll get this done for the first release - will try - otherwise in the next iteration. I think we can add a field in checks.yaml as info to decide dynamically if a check is should be run on a fork.

[evverx]

As far as I understand the idea is to promote that badge for whatever reason so probably if it kept popping up everywhere it would have more exposure. Closing.