search

ossf / scorecard

OpenSSF Scorecard - Security health metrics for Open Source
https://scorecard.dev
Apache License 2.0
4.63k stars 504 forks source link

Test for security policy in other places than SECURITY.md #4192

Open CsatariGergely opened 5 months ago

CsatariGergely commented 5 months ago

Is your feature request related to a problem? Please describe.

There are lots of projects which are describing their security policy in other places, than a SECURITY.md file.

Describe the solution you'd like

Expected content of a security policy should be checked in README.md also.

Describe alternatives you've considered

None

Additional context

None

CsatariGergely commented 5 months ago

What people think about this? Should we try to address it with a pr?

diogoteles08 commented 5 months ago

Hey @CsatariGergely! I think this could be a positive change, as many projects indeed have the content of a security policy directly on their README. But I'm not sure if this would be worth a 10/10, because there is also some value on having a dedicated SECURITY.md, as:

  1. It's usually where security engineers go to look for this content
  2. it's the file GitHub fetches to populate the "Security" tab

That said, I'd be in favor of a PR, but I'd first define a more detailed plan for the resultant scoring.

WDYT, @spencerschrock @raghavkaul

spencerschrock commented 4 months ago

Having a SECURITY.md is a well known convention. If we start parsing the README, my thoughts go to detection mechanisms and false positives.

Do we know how widespread the issue is? And what we'd be looking for in a README?

lelia commented 3 months ago

Having a SECURITY.md is a well known convention. If we start parsing the README, my thoughts go to detection mechanisms and false positives.

I agree with this. The extent to which a README mentions security should ideally be limited to a brief sentence linking to the actual SECURITY.md policy (similar to how CONTRIBUTING.md is treated). GitHub will also autodiscover this file and make the policy available at /orgname/reponame/security/policy for any repository (example) that follows this convention.

That said, I would definitely be in support of an additional check for the presence of SECURITY-INSIGHTS.yml (which was previously discussed in #2305 and #2479, and has more stringent requirements for what a security policy should entail.

github-actions[bot] commented 3 weeks ago

This issue has been marked stale because it has been open for 60 days with no activity.