Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
CsatariGergely opened this issue Jun 24, 2024 · 4 comments
Open

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

CsatariGergely opened this issue Jun 24, 2024 · 4 comments
Labels

Comments

@CsatariGergely
Copy link

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
Copy link
Author

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

@diogoteles08
Copy link
Contributor

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
Copy link
Member

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
Copy link
Contributor

lelia commented Sep 3, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: No status
Development

No branches or pull requests

4 participants