docs: add security guidelines and SECURITY.md template#7
docs: add security guidelines and SECURITY.md template#7morri-son wants to merge 5 commits intoneonephos:mainfrom
Conversation
- Replace cryptic version placeholder table in SECURITY.md template with flexible options (single branch vs. multiple releases) - Clarify SLA targets are calendar days, add transparency-over-speed guidance - Add practical notes to security-guidelines.md: incremental supply chain adoption, CVE deferral for early-stage projects, communication over deadlines - Mark Past Security Advisories section as optional for new projects
Change resolution for artifact signing, SLSA provenance, and SBOM from 'By next minor release' to 'When publishing artifacts to external consumers' — avoids artificial pressure on early-stage projects that do not yet distribute artifacts externally.
|
|
||
| Projects **MUST** provide a `SECURITY.md` file in every repository that contains publishable code or artifacts. The `SECURITY.md` **MUST** include at minimum: | ||
|
|
||
| 1. A link to the repository's GitHub Private Vulnerability Reporting page. |
There was a problem hiding this comment.
Having a link is sometimes more difficult, its nice if organizations can just have a single SECURITY.md file in the .github repo makes is hard to link to the repo specific Vulnerability Reporting page. Therefore we've described how to report a vulnerability without providing a clickable link
There was a problem hiding this comment.
changed the wording. Pls check
| Projects **MUST** provide a `SECURITY.md` file in every repository that contains publishable code or artifacts. The `SECURITY.md` **MUST** include at minimum: | ||
|
|
||
| 1. A link to the repository's GitHub Private Vulnerability Reporting page. | ||
| 2. Supported versions: which release branches receive security updates. |
There was a problem hiding this comment.
This is also more a general policy (e.g. the last 2 minor versions) rather than concretely naming branches correct?
|
Should we also move the Operational Security aspects from here: https://github.com/neonephos/guidelines-development/blob/main/project-guidelines/project-guidelines.md#153-security-and-compliance into this document? |
|
I think it would be a lot easier to just adopt using the OpenSSF Scorecard, which will do checks to align with best practices. |
I created a section |
…SSF Scorecard, and template improvements - Relax SECURITY.md link requirement to support org-level .github repos (nexus49) - Clarify supported versions as a version support policy, not branch names (nexus49) - Add §10 Operational Security Controls reworked from Project Guidelines §15.3: authentication, CI/CD security, access governance, code scanning, data retention - Frame maintainer vetting criteria as supply-chain trust controls (§10.3) - Add §10.6 OpenSSF Scorecard recommendation (jmertic) - Update scope, introduction, and TOC; renumber Acknowledgements to §11 - Add org-level SECURITY.md guidance note to template
I copied the content over from §15.3 and reworked with conformance tables, cross-references to §8, and proper MUST/SHOULD language |
|
@morri-son Good question. Generally we see projects adopt the OpenSSF Best Practices Badge ( https://www.bestpractices.dev/ ) and map to the various tiers ( for example, Passing Badge for Incubation, Gold for Graduated ). The Scorecard could be then a tool to manage ongoing alignment, just in the same way LFX Insights is used for measuring contributions. Let me know your thoughts... |
| |----------|-----------------|-------| | ||
| | **MUST** | ASAP (≤30 days) | TSC | | ||
|
|
||
| Projects **MUST** enable [GitHub Private Vulnerability Reporting](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability) on all repositories that contain publishable code or artifacts. This is the primary channel for receiving vulnerability reports. |
There was a problem hiding this comment.
We should also consider the possibility that projects are not on GitHub. For those, this can't be a MUST.
There was a problem hiding this comment.
You're right. I changed the section 5.1 and make it generic and placed git platform specific solutions below. Since the GH way was refered to in other section, too, I needed to also update those. Pls check the commit to see the diffs.
I added https://github.com/neonephos/guidelines-development/pull/7/changes#diff-1c57ac02b0e896c0a58ee0a4467770159c4a4c5b0e2c6c0e7b2ad989c4d73cd0R353-R364. Pls check if this fits your idea. |
Restructure Section 5.1 from GitHub-only "Private Vulnerability Reporting" to platform-agnostic "Private Vulnerability Intake Channel" with subsections for GitHub, GitLab, and other/self-hosted platforms. Update all downstream references in Sections 6, 7, 9, and 11 that previously hard-coded GitHub Security Advisories to use platform-agnostic language with platform-specific guidance blocks. Update SECURITY.md template with reporting options for GitHub (Private Vulnerability Reporting), GitLab (confidential issues), and email/ security.txt fallback. Addresses review feedback from fmui noting that not all projects may be hosted on GitHub (PR neonephos#7, comment r3064032552). Signed-off-by: Gerald Morrison <gerald.gm.morrison@gmail.com>
|
Hi @morri-son I still think we are just restating things already covered in existing materials. Take a look at the TAC site in progress ( https://special-couscous-6qv9rv3.pages.github.io/best_practices/repo.html ) and let me know your thoughts. |
4 participants
Initial proposal for security guidelines and SECURITY.md template to be used in every repository.