BUG: Security policy is not detected in GitHub repository

[sgammon]

Describe the bug
According to the documentation for the Security-Policy check, it "works by looking for a file named SECURITY.md [...] in a few well-known directories." GitHub's documentation is linked in the remediation steps, and the docs specifically mention that a SECURITY.md file at the root of a repo should be detected.

However, in this repo, there is a root SECURITY.md, and the Scorecard action does not detect it:

0: Security-Policy

Reason
security policy file not detected

Details
Warn: no security policy file detected
Warn: no security file to analyze
Warn: no security file to analyze
Warn: no security file to analyze

Reproduction steps
I am not sure.

Expected behavior
I expected the security policy to be detected.

[spencerschrock]

This is unfortunately a known and tricky edge case with how Scorecard looks at files in a repository using the archive tarball. You have your SECURITY.md export ignored

I'm going to close this in favor of the existing issue, but this is the second or third time to come up this week:
#2489 (comment)

As a short term "fix", you can always have a local copy of the repo and pass it with --local=<path> to do some analysis on the repository, but I understand this doesn't fix it for the action. Long term we may want a compatibility mode which does a clone with go-git. We don't do that by default currently because of speed concerns.

[sgammon]

@spencerschrock Can I ask why Scorecard uses the export tarball? Those paths are ignored in that repo because the exported tarball is used to publish to Bazel Central Registry. Is there a way we can suppress checks that aren't compatible because of how Scorecard is implemented?

As it stands, this bug results in a lower score.

[sgammon]

(I realize speed is a consideration, but I suppose I am asking about this balance with correctness, since in this case, the score is enforced with a strictness that should grant it trust, but instead, it is not accurate, so it is losing trust, and I cannot suppress it to make it accurate.)

Our tarball has semantic meaning. So I can add those files back, but it will add them in turn to our release to BCR and for every downloader of the package using tarballs from Bazel.

[spencerschrock]

Can I ask why Scorecard uses the export tarball
I realize speed is a consideration

It was mainly a speed reason, and that the majority of repositories don't use .gitattributes so it's not usually a problem.

but I suppose I am asking about this balance with correctness

I think a git compatibility mode would solve this for those who want correctness over speed.