From dd7f43460ea75409548d6d7c68c6692ce0ad7f81 Mon Sep 17 00:00:00 2001 From: Gerald Morrison Date: Tue, 7 Apr 2026 14:51:57 +0200 Subject: [PATCH 01/14] docs: add security guidelines and SECURITY.md template --- security-guidelines/security-guidelines.md | 258 ++++++++++++++++++++- templates/SECURITY.md | 86 +++++++ 2 files changed, 343 insertions(+), 1 deletion(-) create mode 100644 templates/SECURITY.md diff --git a/security-guidelines/security-guidelines.md b/security-guidelines/security-guidelines.md index ed303e2..abf9e27 100644 --- a/security-guidelines/security-guidelines.md +++ b/security-guidelines/security-guidelines.md @@ -1 +1,257 @@ -# NeoNephos Security Guidelines \ No newline at end of file +# Security Guidelines — NeoNephos Foundation + + +* [Security Guidelines — NeoNephos Foundation](#security-guidelines--neonephos-foundation) + * [1. Introduction](#1-introduction) + * [2. Normative Language](#2-normative-language) + * [3. Conformance Model](#3-conformance-model) + * [4. Scope](#4-scope) + * [5. Security Contact per Project](#5-security-contact-per-project) + * [5.1 GitHub Private Vulnerability Reporting](#51-github-private-vulnerability-reporting) + * [5.2 SECURITY.md](#52-securitymd) + * [6. Vulnerability Response Process](#6-vulnerability-response-process) + * [6.1 Acknowledgement](#61-acknowledgement) + * [6.2 Triage and Severity Assessment](#62-triage-and-severity-assessment) + * [6.3 Fix Coordination](#63-fix-coordination) + * [6.4 CVE Assignment](#64-cve-assignment) + * [6.5 Coordinated Disclosure](#65-coordinated-disclosure) + * [6.6 Post-Disclosure](#66-post-disclosure) + * [7. Severity Classification and Response SLAs](#7-severity-classification-and-response-slas) + * [8. Supply Chain Security](#8-supply-chain-security) + * [8.1 Artifact Signing](#81-artifact-signing) + * [8.2 Build Provenance (SLSA)](#82-build-provenance-slsa) + * [8.3 Software Bill of Materials (SBOM)](#83-software-bill-of-materials-sbom) + * [8.4 Dependency Scanning](#84-dependency-scanning) + * [9. Security Transparency](#9-security-transparency) + * [10. Acknowledgements](#10-acknowledgements) + + +## 1. Introduction + +This document defines the security guidelines for projects governed by the **NeoNephos Foundation**. It establishes requirements for vulnerability disclosure, incident response, and supply chain security that all NeoNephos projects must follow. + +These guidelines complement the [NeoNephos Project Guidelines](../project-guidelines/project-guidelines.md), which reference this document in [Section 11 — Security](../project-guidelines/project-guidelines.md#11-security). Infrastructure-level security controls (2FA enforcement, GitHub Actions permissions, runner policies, and data retention) are defined in [Section 15.3 — Security and Compliance](../project-guidelines/project-guidelines.md#153-security-and-compliance) of the Project Guidelines and are not repeated here. + +Related sections: [2 — Normative Language](#2-normative-language); [3 — Conformance Model](#3-conformance-model); [4 — Scope](#4-scope). + +--- + +## 2. Normative Language + +The key words **MUST**, **MUST NOT**, **REQUIRED**, **SHALL**, **SHALL NOT**, **SHOULD**, **SHOULD NOT**, **RECOMMENDED**, **MAY**, and **OPTIONAL** in this document are to be interpreted as described in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119.html) and [RFC 8174](https://www.rfc-editor.org/rfc/rfc8174.html). + +Related sections: [3 — Conformance Model](#3-conformance-model). + +--- + +## 3. Conformance Model + +This document follows the same conformance model defined in the [NeoNephos Project Guidelines, Section 3](../project-guidelines/project-guidelines.md#3-conformance-model). Each guideline carries a *conformance priority statement* and a *resolution timeframe*. Enforcement follows the process described in [Section 13a — Enforcement and Remediation](../project-guidelines/project-guidelines.md#13a-enforcement-and-remediation) of the Project Guidelines. + +--- + +## 4. Scope + +This document covers: + +- **Vulnerability disclosure and response**: How projects receive, handle, and disclose security vulnerabilities. +- **Supply chain security**: Requirements for signing, provenance, SBOMs, and dependency management of released artifacts. + +This document does **not** cover: + +- Infrastructure security controls (2FA, GitHub Actions, runners) — see [Project Guidelines §15.3](../project-guidelines/project-guidelines.md#153-security-and-compliance). +- OpenSSF Best Practices Badge requirements — see [Project Lifecycle Policy](../lifecycle-policy/project-lifecycle-policy.md). +- Governance, maintainer access, and operational policies — see [Project Guidelines](../project-guidelines/project-guidelines.md). + +--- + +## 5. Security Contact per Project + +### 5.1 GitHub Private Vulnerability Reporting + +| Priority | Resolution | Owner | +|----------|-----------------|-------| +| **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. + +Projects **SHOULD** enable Private Vulnerability Reporting at the organization level to ensure newly created repositories inherit this setting. + +### 5.2 SECURITY.md + +| Priority | Resolution | Owner | +|----------|-----------------|-------| +| **MUST** | ASAP (≤30 days) | TSC | + +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. +3. The expected response timeline (referencing [Section 6](#6-vulnerability-response-process) of this document). + +Projects **SHOULD** additionally provide an email address or alternative private channel for reporters who cannot use GitHub. + +A template is available at [`../templates/SECURITY.md`](../templates/SECURITY.md). + +Related sections: [6 — Vulnerability Response Process](#6-vulnerability-response-process); [7 — Severity Classification and Response SLAs](#7-severity-classification-and-response-slas). + +--- + +## 6. Vulnerability Response Process + +| Priority | Resolution | Owner | +|----------|-----------------|-------| +| **MUST** | ASAP (≤30 days) | TSC | + +Each project's TSC **MUST** designate at least two maintainers as security contacts responsible for handling vulnerability reports. These contacts **MUST** be documented in the project's `SECURITY.md`. + +### 6.1 Acknowledgement + +Projects **MUST** acknowledge receipt of a vulnerability report within **3 business days**. The acknowledgement **MUST** be sent via the same channel the report was received on (e.g., GitHub Security Advisory). + +### 6.2 Triage and Severity Assessment + +Projects **MUST** perform an initial triage within **7 calendar days** of receiving a report. Triage **MUST** include: + +1. Validation: confirming whether the report describes a genuine vulnerability. +2. Severity assessment using [CVSS v3.1](https://www.first.org/cvss/v3.1/specification-document) or later. +3. Assignment of a severity level per [Section 7](#7-severity-classification-and-response-slas). + +The reporter **SHOULD** be informed of the triage outcome and the planned remediation timeline. + +### 6.3 Fix Coordination + +Fix development **SHOULD** happen in a private fork or draft advisory within GitHub to prevent premature disclosure. The fix **MUST** be reviewed by at least one additional maintainer before merging. + +If the vulnerability affects multiple NeoNephos projects, the reporting project's TSC **SHOULD** coordinate with the affected projects' TSCs before disclosure. The TAC **MAY** facilitate cross-project coordination. + +### 6.4 CVE Assignment + +| Priority | Resolution | Owner | +|------------|-----------------|-------| +| **SHOULD** | ASAP (≤30 days) | TSC | + +Projects **SHOULD** request a CVE identifier for confirmed vulnerabilities with a CVSS score ≥ 4.0 (Medium or higher). CVE identifiers **SHOULD** be obtained via [GitHub's CNA program](https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/publishing-a-repository-security-advisory#requesting-a-cve-identification-number). + +### 6.5 Coordinated Disclosure + +| Priority | Resolution | Owner | +|----------|-----------------|-------| +| **MUST** | ASAP (≤30 days) | TSC | + +Projects **MUST** follow a coordinated disclosure process: + +1. **Embargo period**: The maximum embargo duration is **90 calendar days** from the date the report is acknowledged. During this period, details of the vulnerability **MUST NOT** be disclosed publicly. +2. **Disclosure**: Once a fix is available (or the embargo expires), the project **MUST** publish a [GitHub Security Advisory](https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/publishing-a-repository-security-advisory) containing: + - A description of the vulnerability. + - Affected versions. + - The CVSS score and vector. + - The CVE identifier (if assigned). + - Remediation steps or patched versions. +3. **Early disclosure**: If active exploitation is detected in the wild, the TSC **MAY** shorten the embargo period and disclose early with whatever fix or mitigation is available. + +### 6.6 Post-Disclosure + +After public disclosure: + +- The fix **MUST** be released in a patch version for all supported release branches. +- The CVE and advisory **SHOULD** be referenced in the release notes of the patched version. +- Projects **SHOULD** conduct a retrospective for Critical and High severity vulnerabilities to identify process improvements. + +Related sections: [5 — Security Contact per Project](#5-security-contact-per-project); [7 — Severity Classification and Response SLAs](#7-severity-classification-and-response-slas); [9 — Security Transparency](#9-security-transparency). + +--- + +## 7. Severity Classification and Response SLAs + +| Priority | Resolution | Owner | +|----------|-----------------|-------| +| **MUST** | ASAP (≤30 days) | TSC | + +Projects **MUST** classify vulnerabilities using [CVSS v3.1](https://www.first.org/cvss/v3.1/specification-document) or later and apply the following response SLAs: + +| Severity | CVSS Score | Fix SLA | Disclosure SLA | +|--------------|------------|------------------------|------------------------| +| **Critical** | 9.0 – 10.0 | ≤ 7 calendar days | ≤ 14 calendar days | +| **High** | 7.0 – 8.9 | ≤ 30 calendar days | ≤ 30 calendar days | +| **Medium** | 4.0 – 6.9 | ≤ 90 calendar days | ≤ 90 calendar days | +| **Low** | 0.1 – 3.9 | Best effort | Best effort | + +- **Fix SLA**: Time from triage completion to a fix being merged. +- **Disclosure SLA**: Time from triage completion to publishing a GitHub Security Advisory. The disclosure SLA **MUST NOT** exceed the 90-day embargo defined in [Section 6.5](#65-coordinated-disclosure). + +If a project cannot meet a Fix SLA, the TSC **MUST** communicate an updated timeline to the reporter and publish a mitigation or workaround advisory. + +Related sections: [6 — Vulnerability Response Process](#6-vulnerability-response-process); [6.5 — Coordinated Disclosure](#65-coordinated-disclosure). + +--- + +## 8. Supply Chain Security + +### 8.1 Artifact Signing + +| Priority | Resolution | Owner | +|------------|-----------------------|-------| +| **SHOULD** | By next minor release | TSC | + +Projects **SHOULD** sign all published release artifacts (container images, binaries, packages) using [Sigstore cosign](https://docs.sigstore.dev/cosign/signing/overview/) or an equivalent signing mechanism. Signing **SHOULD** be integrated into the CI/CD pipeline. + +### 8.2 Build Provenance (SLSA) + +| Priority | Resolution | Owner | +|------------|-----------------------|-------| +| **SHOULD** | By next minor release | TSC | + +Projects **SHOULD** generate [SLSA](https://slsa.dev/) provenance attestations for published artifacts. The target level is at minimum [SLSA Build Level 2](https://slsa.dev/spec/v1.0/levels) (scripted build, hosted build platform). + +Projects **MAY** use the [SLSA GitHub Generator](https://github.com/slsa-framework/slsa-github-generator) or equivalent tooling to generate and publish provenance attestations. + +### 8.3 Software Bill of Materials (SBOM) + +| Priority | Resolution | Owner | +|------------|-----------------------|-------| +| **SHOULD** | By next minor release | TSC | + +Projects **SHOULD** generate a Software Bill of Materials (SBOM) for each published release artifact. SBOMs **MUST** use either [SPDX](https://spdx.dev/) or [CycloneDX](https://cyclonedx.org/) format. + +SBOMs **SHOULD** be published alongside release artifacts (e.g., attached to GitHub releases or pushed to the OCI registry as a referrer). + +### 8.4 Dependency Scanning + +| Priority | Resolution | Owner | +|----------|-----------------|-------| +| **MUST** | ASAP (≤30 days) | TSC | + +Projects **MUST** enable automated dependency scanning to detect known vulnerabilities in direct and transitive dependencies for all repositories containing publishable code. Examples of acceptable tools include [Dependabot](https://docs.github.com/en/code-security/dependabot), [Renovate](https://docs.renovatebot.com/), or equivalent. + +Projects **SHOULD** configure automated dependency update pull requests to reduce time-to-remediation. + +Related sections: [Project Guidelines §15.3.2 — Supplemental Compliance](../project-guidelines/project-guidelines.md#1532-supplemental-compliance); [Project Guidelines §6 — Technical and Development Practices](../project-guidelines/project-guidelines.md#6-technical-and-development-practices). + +--- + +## 9. Security Transparency + +| Priority | Resolution | Owner | +|----------|-----------------|-------| +| **MUST** | ASAP (≤30 days) | TSC | + +Projects **MUST** publish security advisories for all confirmed vulnerabilities with a CVSS score ≥ 4.0 via [GitHub Security Advisories](https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/about-repository-security-advisories). + +Projects **MUST** reference CVE identifiers and advisory links in the release notes of patched versions. + +Projects **SHOULD** maintain a public record of past security advisories accessible from the project's `SECURITY.md`. + +Related sections: [6.6 — Post-Disclosure](#66-post-disclosure); [5.2 — SECURITY.md](#52-securitymd). + +--- + +## 10. Acknowledgements + +| Priority | Resolution | Owner | +|------------|-----------------|-------| +| **SHOULD** | ASAP (≤30 days) | TSC | + +Projects **SHOULD** credit security researchers who responsibly report vulnerabilities, unless the reporter requests anonymity. Acknowledgement **SHOULD** be included in the published GitHub Security Advisory and **MAY** also be included in release notes. + +Related sections: [6.5 — Coordinated Disclosure](#65-coordinated-disclosure); [9 — Security Transparency](#9-security-transparency). diff --git a/templates/SECURITY.md b/templates/SECURITY.md new file mode 100644 index 0000000..74ae56c --- /dev/null +++ b/templates/SECURITY.md @@ -0,0 +1,86 @@ +# Security Policy (Template) + +*This is a template for a SECURITY.md file. Adjust the placeholders (marked with `<...>`) to match +your project. Remove this italic guidance text before publishing. For projects with multiple +repositories, each repository containing publishable code or artifacts MUST have its own SECURITY.md. +See the [NeoNephos Security Guidelines](../security-guidelines/security-guidelines.md) for the full +set of requirements.* + +## Reporting a Vulnerability + +If you discover a security vulnerability in **\**, please report it responsibly +through one of the channels below. **Do not open a public issue for security vulnerabilities.** + +### GitHub Private Vulnerability Reporting (Preferred) + +Please use GitHub's built-in private vulnerability reporting: + +1. Navigate to the **Security** tab of this repository. +2. Click **Report a vulnerability**. +3. Fill in the details and submit. + +Direct link: [Report a vulnerability](https://github.com///security/advisories/new) + +*For more information, see [Privately reporting a security vulnerability](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability).* + +### Alternative Contact + +*If your project offers an alternative private reporting channel (e.g., email), list it here. +Otherwise, remove this section.* + +You may also report vulnerabilities via email to **\**. + +## Security Contacts + +The following maintainers are responsible for handling vulnerability reports: + +| Name | GitHub Handle | Role | +|------|---------------|------| +| *\* | [@\](https://github.com/) | Security Officer | +| *\* | [@\](https://github.com/) | Maintainer | + +## Supported Versions + +*List which versions of your project currently receive security updates. Adjust the table to match +your release branches.* + +| Version | Supported | +|---------|-----------| +| \ (latest) | Yes | +| \ | Yes | +| < \ | No | + +## Response Process + +This project follows the [NeoNephos Security Guidelines](../security-guidelines/security-guidelines.md) for vulnerability handling. In summary: + +- **Acknowledgement**: We will acknowledge your report within **3 business days**. +- **Triage**: We will assess the severity (using [CVSS v3.1](https://www.first.org/cvss/v3.1/specification-document)) within **7 calendar days**. +- **Embargo**: Vulnerability details will remain confidential for up to **90 days** while a fix is developed. +- **Disclosure**: Once a fix is available, we will publish a [GitHub Security Advisory](https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/about-repository-security-advisories) with full details. + +### Severity Response SLAs + +| Severity | CVSS Score | Fix Target | +|----------|------------|------------| +| Critical | 9.0 – 10.0 | ≤ 7 days | +| High | 7.0 – 8.9 | ≤ 30 days | +| Medium | 4.0 – 6.9 | ≤ 90 days | +| Low | 0.1 – 3.9 | Best effort | + +## Disclosure Policy + +We follow [coordinated disclosure](https://en.wikipedia.org/wiki/Coordinated_vulnerability_disclosure). We ask that you: + +- Allow us reasonable time to investigate and address the vulnerability before public disclosure. +- Do not exploit the vulnerability beyond what is necessary to demonstrate the issue. +- Do not access or modify data belonging to other users. + +We are committed to crediting reporters in our security advisories unless you prefer to remain anonymous. + +## Past Security Advisories + +*Link to your project's published GitHub Security Advisories. Remove this section if no advisories +have been published yet.* + +See [Published Security Advisories](https://github.com///security/advisories?state=published). From d57efb1fcbee555a13be3bdd3ef46b2400945837 Mon Sep 17 00:00:00 2001 From: Gerald Morrison Date: Tue, 7 Apr 2026 15:03:08 +0200 Subject: [PATCH 02/14] =?UTF-8?q?docs:=20improve=20practicality=20of=20sec?= =?UTF-8?q?urity=20docs=20=E2=80=94=20make=20guidelines=20livable?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - 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 --- security-guidelines/security-guidelines.md | 6 +++- templates/SECURITY.md | 32 ++++++++++++++-------- 2 files changed, 26 insertions(+), 12 deletions(-) diff --git a/security-guidelines/security-guidelines.md b/security-guidelines/security-guidelines.md index abf9e27..803abbb 100644 --- a/security-guidelines/security-guidelines.md +++ b/security-guidelines/security-guidelines.md @@ -133,6 +133,8 @@ If the vulnerability affects multiple NeoNephos projects, the reporting project' Projects **SHOULD** request a CVE identifier for confirmed vulnerabilities with a CVSS score ≥ 4.0 (Medium or higher). CVE identifiers **SHOULD** be obtained via [GitHub's CNA program](https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/publishing-a-repository-security-advisory#requesting-a-cve-identification-number). +> **Practical note:** CVE assignment adds credibility and traceability but involves administrative overhead. Early-stage projects or projects with a small user base **MAY** defer CVE assignment until a stable release has been published and external adoption is established. The GitHub Security Advisory alone already provides adequate transparency for most cases. + ### 6.5 Coordinated Disclosure | Priority | Resolution | Owner | @@ -180,7 +182,7 @@ Projects **MUST** classify vulnerabilities using [CVSS v3.1](https://www.first.o - **Fix SLA**: Time from triage completion to a fix being merged. - **Disclosure SLA**: Time from triage completion to publishing a GitHub Security Advisory. The disclosure SLA **MUST NOT** exceed the 90-day embargo defined in [Section 6.5](#65-coordinated-disclosure). -If a project cannot meet a Fix SLA, the TSC **MUST** communicate an updated timeline to the reporter and publish a mitigation or workaround advisory. +If a project cannot meet a Fix SLA, the TSC **MUST** communicate an updated timeline to the reporter and publish a mitigation or workaround advisory. Transparent communication about delays is always preferable to silently missing a deadline. Related sections: [6 — Vulnerability Response Process](#6-vulnerability-response-process); [6.5 — Coordinated Disclosure](#65-coordinated-disclosure). @@ -196,6 +198,8 @@ Related sections: [6 — Vulnerability Response Process](#6-vulnerability-respon Projects **SHOULD** sign all published release artifacts (container images, binaries, packages) using [Sigstore cosign](https://docs.sigstore.dev/cosign/signing/overview/) or an equivalent signing mechanism. Signing **SHOULD** be integrated into the CI/CD pipeline. +> **Practical note:** Artifact signing, build provenance, and SBOM generation (Sections 8.1–8.3) are intended to be adopted incrementally. Projects **SHOULD** prioritize dependency scanning ([Section 8.4](#84-dependency-scanning)) first, as it provides the highest security value with the least effort. The remaining supply chain practices can be introduced as the project matures and publishes artifacts to external consumers. + ### 8.2 Build Provenance (SLSA) | Priority | Resolution | Owner | diff --git a/templates/SECURITY.md b/templates/SECURITY.md index 74ae56c..879b817 100644 --- a/templates/SECURITY.md +++ b/templates/SECURITY.md @@ -41,14 +41,21 @@ The following maintainers are responsible for handling vulnerability reports: ## Supported Versions -*List which versions of your project currently receive security updates. Adjust the table to match -your release branches.* +*State clearly which versions receive security updates. Choose whichever format fits your project — +a table, a simple sentence, or a link to your release policy. Remove this guidance text before +publishing. Examples:* -| Version | Supported | -|---------|-----------| -| \ (latest) | Yes | -| \ | Yes | -| < \ | No | +**Option A — Single active branch (common for early-stage projects):** + +> Only the latest release on the `main` branch is supported with security updates. + +**Option B — Multiple supported releases:** + +> | Version | Supported | +> |---------|-----------| +> | 2.x | Yes | +> | 1.x | Yes (until YYYY-MM-DD) | +> | < 1.0 | No | ## Response Process @@ -61,13 +68,16 @@ This project follows the [NeoNephos Security Guidelines](../security-guidelines/ ### Severity Response SLAs -| Severity | CVSS Score | Fix Target | -|----------|------------|------------| +| Severity | CVSS Score | Fix Target (calendar days) | +|----------|------------|----------------------------| | Critical | 9.0 – 10.0 | ≤ 7 days | | High | 7.0 – 8.9 | ≤ 30 days | | Medium | 4.0 – 6.9 | ≤ 90 days | | Low | 0.1 – 3.9 | Best effort | +*If your project cannot meet a target, communicate an updated timeline to the reporter and publish +a workaround or mitigation advisory. Transparency matters more than speed.* + ## Disclosure Policy We follow [coordinated disclosure](https://en.wikipedia.org/wiki/Coordinated_vulnerability_disclosure). We ask that you: @@ -80,7 +90,7 @@ We are committed to crediting reporters in our security advisories unless you pr ## Past Security Advisories -*Link to your project's published GitHub Security Advisories. Remove this section if no advisories -have been published yet.* +*Optional — include this section only if your project has published advisories. Remove it entirely +for new projects.* See [Published Security Advisories](https://github.com///security/advisories?state=published). From 14f8e386256c28891f88328b749d6351b0fb293a Mon Sep 17 00:00:00 2001 From: Gerald Morrison Date: Tue, 7 Apr 2026 15:04:12 +0200 Subject: [PATCH 03/14] docs: relax supply chain resolution timelines to match project maturity MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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. --- security-guidelines/security-guidelines.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/security-guidelines/security-guidelines.md b/security-guidelines/security-guidelines.md index 803abbb..68c0f7d 100644 --- a/security-guidelines/security-guidelines.md +++ b/security-guidelines/security-guidelines.md @@ -192,9 +192,9 @@ Related sections: [6 — Vulnerability Response Process](#6-vulnerability-respon ### 8.1 Artifact Signing -| Priority | Resolution | Owner | -|------------|-----------------------|-------| -| **SHOULD** | By next minor release | TSC | +| Priority | Resolution | Owner | +|------------|----------------------------------------------|-------| +| **SHOULD** | When publishing artifacts to external consumers | TSC | Projects **SHOULD** sign all published release artifacts (container images, binaries, packages) using [Sigstore cosign](https://docs.sigstore.dev/cosign/signing/overview/) or an equivalent signing mechanism. Signing **SHOULD** be integrated into the CI/CD pipeline. @@ -202,9 +202,9 @@ Projects **SHOULD** sign all published release artifacts (container images, bina ### 8.2 Build Provenance (SLSA) -| Priority | Resolution | Owner | -|------------|-----------------------|-------| -| **SHOULD** | By next minor release | TSC | +| Priority | Resolution | Owner | +|------------|----------------------------------------------|-------| +| **SHOULD** | When publishing artifacts to external consumers | TSC | Projects **SHOULD** generate [SLSA](https://slsa.dev/) provenance attestations for published artifacts. The target level is at minimum [SLSA Build Level 2](https://slsa.dev/spec/v1.0/levels) (scripted build, hosted build platform). @@ -212,9 +212,9 @@ Projects **MAY** use the [SLSA GitHub Generator](https://github.com/slsa-framewo ### 8.3 Software Bill of Materials (SBOM) -| Priority | Resolution | Owner | -|------------|-----------------------|-------| -| **SHOULD** | By next minor release | TSC | +| Priority | Resolution | Owner | +|------------|----------------------------------------------|-------| +| **SHOULD** | When publishing artifacts to external consumers | TSC | Projects **SHOULD** generate a Software Bill of Materials (SBOM) for each published release artifact. SBOMs **MUST** use either [SPDX](https://spdx.dev/) or [CycloneDX](https://cyclonedx.org/) format. From 9319ade5b068c7d70b66d752c7eff71e77f80071 Mon Sep 17 00:00:00 2001 From: Gerald Morrison Date: Thu, 9 Apr 2026 15:14:14 +0200 Subject: [PATCH 04/14] =?UTF-8?q?docs:=20integrate=20PR=20feedback=20?= =?UTF-8?q?=E2=80=94=20add=20operational=20security=20controls,=20OpenSSF?= =?UTF-8?q?=20Scorecard,=20and=20template=20improvements?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - 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 --- security-guidelines/security-guidelines.md | 128 +++++++++++++++++++-- templates/SECURITY.md | 11 +- 2 files changed, 129 insertions(+), 10 deletions(-) diff --git a/security-guidelines/security-guidelines.md b/security-guidelines/security-guidelines.md index 68c0f7d..6489b3e 100644 --- a/security-guidelines/security-guidelines.md +++ b/security-guidelines/security-guidelines.md @@ -23,14 +23,21 @@ * [8.3 Software Bill of Materials (SBOM)](#83-software-bill-of-materials-sbom) * [8.4 Dependency Scanning](#84-dependency-scanning) * [9. Security Transparency](#9-security-transparency) - * [10. Acknowledgements](#10-acknowledgements) + * [10. Operational Security Controls](#10-operational-security-controls) + * [10.1 Authentication](#101-authentication) + * [10.2 CI/CD Security](#102-cicd-security) + * [10.3 Access Governance](#103-access-governance) + * [10.4 Code Quality and Scanning](#104-code-quality-and-scanning) + * [10.5 Data Retention](#105-data-retention) + * [10.6 Automated Security Posture Verification](#106-automated-security-posture-verification) + * [11. Acknowledgements](#11-acknowledgements) ## 1. Introduction -This document defines the security guidelines for projects governed by the **NeoNephos Foundation**. It establishes requirements for vulnerability disclosure, incident response, and supply chain security that all NeoNephos projects must follow. +This document defines the security guidelines for projects governed by the **NeoNephos Foundation**. It establishes requirements for vulnerability disclosure, incident response, supply chain security, and operational security controls that all NeoNephos projects must follow. -These guidelines complement the [NeoNephos Project Guidelines](../project-guidelines/project-guidelines.md), which reference this document in [Section 11 — Security](../project-guidelines/project-guidelines.md#11-security). Infrastructure-level security controls (2FA enforcement, GitHub Actions permissions, runner policies, and data retention) are defined in [Section 15.3 — Security and Compliance](../project-guidelines/project-guidelines.md#153-security-and-compliance) of the Project Guidelines and are not repeated here. +These guidelines complement the [NeoNephos Project Guidelines](../project-guidelines/project-guidelines.md), which reference this document in [Section 11 — Security](../project-guidelines/project-guidelines.md#11-security). Some operational security controls defined here overlap with [Section 15.3 — Security and Compliance](../project-guidelines/project-guidelines.md#153-security-and-compliance) of the Project Guidelines; this document provides the normative requirements while the Project Guidelines retain the operational context. Related sections: [2 — Normative Language](#2-normative-language); [3 — Conformance Model](#3-conformance-model); [4 — Scope](#4-scope). @@ -56,10 +63,10 @@ This document covers: - **Vulnerability disclosure and response**: How projects receive, handle, and disclose security vulnerabilities. - **Supply chain security**: Requirements for signing, provenance, SBOMs, and dependency management of released artifacts. +- **Operational security controls**: Authentication, CI/CD security, access governance, code scanning, and data retention requirements. This document does **not** cover: -- Infrastructure security controls (2FA, GitHub Actions, runners) — see [Project Guidelines §15.3](../project-guidelines/project-guidelines.md#153-security-and-compliance). - OpenSSF Best Practices Badge requirements — see [Project Lifecycle Policy](../lifecycle-policy/project-lifecycle-policy.md). - Governance, maintainer access, and operational policies — see [Project Guidelines](../project-guidelines/project-guidelines.md). @@ -85,8 +92,8 @@ Projects **SHOULD** enable Private Vulnerability Reporting at the organization l 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. +1. Instructions for reporting a vulnerability via GitHub Private Vulnerability Reporting, including a direct link where the `SECURITY.md` is repository-specific. +2. A version support policy stating which releases receive security updates (e.g., "the latest two minor releases" or a version table). 3. The expected response timeline (referencing [Section 6](#6-vulnerability-response-process) of this document). Projects **SHOULD** additionally provide an email address or alternative private channel for reporters who cannot use GitHub. @@ -250,7 +257,114 @@ Related sections: [6.6 — Post-Disclosure](#66-post-disclosure); [5.2 — SECUR --- -## 10. Acknowledgements +## 10. Operational Security Controls + +This section defines security-relevant operational controls for NeoNephos projects. These requirements complement the supply chain security practices in [Section 8](#8-supply-chain-security) and the infrastructure guarantees in the [Project Guidelines §15](../project-guidelines/project-guidelines.md#15-operational-guarantees). + +### 10.1 Authentication + +| Priority | Resolution | Owner | +|----------|-----------------|-------| +| **MUST** | ASAP (≤30 days) | TSC | + +Projects **MUST** enforce Two-Factor Authentication (2FA) for all organization members. + +Projects **SHOULD** disable SSH deploy keys at the organization level. Deploy keys lack per-user accountability; personal or machine accounts with MFA are preferred. + +### 10.2 CI/CD Security + +| Priority | Resolution | Owner | +|----------|-----------------|-------| +| **MUST** | ASAP (≤30 days) | TSC | + +**Self-hosted runners** + +- Repository-level self-hosted runners **MUST NOT** be enabled. +- Organization-level self-hosted runners **SHOULD NOT** be enabled unless necessary, and **MUST** be approved by GitHub Enterprise Cloud account administrators who record the decision via a TAC vote. +- *Rationale*: GitHub-hosted runners are preferred; self-hosted runners require careful hardening to prevent exploitation. + +**Fork pull-request workflows** + +- Projects **MUST** require approval for first-time contributors before workflows execute on fork pull requests. +- *Rationale*: Prevents unauthorized code execution from external contributors. + +**Workflow permissions** + +- The default `GITHUB_TOKEN` permission **MUST** be set to "Read repository contents and packages." +- Write access **MUST** be explicitly requested via the `permissions` key in workflow files. +- *Rationale*: Limits blast radius by preventing workflows from gaining unnecessary write access. + +**Credential handling** + +| Priority | Resolution | Owner | +|------------|-----------------|-------| +| **SHOULD** | ASAP (≤90 days) | TSC | + +- Projects **SHOULD** use workload identities (OIDC) or short-lived GitHub access tokens for interactions with external services. +- Where workload identity is not supported, projects **SHOULD** use fine-grained personal access tokens with the minimum required scopes. +- Temporary access tokens created for exceptional local batch jobs **MUST** be deleted immediately after use and **MUST NOT** exceed a lifetime of 6 hours. +- Projects **SHOULD** conduct package releases via CI/CD pipelines (GitHub Actions recommended) rather than from local machines. See also [Section 8.1 — Artifact Signing](#81-artifact-signing) and [Section 8.2 — Build Provenance](#82-build-provenance-slsa). + +### 10.3 Access Governance + +| Priority | Resolution | Owner | +|------------|-----------------|-------| +| **SHOULD** | ASAP (≤90 days) | TSC | + +Projects **SHOULD** follow the principle of least privilege for all access grants: + +- Limit GitHub Organization Owner access to a small number of administrative accounts. +- Limit the number of maintainers with repository admin permissions. +- Ensure settings and permissions changes are made only by trusted administrators. +- Use pull requests for all repository changes; consider preventing direct push access by requiring pull-request merges from forks. +- Maintain an up-to-date inventory of maintainer permissions across all platforms used by the project. + +**Maintainer vetting** + +Projects **SHOULD** require that maintainer candidates: + +1. Have a demonstrated history of contributions for at least 6 months. +2. Are vouched for by an existing maintainer. +3. Have verified their real identity with an existing maintainer, preferably in person. + +*Rationale*: Vetting contributors before granting commit or release access mitigates supply chain risks from compromised or malicious accounts (cf. the [xz-utils incident](https://en.wikipedia.org/wiki/XZ_Utils_backdoor)). For the broader contributor promotion process, see the [Project Lifecycle Policy](../lifecycle-policy/project-lifecycle-policy.md). + +### 10.4 Code Quality and Scanning + +| Priority | Resolution | Owner | +|------------|-----------------|-------| +| **SHOULD** | ASAP (≤90 days) | TSC | + +Projects **SHOULD** enable static application security testing (SAST) to detect code-level vulnerabilities. Examples of acceptable tools include [CodeQL](https://codeql.github.com/) and [SonarQube](https://www.sonarsource.com/products/sonarqube/). + +Projects **SHOULD** implement automated tests (unit, integration) as part of their CI pipeline to validate code correctness and prevent regressions. + +For dependency-level vulnerability scanning, see [Section 8.4 — Dependency Scanning](#84-dependency-scanning). + +### 10.5 Data Retention + +| Priority | Resolution | Owner | +|----------|-----------------|-------| +| **MUST** | ASAP (≤30 days) | TSC | + +- **Private repositories**: Artifact and log retention **MUST** be configured to 180 days. +- **Public repositories**: Retention defaults to 90 days (GitHub platform limitation). + +### 10.6 Automated Security Posture Verification + +| Priority | Resolution | Owner | +|------------|-----------------|-------| +| **SHOULD** | ASAP (≤90 days) | TSC | + +Projects **SHOULD** enable the [OpenSSF Scorecard](https://github.com/ossf/scorecard) on all repositories containing publishable code. Scorecard provides automated checks for many of the requirements in this document and the [Project Guidelines](../project-guidelines/project-guidelines.md), including branch protection, dependency scanning, CI permissions, and vulnerability disclosure. + +Projects **MAY** integrate Scorecard into their CI pipeline via the [Scorecard GitHub Action](https://github.com/ossf/scorecard-action) to receive continuous feedback on security posture. + +Related sections: [8 — Supply Chain Security](#8-supply-chain-security); [8.4 — Dependency Scanning](#84-dependency-scanning); [10.2 — CI/CD Security](#102-cicd-security). + +--- + +## 11. Acknowledgements | Priority | Resolution | Owner | |------------|-----------------|-------| diff --git a/templates/SECURITY.md b/templates/SECURITY.md index 879b817..6067215 100644 --- a/templates/SECURITY.md +++ b/templates/SECURITY.md @@ -23,6 +23,10 @@ Direct link: [Report a vulnerability](https://github.com///security/a *For more information, see [Privately reporting a security vulnerability](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability).* +*If this SECURITY.md is used as an organization-level file in a `.github` repository, remove the +direct link above and keep only the step-by-step instructions, since the link cannot point to a +specific repository.* + ### Alternative Contact *If your project offers an alternative private reporting channel (e.g., email), list it here. @@ -41,9 +45,10 @@ The following maintainers are responsible for handling vulnerability reports: ## Supported Versions -*State clearly which versions receive security updates. Choose whichever format fits your project — -a table, a simple sentence, or a link to your release policy. Remove this guidance text before -publishing. Examples:* +*State clearly which versions receive security updates. This should express a version support policy +(e.g., "the latest two minor releases") rather than naming specific branches. Choose whichever format +fits your project — a table, a simple sentence, or a link to your release policy. Remove this guidance +text before publishing. Examples:* **Option A — Single active branch (common for early-stage projects):** From 187b4b3b5a862d85760ae46b8aaf2d74130740c4 Mon Sep 17 00:00:00 2001 From: Gerald Morrison Date: Wed, 15 Apr 2026 11:06:16 +0200 Subject: [PATCH 05/14] docs: make vulnerability reporting platform-agnostic 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 #7, comment r3064032552). Signed-off-by: Gerald Morrison --- security-guidelines/security-guidelines.md | 60 +++++++++++++++++----- templates/SECURITY.md | 38 +++++++++++--- 2 files changed, 79 insertions(+), 19 deletions(-) diff --git a/security-guidelines/security-guidelines.md b/security-guidelines/security-guidelines.md index 6489b3e..9b58869 100644 --- a/security-guidelines/security-guidelines.md +++ b/security-guidelines/security-guidelines.md @@ -7,7 +7,10 @@ * [3. Conformance Model](#3-conformance-model) * [4. Scope](#4-scope) * [5. Security Contact per Project](#5-security-contact-per-project) - * [5.1 GitHub Private Vulnerability Reporting](#51-github-private-vulnerability-reporting) + * [5.1 Private Vulnerability Intake Channel](#51-private-vulnerability-intake-channel) + * [5.1.1 GitHub](#511-github) + * [5.1.2 GitLab](#512-gitlab) + * [5.1.3 Other Platforms and Self-Hosted Setups](#513-other-platforms-and-self-hosted-setups) * [5.2 SECURITY.md](#52-securitymd) * [6. Vulnerability Response Process](#6-vulnerability-response-process) * [6.1 Acknowledgement](#61-acknowledgement) @@ -74,16 +77,43 @@ This document does **not** cover: ## 5. Security Contact per Project -### 5.1 GitHub Private Vulnerability Reporting +### 5.1 Private Vulnerability Intake Channel | Priority | Resolution | Owner | |----------|-----------------|-------| | **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. +Projects **MUST** provide a private channel through which external reporters can submit vulnerability reports confidentially. The specific mechanism depends on the hosting platform, but **MUST** ensure that: + +1. Reports are visible only to designated security contacts (see [Section 6](#6-vulnerability-response-process)) and **MUST NOT** be publicly accessible. +2. The channel is documented in the project's `SECURITY.md` (see [Section 5.2](#52-securitymd)). +3. Reporters receive a confirmation that their report has been received. + +The following subsections define platform-specific requirements. + +#### 5.1.1 GitHub + +Projects hosted on **GitHub** **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 preferred intake channel for GitHub-hosted projects. Projects **SHOULD** enable Private Vulnerability Reporting at the organization level to ensure newly created repositories inherit this setting. +#### 5.1.2 GitLab + +Projects hosted on **GitLab** **MUST** accept vulnerability reports via [confidential issues](https://docs.gitlab.com/ee/user/project/issues/confidential_issues.html). The `SECURITY.md` **MUST** instruct reporters to mark issues as confidential when submitting vulnerability reports. + +Projects **SHOULD** configure an [issue template](https://docs.gitlab.com/ee/user/project/description_templates.html) named "Security Vulnerability" that pre-selects the confidentiality checkbox and provides a structured reporting form. + +#### 5.1.3 Other Platforms and Self-Hosted Setups + +Projects that are **not** hosted on GitHub or GitLab (e.g., self-hosted Gitea, Forgejo, Bitbucket, or other platforms) **MUST** provide at least one of the following private intake channels: + +1. **Encrypted email**: A dedicated security contact email address published in `SECURITY.md` and in a [`security.txt`](https://securitytxt.org/) file following [RFC 9116](https://www.rfc-editor.org/rfc/rfc9116). The project **SHOULD** publish a PGP/GPG public key to enable encrypted communication. +2. **Platform-native private reporting**: If the hosting platform offers a built-in confidential issue or vulnerability reporting mechanism, the project **MUST** enable and use it. + +Projects **SHOULD** additionally publish a `/.well-known/security.txt` file on any project website, conforming to [RFC 9116](https://www.rfc-editor.org/rfc/rfc9116), with at minimum the `Contact` and `Expires` fields. + +> **Practical note:** Regardless of platform, projects **SHOULD** provide an email address or alternative private channel in `SECURITY.md` as a fallback for reporters who do not have an account on the project's hosting platform. + ### 5.2 SECURITY.md | Priority | Resolution | Owner | @@ -92,11 +122,11 @@ Projects **SHOULD** enable Private Vulnerability Reporting at the organization l Projects **MUST** provide a `SECURITY.md` file in every repository that contains publishable code or artifacts. The `SECURITY.md` **MUST** include at minimum: -1. Instructions for reporting a vulnerability via GitHub Private Vulnerability Reporting, including a direct link where the `SECURITY.md` is repository-specific. +1. Instructions for reporting a vulnerability via the project's private intake channel (see [Section 5.1](#51-private-vulnerability-intake-channel)), including a direct link where applicable. 2. A version support policy stating which releases receive security updates (e.g., "the latest two minor releases" or a version table). 3. The expected response timeline (referencing [Section 6](#6-vulnerability-response-process) of this document). -Projects **SHOULD** additionally provide an email address or alternative private channel for reporters who cannot use GitHub. +Projects **SHOULD** additionally provide an email address or alternative private channel for reporters who do not have an account on the project's hosting platform. A template is available at [`../templates/SECURITY.md`](../templates/SECURITY.md). @@ -114,7 +144,7 @@ Each project's TSC **MUST** designate at least two maintainers as security conta ### 6.1 Acknowledgement -Projects **MUST** acknowledge receipt of a vulnerability report within **3 business days**. The acknowledgement **MUST** be sent via the same channel the report was received on (e.g., GitHub Security Advisory). +Projects **MUST** acknowledge receipt of a vulnerability report within **3 business days**. The acknowledgement **MUST** be sent via the same channel the report was received on (e.g., GitHub Security Advisory, GitLab confidential issue, or encrypted email). ### 6.2 Triage and Severity Assessment @@ -128,7 +158,9 @@ The reporter **SHOULD** be informed of the triage outcome and the planned remedi ### 6.3 Fix Coordination -Fix development **SHOULD** happen in a private fork or draft advisory within GitHub to prevent premature disclosure. The fix **MUST** be reviewed by at least one additional maintainer before merging. +Fix development **SHOULD** happen in a private fork, draft advisory, or other non-public workspace to prevent premature disclosure. The fix **MUST** be reviewed by at least one additional maintainer before merging. + +> **Platform-specific guidance:** On GitHub, use a [temporary private fork within a Security Advisory](https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/collaborating-in-a-temporary-private-fork-to-resolve-a-repository-security-vulnerability). On GitLab, use a [confidential merge request](https://docs.gitlab.com/ee/user/project/merge_requests/confidential.html). On other platforms, use a private branch or out-of-band patch review. If the vulnerability affects multiple NeoNephos projects, the reporting project's TSC **SHOULD** coordinate with the affected projects' TSCs before disclosure. The TAC **MAY** facilitate cross-project coordination. @@ -138,9 +170,9 @@ If the vulnerability affects multiple NeoNephos projects, the reporting project' |------------|-----------------|-------| | **SHOULD** | ASAP (≤30 days) | TSC | -Projects **SHOULD** request a CVE identifier for confirmed vulnerabilities with a CVSS score ≥ 4.0 (Medium or higher). CVE identifiers **SHOULD** be obtained via [GitHub's CNA program](https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/publishing-a-repository-security-advisory#requesting-a-cve-identification-number). +Projects **SHOULD** request a CVE identifier for confirmed vulnerabilities with a CVSS score ≥ 4.0 (Medium or higher). Projects hosted on GitHub **SHOULD** obtain CVE identifiers via [GitHub's CNA program](https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/publishing-a-repository-security-advisory#requesting-a-cve-identification-number). Projects on other platforms **MAY** request CVEs through [MITRE's CVE Request form](https://cveform.mitre.org/) or another authorized CNA. -> **Practical note:** CVE assignment adds credibility and traceability but involves administrative overhead. Early-stage projects or projects with a small user base **MAY** defer CVE assignment until a stable release has been published and external adoption is established. The GitHub Security Advisory alone already provides adequate transparency for most cases. +> **Practical note:** CVE assignment adds credibility and traceability but involves administrative overhead. Early-stage projects or projects with a small user base **MAY** defer CVE assignment until a stable release has been published and external adoption is established. A platform security advisory alone already provides adequate transparency for most cases. ### 6.5 Coordinated Disclosure @@ -151,12 +183,14 @@ Projects **SHOULD** request a CVE identifier for confirmed vulnerabilities with Projects **MUST** follow a coordinated disclosure process: 1. **Embargo period**: The maximum embargo duration is **90 calendar days** from the date the report is acknowledged. During this period, details of the vulnerability **MUST NOT** be disclosed publicly. -2. **Disclosure**: Once a fix is available (or the embargo expires), the project **MUST** publish a [GitHub Security Advisory](https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/publishing-a-repository-security-advisory) containing: +2. **Disclosure**: Once a fix is available (or the embargo expires), the project **MUST** publish a security advisory containing: - A description of the vulnerability. - Affected versions. - The CVSS score and vector. - The CVE identifier (if assigned). - Remediation steps or patched versions. + + On GitHub, use [GitHub Security Advisories](https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/publishing-a-repository-security-advisory). On GitLab, use a [project-level vulnerability record](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/). On other platforms, publish the advisory on the project website or mailing list and link to it from `SECURITY.md`. 3. **Early disclosure**: If active exploitation is detected in the wild, the TSC **MAY** shorten the embargo period and disclose early with whatever fix or mitigation is available. ### 6.6 Post-Disclosure @@ -187,7 +221,7 @@ Projects **MUST** classify vulnerabilities using [CVSS v3.1](https://www.first.o | **Low** | 0.1 – 3.9 | Best effort | Best effort | - **Fix SLA**: Time from triage completion to a fix being merged. -- **Disclosure SLA**: Time from triage completion to publishing a GitHub Security Advisory. The disclosure SLA **MUST NOT** exceed the 90-day embargo defined in [Section 6.5](#65-coordinated-disclosure). +- **Disclosure SLA**: Time from triage completion to publishing a security advisory (see [Section 6.5](#65-coordinated-disclosure)). The disclosure SLA **MUST NOT** exceed the 90-day embargo defined in [Section 6.5](#65-coordinated-disclosure). If a project cannot meet a Fix SLA, the TSC **MUST** communicate an updated timeline to the reporter and publish a mitigation or workaround advisory. Transparent communication about delays is always preferable to silently missing a deadline. @@ -247,7 +281,7 @@ Related sections: [Project Guidelines §15.3.2 — Supplemental Compliance](../p |----------|-----------------|-------| | **MUST** | ASAP (≤30 days) | TSC | -Projects **MUST** publish security advisories for all confirmed vulnerabilities with a CVSS score ≥ 4.0 via [GitHub Security Advisories](https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/about-repository-security-advisories). +Projects **MUST** publish security advisories for all confirmed vulnerabilities with a CVSS score ≥ 4.0 via the platform's advisory mechanism. On GitHub, use [GitHub Security Advisories](https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/about-repository-security-advisories). On GitLab, use [project-level vulnerability records](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/). On other platforms, publish advisories on the project website or mailing list and link to them from `SECURITY.md`. Projects **MUST** reference CVE identifiers and advisory links in the release notes of patched versions. @@ -370,6 +404,6 @@ Related sections: [8 — Supply Chain Security](#8-supply-chain-security); [8.4 |------------|-----------------|-------| | **SHOULD** | ASAP (≤30 days) | TSC | -Projects **SHOULD** credit security researchers who responsibly report vulnerabilities, unless the reporter requests anonymity. Acknowledgement **SHOULD** be included in the published GitHub Security Advisory and **MAY** also be included in release notes. +Projects **SHOULD** credit security researchers who responsibly report vulnerabilities, unless the reporter requests anonymity. Acknowledgement **SHOULD** be included in the published security advisory and **MAY** also be included in release notes. Related sections: [6.5 — Coordinated Disclosure](#65-coordinated-disclosure); [9 — Security Transparency](#9-security-transparency). diff --git a/templates/SECURITY.md b/templates/SECURITY.md index 6067215..91a63d1 100644 --- a/templates/SECURITY.md +++ b/templates/SECURITY.md @@ -11,7 +11,10 @@ set of requirements.* If you discover a security vulnerability in **\**, please report it responsibly through one of the channels below. **Do not open a public issue for security vulnerabilities.** -### GitHub Private Vulnerability Reporting (Preferred) +*Choose the section that matches your hosting platform. Remove the other sections and this guidance +text before publishing.* + +### Option A: GitHub Private Vulnerability Reporting (Preferred for GitHub-hosted projects) Please use GitHub's built-in private vulnerability reporting: @@ -27,9 +30,30 @@ Direct link: [Report a vulnerability](https://github.com///security/a direct link above and keep only the step-by-step instructions, since the link cannot point to a specific repository.* +### Option B: GitLab Confidential Issues (Preferred for GitLab-hosted projects) + +Please report vulnerabilities as a **confidential issue**: + +1. Navigate to **Issues** in this project. +2. Click **New issue**. +3. Check the **"This issue is confidential"** checkbox. +4. Provide a detailed description including steps to reproduce. +5. Submit the issue. + +*For more information, see [Confidential issues](https://docs.gitlab.com/ee/user/project/issues/confidential_issues.html).* + +### Option C: Email (For other platforms or as a fallback) + +You may report vulnerabilities via email to **\**. + +*If your project publishes a PGP/GPG key for encrypted communication, mention it here and provide +a link to the public key or a fingerprint. Projects SHOULD also publish a +[`security.txt`](https://securitytxt.org/) file following [RFC 9116](https://www.rfc-editor.org/rfc/rfc9116).* + ### Alternative Contact -*If your project offers an alternative private reporting channel (e.g., email), list it here. +*If your project offers an additional private reporting channel beyond the primary one above +(e.g., email as fallback for a GitHub/GitLab-hosted project), list it here. Otherwise, remove this section.* You may also report vulnerabilities via email to **\**. @@ -38,11 +62,13 @@ You may also report vulnerabilities via email to **\**. The following maintainers are responsible for handling vulnerability reports: -| Name | GitHub Handle | Role | -|------|---------------|------| +| Name | Handle | Role | +|------|--------|------| | *\* | [@\](https://github.com/) | Security Officer | | *\* | [@\](https://github.com/) | Maintainer | +*Adjust the profile links to match your hosting platform.* + ## Supported Versions *State clearly which versions receive security updates. This should express a version support policy @@ -69,7 +95,7 @@ This project follows the [NeoNephos Security Guidelines](../security-guidelines/ - **Acknowledgement**: We will acknowledge your report within **3 business days**. - **Triage**: We will assess the severity (using [CVSS v3.1](https://www.first.org/cvss/v3.1/specification-document)) within **7 calendar days**. - **Embargo**: Vulnerability details will remain confidential for up to **90 days** while a fix is developed. -- **Disclosure**: Once a fix is available, we will publish a [GitHub Security Advisory](https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/about-repository-security-advisories) with full details. +- **Disclosure**: Once a fix is available, we will publish a security advisory with full details. ### Severity Response SLAs @@ -96,6 +122,6 @@ We are committed to crediting reporters in our security advisories unless you pr ## Past Security Advisories *Optional — include this section only if your project has published advisories. Remove it entirely -for new projects.* +for new projects. Adjust the link to match your hosting platform.* See [Published Security Advisories](https://github.com///security/advisories?state=published). From 559970e2233aea065a8c69a7bb7eec65b6b2938e Mon Sep 17 00:00:00 2001 From: Gerald Morrison Date: Fri, 17 Apr 2026 14:57:20 +0200 Subject: [PATCH 06/14] docs: add container image scanning and license compliance scanning sections MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add §8.5 and §8.6 to supply chain security guidelines, aligned with OpenSSF Security Baseline controls (OSPS-VM-05.01–05.03, OSPS-LE-02). Recommends Trivy, Grype, OSV-Scanner for image scanning and Trivy, Anchore Grant, REUSE for license compliance. --- security-guidelines/security-guidelines.md | 34 ++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/security-guidelines/security-guidelines.md b/security-guidelines/security-guidelines.md index 9b58869..b4b3205 100644 --- a/security-guidelines/security-guidelines.md +++ b/security-guidelines/security-guidelines.md @@ -25,6 +25,8 @@ * [8.2 Build Provenance (SLSA)](#82-build-provenance-slsa) * [8.3 Software Bill of Materials (SBOM)](#83-software-bill-of-materials-sbom) * [8.4 Dependency Scanning](#84-dependency-scanning) + * [8.5 Container Image Scanning](#85-container-image-scanning) + * [8.6 License Compliance Scanning](#86-license-compliance-scanning) * [9. Security Transparency](#9-security-transparency) * [10. Operational Security Controls](#10-operational-security-controls) * [10.1 Authentication](#101-authentication) @@ -273,6 +275,38 @@ Projects **SHOULD** configure automated dependency update pull requests to reduc Related sections: [Project Guidelines §15.3.2 — Supplemental Compliance](../project-guidelines/project-guidelines.md#1532-supplemental-compliance); [Project Guidelines §6 — Technical and Development Practices](../project-guidelines/project-guidelines.md#6-technical-and-development-practices). +### 8.5 Container Image Scanning + +| Priority | Resolution | Owner | +|------------|----------------------------------------------|-------| +| **SHOULD** | When publishing container images | TSC | + +Projects that publish container images **SHOULD** scan all images for known vulnerabilities before pushing them to a registry. Image scanning **SHOULD** be integrated into the CI/CD pipeline so that every built image is evaluated before publication. + +Projects **SHOULD** fail the pipeline (or at minimum generate a warning) when vulnerabilities at or above a project-defined severity threshold are detected. Projects **SHOULD** define this threshold explicitly (e.g., "Critical and High"). + +Examples of acceptable tools include [Trivy](https://github.com/aquasecurity/trivy), [Grype](https://github.com/anchore/grype), [OSV-Scanner](https://google.github.io/osv-scanner/), or equivalent. Registry-level scanning (e.g., Harbor with integrated Trivy, or cloud-native registry scanning) **MAY** be used as an additional layer but **SHOULD NOT** replace pipeline-level scanning. + +> **OpenSSF alignment:** The [OpenSSF Security Baseline](https://baseline.openssf.org/) controls `OSPS-VM-05.01` through `OSPS-VM-05.03` (Maturity Level 3) require projects to define thresholds for SCA findings — including container image vulnerabilities — address violations before release, and automatically evaluate changes against policy. + +Related sections: [8.3 — Software Bill of Materials (SBOM)](#83-software-bill-of-materials-sbom); [8.4 — Dependency Scanning](#84-dependency-scanning). + +### 8.6 License Compliance Scanning + +| Priority | Resolution | Owner | +|------------|-----------------|-------| +| **SHOULD** | ASAP (≤90 days) | TSC | + +Projects **SHOULD** automate license scanning of all direct and transitive dependencies to detect incompatible, unknown, or unlicensed components. License scanning **SHOULD** be integrated into the CI/CD pipeline. + +Projects **SHOULD** define an allowlist of acceptable licenses (e.g., OSI-approved permissive licenses such as MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause) and flag any dependency whose license is not on the allowlist. Dependencies with incompatible or unknown licenses **SHOULD** be resolved before release. + +Examples of acceptable tools include [Trivy](https://github.com/aquasecurity/trivy) (supports license scanning), [Anchore Grant](https://github.com/anchore/grant), [REUSE](https://reuse.software/), or equivalent. + +> **OpenSSF alignment:** The [OpenSSF Security Baseline](https://baseline.openssf.org/) controls `OSPS-LE-02.01` and `OSPS-LE-02.02` (Maturity Level 1) require that project licenses meet the OSI or FSF definitions. Controls `OSPS-VM-05.01` and `OSPS-VM-05.02` (Maturity Level 3) extend this to dependencies, requiring projects to define thresholds for license-related SCA findings and address violations before release. + +Related sections: [8.4 — Dependency Scanning](#84-dependency-scanning); [8.5 — Container Image Scanning](#85-container-image-scanning). + --- ## 9. Security Transparency From d7b21b02565cb54ea6825c13a78d937a4abdc72d Mon Sep 17 00:00:00 2001 From: Gerald Morrison Date: Fri, 17 Apr 2026 16:14:36 +0200 Subject: [PATCH 07/14] docs: align security guidelines with OpenSSF Security Baseline Add branch protection (MUST), secret scanning (MUST), CI/CD input sanitization, action pinning, SAST thresholds, security assessment, and provenance verification guidance. Strengthen existing sections with OpenSSF Baseline control references (OSPS-AC-03, BR-01, BR-07, VM-06, SA-03, DO-03, BR-04). All additions link to upstream docs rather than duplicating content. --- security-guidelines/security-guidelines.md | 92 ++++++++++++++++++++-- 1 file changed, 84 insertions(+), 8 deletions(-) diff --git a/security-guidelines/security-guidelines.md b/security-guidelines/security-guidelines.md index b4b3205..9762dad 100644 --- a/security-guidelines/security-guidelines.md +++ b/security-guidelines/security-guidelines.md @@ -31,10 +31,13 @@ * [10. Operational Security Controls](#10-operational-security-controls) * [10.1 Authentication](#101-authentication) * [10.2 CI/CD Security](#102-cicd-security) - * [10.3 Access Governance](#103-access-governance) - * [10.4 Code Quality and Scanning](#104-code-quality-and-scanning) - * [10.5 Data Retention](#105-data-retention) - * [10.6 Automated Security Posture Verification](#106-automated-security-posture-verification) + * [10.3 Branch Protection](#103-branch-protection) + * [10.4 Secret Scanning and Prevention](#104-secret-scanning-and-prevention) + * [10.5 Access Governance](#105-access-governance) + * [10.6 Code Quality and Scanning](#106-code-quality-and-scanning) + * [10.7 Data Retention](#107-data-retention) + * [10.8 Security Assessment](#108-security-assessment) + * [10.9 Automated Security Posture Verification](#109-automated-security-posture-verification) * [11. Acknowledgements](#11-acknowledgements) @@ -75,6 +78,8 @@ This document does **not** cover: - OpenSSF Best Practices Badge requirements — see [Project Lifecycle Policy](../lifecycle-policy/project-lifecycle-policy.md). - Governance, maintainer access, and operational policies — see [Project Guidelines](../project-guidelines/project-guidelines.md). +Where applicable, individual sections reference the corresponding controls from the [OpenSSF Security Baseline (OSPS)](https://baseline.openssf.org/) to help projects map these guidelines to the broader open source security ecosystem. + --- ## 5. Security Contact per Project @@ -253,6 +258,8 @@ Projects **SHOULD** generate [SLSA](https://slsa.dev/) provenance attestations f Projects **MAY** use the [SLSA GitHub Generator](https://github.com/slsa-framework/slsa-github-generator) or equivalent tooling to generate and publish provenance attestations. +Projects that publish provenance attestations **SHOULD** document how consumers can verify them (e.g., via `cosign verify-attestation` or `slsa-verifier`). See [OpenSSF Security Baseline](https://baseline.openssf.org/) controls `OSPS-DO-03.01` and `OSPS-DO-03.02` (Level 3). + ### 8.3 Software Bill of Materials (SBOM) | Priority | Resolution | Owner | @@ -319,6 +326,8 @@ Projects **MUST** publish security advisories for all confirmed vulnerabilities Projects **MUST** reference CVE identifiers and advisory links in the release notes of patched versions. +Release changelogs **SHOULD** explicitly flag security-relevant modifications (fixes, dependency updates addressing CVEs, configuration changes with security impact). See [OpenSSF Security Baseline](https://baseline.openssf.org/) control `OSPS-BR-04.01` (Level 2). + Projects **SHOULD** maintain a public record of past security advisories accessible from the project's `SECURITY.md`. Related sections: [6.6 — Post-Disclosure](#66-post-disclosure); [5.2 — SECURITY.md](#52-securitymd). @@ -373,7 +382,54 @@ Projects **SHOULD** disable SSH deploy keys at the organization level. Deploy ke - Temporary access tokens created for exceptional local batch jobs **MUST** be deleted immediately after use and **MUST NOT** exceed a lifetime of 6 hours. - Projects **SHOULD** conduct package releases via CI/CD pipelines (GitHub Actions recommended) rather than from local machines. See also [Section 8.1 — Artifact Signing](#81-artifact-signing) and [Section 8.2 — Build Provenance](#82-build-provenance-slsa). -### 10.3 Access Governance +**Pipeline input sanitization** + +| Priority | Resolution | Owner | +|------------|-----------------|-------| +| **SHOULD** | ASAP (≤90 days) | TSC | + +- Workflows **SHOULD** treat all externally supplied metadata (issue titles, PR bodies, branch names, commit messages) as untrusted input and sanitize it before use in shell commands, environment variables, or script interpolation. +- Workflows triggered by events from untrusted sources (e.g., `pull_request_target`, `issue_comment`) **SHOULD NOT** check out or execute code from the untrusted source in a context that has access to repository secrets. +- *Rationale*: Prevents script injection and privilege escalation via CI/CD pipelines. See [OpenSSF Security Baseline](https://baseline.openssf.org/) `OSPS-BR-01.01` (Level 1) and the [OpenSSF SCM Best Practices](https://best.openssf.org/SCM-BestPractices/). + +**Workflow dependency pinning and action provenance** + +| Priority | Resolution | Owner | +|------------|-----------------|-------| +| **SHOULD** | ASAP (≤90 days) | TSC | + +- Third-party GitHub Actions **SHOULD** be pinned to a specific commit SHA rather than a mutable tag (e.g., `actions/checkout@` instead of `actions/checkout@v4`). +- Projects **SHOULD** restrict allowed GitHub Actions to actions created by GitHub and verified creators, or to an explicit allowlist maintained by the project. See the [OpenSSF Scorecard `Pinned-Dependencies` check](https://github.com/ossf/scorecard/blob/main/docs/checks.md#pinned-dependencies). + +### 10.3 Branch Protection + +| Priority | Resolution | Owner | +|----------|-----------------|-------| +| **MUST** | ASAP (≤30 days) | TSC | + +Projects **MUST** enable branch protection rules on the primary branch (e.g., `main`) of every repository containing publishable code. At minimum: + +1. Direct commits to the primary branch **MUST** be prevented; all changes **MUST** go through a pull request or merge request. +2. Force-pushes to the primary branch **MUST** be disabled. +3. Deletion of the primary branch **MUST** be prevented. +4. At least one approving review from a non-author maintainer **MUST** be required before merge. +5. Required status checks (CI build, tests, security scans) **SHOULD** pass before merge. + +> **OpenSSF alignment:** [OpenSSF Security Baseline](https://baseline.openssf.org/) controls `OSPS-AC-03.01` and `OSPS-AC-03.02` (Level 1) require preventing unauthorized commits and deletion of the primary branch. Control `OSPS-QA-07.01` (Level 3) requires non-author approval before merge. See also the [OpenSSF SCM Best Practices](https://best.openssf.org/SCM-BestPractices/) for platform-specific configuration guidance. + +### 10.4 Secret Scanning and Prevention + +| Priority | Resolution | Owner | +|----------|-----------------|-------| +| **MUST** | ASAP (≤30 days) | TSC | + +Projects **MUST** enable automated secret scanning on all repositories to detect accidentally committed credentials, API keys, and tokens. On GitHub, enable [Secret Scanning](https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning) and [Push Protection](https://docs.github.com/en/code-security/secret-scanning/introduction/about-push-protection). On GitLab, enable [Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/). On other platforms, integrate a tool such as [Gitleaks](https://github.com/gitleaks/gitleaks) or [TruffleHog](https://github.com/trufflesecurity/trufflehog) into the CI pipeline. + +Projects **SHOULD** enable push protection to block commits containing detected secrets before they enter the repository history. + +> **OpenSSF alignment:** [OpenSSF Security Baseline](https://baseline.openssf.org/) control `OSPS-BR-07.01` (Level 1) requires that the project's version control system **MUST** prevent secrets from being included in a commit. The [OpenSSF Concise Guide for Developing More Secure Software](https://best.openssf.org/Concise-Guide-for-Developing-More-Secure-Software) (Recommendation #9) reinforces this requirement. + +### 10.5 Access Governance | Priority | Resolution | Owner | |------------|-----------------|-------| @@ -397,7 +453,7 @@ Projects **SHOULD** require that maintainer candidates: *Rationale*: Vetting contributors before granting commit or release access mitigates supply chain risks from compromised or malicious accounts (cf. the [xz-utils incident](https://en.wikipedia.org/wiki/XZ_Utils_backdoor)). For the broader contributor promotion process, see the [Project Lifecycle Policy](../lifecycle-policy/project-lifecycle-policy.md). -### 10.4 Code Quality and Scanning +### 10.6 Code Quality and Scanning | Priority | Resolution | Owner | |------------|-----------------|-------| @@ -405,11 +461,15 @@ Projects **SHOULD** require that maintainer candidates: Projects **SHOULD** enable static application security testing (SAST) to detect code-level vulnerabilities. Examples of acceptable tools include [CodeQL](https://codeql.github.com/) and [SonarQube](https://www.sonarsource.com/products/sonarqube/). +Projects **SHOULD** define a severity threshold for SAST findings (e.g., "Critical and High") and **SHOULD** fail or gate the CI pipeline when findings at or above the threshold are detected. Findings below the threshold **SHOULD** be tracked and triaged but need not block merges. + Projects **SHOULD** implement automated tests (unit, integration) as part of their CI pipeline to validate code correctness and prevent regressions. +> **OpenSSF alignment:** [OpenSSF Security Baseline](https://baseline.openssf.org/) controls `OSPS-VM-06.01` and `OSPS-VM-06.02` (Level 3) require projects to define a threshold for SAST findings and automatically block changes that violate it. + For dependency-level vulnerability scanning, see [Section 8.4 — Dependency Scanning](#84-dependency-scanning). -### 10.5 Data Retention +### 10.7 Data Retention | Priority | Resolution | Owner | |----------|-----------------|-------| @@ -418,7 +478,23 @@ For dependency-level vulnerability scanning, see [Section 8.4 — Dependency Sca - **Private repositories**: Artifact and log retention **MUST** be configured to 180 days. - **Public repositories**: Retention defaults to 90 days (GitHub platform limitation). -### 10.6 Automated Security Posture Verification +### 10.8 Security Assessment + +| Priority | Resolution | Owner | +|------------|-----------------|-------| +| **SHOULD** | ASAP (≤90 days) | TSC | + +Projects **SHOULD** perform an initial security assessment when entering the Growth or Graduated lifecycle stage. The assessment **SHOULD** include: + +1. Identification of the project's trust boundaries and external interfaces. +2. A lightweight threat model covering the project's primary attack surfaces (e.g., using [STRIDE](https://en.wikipedia.org/wiki/STRIDE_%28security%29) or equivalent). +3. Documentation of known security assumptions and residual risks. + +The assessment does not need to be formal; a section in the project's documentation or a dedicated `SECURITY_ASSESSMENT.md` is sufficient. Projects **SHOULD** review and update the assessment when significant architectural changes occur. + +> **OpenSSF alignment:** [OpenSSF Security Baseline](https://baseline.openssf.org/) controls `OSPS-SA-03.01` (Level 2) and `OSPS-SA-03.02` (Level 3) require security assessment, threat modeling, and attack surface analysis for mature projects. + +### 10.9 Automated Security Posture Verification | Priority | Resolution | Owner | |------------|-----------------|-------| From 5b7ba8d58f573f9936b091d4b11528022383835a Mon Sep 17 00:00:00 2001 From: Gerald Morrison Date: Mon, 20 Apr 2026 17:34:35 +0200 Subject: [PATCH 08/14] docs: trim implementation details, add SLA rationale and exemplary project references MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Add paragraph in introduction clarifying relationship to OpenSSF standards - Add industry rationale for SLAs (benchmarked against Envoy, GitLab, Chainguard) - Trim §8.2 (SLSA), §8.5 (container scanning), §8.6 (license scanning): replace verbose tool/implementation details with concise requirements + OpenSSF references - Condense §10.6 (SAST) from 9 lines to 3, keeping requirement and threshold concept - Add exemplary project references: Gardener (SECURITY.md), OCM (CI/CD, Scorecard) --- security-guidelines/security-guidelines.md | 30 ++++++++++------------ 1 file changed, 14 insertions(+), 16 deletions(-) diff --git a/security-guidelines/security-guidelines.md b/security-guidelines/security-guidelines.md index 9762dad..772cfce 100644 --- a/security-guidelines/security-guidelines.md +++ b/security-guidelines/security-guidelines.md @@ -47,6 +47,8 @@ This document defines the security guidelines for projects governed by the **Neo These guidelines complement the [NeoNephos Project Guidelines](../project-guidelines/project-guidelines.md), which reference this document in [Section 11 — Security](../project-guidelines/project-guidelines.md#11-security). Some operational security controls defined here overlap with [Section 15.3 — Security and Compliance](../project-guidelines/project-guidelines.md#153-security-and-compliance) of the Project Guidelines; this document provides the normative requirements while the Project Guidelines retain the operational context. +These guidelines build on established open source security standards — in particular the [OpenSSF Security Baseline](https://baseline.openssf.org/), [SLSA](https://slsa.dev/), and the [OpenSSF Best Practices Badge](https://www.bestpractices.dev/). Rather than duplicating those standards, this document defines NeoNephos-specific requirements (such as response SLAs and conformance tiers) and provides platform-specific guidance that generic standards cannot offer. Where a topic is fully covered by an external standard, this document states the requirement and references the authoritative source. + Related sections: [2 — Normative Language](#2-normative-language); [3 — Conformance Model](#3-conformance-model); [4 — Scope](#4-scope). --- @@ -137,6 +139,8 @@ Projects **SHOULD** additionally provide an email address or alternative private A template is available at [`../templates/SECURITY.md`](../templates/SECURITY.md). +> **Exemplary implementation:** [Gardener's SECURITY.md](https://github.com/gardener/.github/blob/main/SECURITY.md) includes named security contacts, a detailed disclosure process, and severity-based handling. + Related sections: [6 — Vulnerability Response Process](#6-vulnerability-response-process); [7 — Severity Classification and Response SLAs](#7-severity-classification-and-response-slas). --- @@ -232,6 +236,8 @@ Projects **MUST** classify vulnerabilities using [CVSS v3.1](https://www.first.o If a project cannot meet a Fix SLA, the TSC **MUST** communicate an updated timeline to the reporter and publish a mitigation or workaround advisory. Transparent communication about delays is always preferable to silently missing a deadline. +> **Rationale:** These SLAs are aligned with industry practice. The 90-day embargo follows the [OpenSSF Model Outbound Vulnerability Disclosure Policy](https://github.com/ossf/oss-vulnerability-guide/blob/main/maintainer-guide.md) and is consistent with CNCF projects such as Envoy. The severity-based fix timelines are comparable to those used by GitLab and Chainguard, adjusted from "patch availability" to "triage completion" to reflect the realities of volunteer-maintained open source projects. + Related sections: [6 — Vulnerability Response Process](#6-vulnerability-response-process); [6.5 — Coordinated Disclosure](#65-coordinated-disclosure). --- @@ -256,9 +262,7 @@ Projects **SHOULD** sign all published release artifacts (container images, bina Projects **SHOULD** generate [SLSA](https://slsa.dev/) provenance attestations for published artifacts. The target level is at minimum [SLSA Build Level 2](https://slsa.dev/spec/v1.0/levels) (scripted build, hosted build platform). -Projects **MAY** use the [SLSA GitHub Generator](https://github.com/slsa-framework/slsa-github-generator) or equivalent tooling to generate and publish provenance attestations. - -Projects that publish provenance attestations **SHOULD** document how consumers can verify them (e.g., via `cosign verify-attestation` or `slsa-verifier`). See [OpenSSF Security Baseline](https://baseline.openssf.org/) controls `OSPS-DO-03.01` and `OSPS-DO-03.02` (Level 3). +For implementation guidance and tooling options, see the [SLSA specification](https://slsa.dev/spec/v1.0/) and [OpenSSF Security Baseline](https://baseline.openssf.org/) controls `OSPS-DO-03.01` and `OSPS-DO-03.02` (Level 3). ### 8.3 Software Bill of Materials (SBOM) @@ -292,9 +296,7 @@ Projects that publish container images **SHOULD** scan all images for known vuln Projects **SHOULD** fail the pipeline (or at minimum generate a warning) when vulnerabilities at or above a project-defined severity threshold are detected. Projects **SHOULD** define this threshold explicitly (e.g., "Critical and High"). -Examples of acceptable tools include [Trivy](https://github.com/aquasecurity/trivy), [Grype](https://github.com/anchore/grype), [OSV-Scanner](https://google.github.io/osv-scanner/), or equivalent. Registry-level scanning (e.g., Harbor with integrated Trivy, or cloud-native registry scanning) **MAY** be used as an additional layer but **SHOULD NOT** replace pipeline-level scanning. - -> **OpenSSF alignment:** The [OpenSSF Security Baseline](https://baseline.openssf.org/) controls `OSPS-VM-05.01` through `OSPS-VM-05.03` (Maturity Level 3) require projects to define thresholds for SCA findings — including container image vulnerabilities — address violations before release, and automatically evaluate changes against policy. +Examples of acceptable tools include [Trivy](https://github.com/aquasecurity/trivy), [Grype](https://github.com/anchore/grype), or [OSV-Scanner](https://google.github.io/osv-scanner/). See [OpenSSF Security Baseline](https://baseline.openssf.org/) controls `OSPS-VM-05.01` through `OSPS-VM-05.03` (Level 3) for additional guidance on SCA thresholds and policy evaluation. Related sections: [8.3 — Software Bill of Materials (SBOM)](#83-software-bill-of-materials-sbom); [8.4 — Dependency Scanning](#84-dependency-scanning). @@ -308,9 +310,7 @@ Projects **SHOULD** automate license scanning of all direct and transitive depen Projects **SHOULD** define an allowlist of acceptable licenses (e.g., OSI-approved permissive licenses such as MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause) and flag any dependency whose license is not on the allowlist. Dependencies with incompatible or unknown licenses **SHOULD** be resolved before release. -Examples of acceptable tools include [Trivy](https://github.com/aquasecurity/trivy) (supports license scanning), [Anchore Grant](https://github.com/anchore/grant), [REUSE](https://reuse.software/), or equivalent. - -> **OpenSSF alignment:** The [OpenSSF Security Baseline](https://baseline.openssf.org/) controls `OSPS-LE-02.01` and `OSPS-LE-02.02` (Maturity Level 1) require that project licenses meet the OSI or FSF definitions. Controls `OSPS-VM-05.01` and `OSPS-VM-05.02` (Maturity Level 3) extend this to dependencies, requiring projects to define thresholds for license-related SCA findings and address violations before release. +Examples of acceptable tools include [Trivy](https://github.com/aquasecurity/trivy), [REUSE](https://reuse.software/), or equivalent. See [OpenSSF Security Baseline](https://baseline.openssf.org/) controls `OSPS-LE-02.01`, `OSPS-LE-02.02` (Level 1) and `OSPS-VM-05.01`, `OSPS-VM-05.02` (Level 3) for alignment with broader license compliance requirements. Related sections: [8.4 — Dependency Scanning](#84-dependency-scanning); [8.5 — Container Image Scanning](#85-container-image-scanning). @@ -401,6 +401,8 @@ Projects **SHOULD** disable SSH deploy keys at the organization level. Deploy ke - Third-party GitHub Actions **SHOULD** be pinned to a specific commit SHA rather than a mutable tag (e.g., `actions/checkout@` instead of `actions/checkout@v4`). - Projects **SHOULD** restrict allowed GitHub Actions to actions created by GitHub and verified creators, or to an explicit allowlist maintained by the project. See the [OpenSSF Scorecard `Pinned-Dependencies` check](https://github.com/ossf/scorecard/blob/main/docs/checks.md#pinned-dependencies). +> **Exemplary implementation:** The [Open Component Model CI workflows](https://github.com/open-component-model/open-component-model/tree/main/.github/workflows) demonstrate SHA-pinned actions, minimal `GITHUB_TOKEN` permissions with per-job escalation, and safe `pull_request_target` handling. + ### 10.3 Branch Protection | Priority | Resolution | Owner | @@ -459,13 +461,7 @@ Projects **SHOULD** require that maintainer candidates: |------------|-----------------|-------| | **SHOULD** | ASAP (≤90 days) | TSC | -Projects **SHOULD** enable static application security testing (SAST) to detect code-level vulnerabilities. Examples of acceptable tools include [CodeQL](https://codeql.github.com/) and [SonarQube](https://www.sonarsource.com/products/sonarqube/). - -Projects **SHOULD** define a severity threshold for SAST findings (e.g., "Critical and High") and **SHOULD** fail or gate the CI pipeline when findings at or above the threshold are detected. Findings below the threshold **SHOULD** be tracked and triaged but need not block merges. - -Projects **SHOULD** implement automated tests (unit, integration) as part of their CI pipeline to validate code correctness and prevent regressions. - -> **OpenSSF alignment:** [OpenSSF Security Baseline](https://baseline.openssf.org/) controls `OSPS-VM-06.01` and `OSPS-VM-06.02` (Level 3) require projects to define a threshold for SAST findings and automatically block changes that violate it. +Projects **SHOULD** enable static application security testing (SAST) — such as [CodeQL](https://codeql.github.com/) or [SonarQube](https://www.sonarsource.com/products/sonarqube/) — to detect code-level vulnerabilities. Projects **SHOULD** define a severity threshold (e.g., "Critical and High") and gate the CI pipeline on it. See [OpenSSF Security Baseline](https://baseline.openssf.org/) controls `OSPS-VM-06.01` and `OSPS-VM-06.02` (Level 3). For dependency-level vulnerability scanning, see [Section 8.4 — Dependency Scanning](#84-dependency-scanning). @@ -504,6 +500,8 @@ Projects **SHOULD** enable the [OpenSSF Scorecard](https://github.com/ossf/score Projects **MAY** integrate Scorecard into their CI pipeline via the [Scorecard GitHub Action](https://github.com/ossf/scorecard-action) to receive continuous feedback on security posture. +> **Exemplary implementation:** The [Open Component Model Scorecard workflow](https://github.com/open-component-model/open-component-model/blob/main/.github/workflows/openssf-scorecard.yml) runs Scorecard with SARIF upload to the code-scanning dashboard. + Related sections: [8 — Supply Chain Security](#8-supply-chain-security); [8.4 — Dependency Scanning](#84-dependency-scanning); [10.2 — CI/CD Security](#102-cicd-security). --- From f22cb7357ddc77127eb1c6cbb66818922ee7aefe Mon Sep 17 00:00:00 2001 From: Gerald Morrison Date: Mon, 20 Apr 2026 18:44:30 +0200 Subject: [PATCH 09/14] consolidate section 8, Revise introduction statement and point to OpenSSF --- security-guidelines/security-guidelines.md | 90 ++++++++++------------ templates/SECURITY.md | 40 +++++----- 2 files changed, 63 insertions(+), 67 deletions(-) diff --git a/security-guidelines/security-guidelines.md b/security-guidelines/security-guidelines.md index 772cfce..f6fae5b 100644 --- a/security-guidelines/security-guidelines.md +++ b/security-guidelines/security-guidelines.md @@ -13,7 +13,7 @@ * [5.1.3 Other Platforms and Self-Hosted Setups](#513-other-platforms-and-self-hosted-setups) * [5.2 SECURITY.md](#52-securitymd) * [6. Vulnerability Response Process](#6-vulnerability-response-process) - * [6.1 Acknowledgement](#61-acknowledgement) + * [6.1 Initial Response](#61-initial-response) * [6.2 Triage and Severity Assessment](#62-triage-and-severity-assessment) * [6.3 Fix Coordination](#63-fix-coordination) * [6.4 CVE Assignment](#64-cve-assignment) @@ -24,9 +24,7 @@ * [8.1 Artifact Signing](#81-artifact-signing) * [8.2 Build Provenance (SLSA)](#82-build-provenance-slsa) * [8.3 Software Bill of Materials (SBOM)](#83-software-bill-of-materials-sbom) - * [8.4 Dependency Scanning](#84-dependency-scanning) - * [8.5 Container Image Scanning](#85-container-image-scanning) - * [8.6 License Compliance Scanning](#86-license-compliance-scanning) + * [8.4 Software Composition Analysis (SCA)](#84-software-composition-analysis-sca) * [9. Security Transparency](#9-security-transparency) * [10. Operational Security Controls](#10-operational-security-controls) * [10.1 Authentication](#101-authentication) @@ -45,9 +43,9 @@ This document defines the security guidelines for projects governed by the **NeoNephos Foundation**. It establishes requirements for vulnerability disclosure, incident response, supply chain security, and operational security controls that all NeoNephos projects must follow. -These guidelines complement the [NeoNephos Project Guidelines](../project-guidelines/project-guidelines.md), which reference this document in [Section 11 — Security](../project-guidelines/project-guidelines.md#11-security). Some operational security controls defined here overlap with [Section 15.3 — Security and Compliance](../project-guidelines/project-guidelines.md#153-security-and-compliance) of the Project Guidelines; this document provides the normative requirements while the Project Guidelines retain the operational context. +These guidelines complement the [NeoNephos Project Guidelines](../project-guidelines/project-guidelines.md), which reference this document in [Section 11 — Security](../project-guidelines/project-guidelines.md#11-security). Some operational security controls defined here overlap with [§15.3 — Security and Compliance](../project-guidelines/project-guidelines.md#153-security-and-compliance) of the Project Guidelines; this document provides the normative requirements while the Project Guidelines retain the operational context. -These guidelines build on established open source security standards — in particular the [OpenSSF Security Baseline](https://baseline.openssf.org/), [SLSA](https://slsa.dev/), and the [OpenSSF Best Practices Badge](https://www.bestpractices.dev/). Rather than duplicating those standards, this document defines NeoNephos-specific requirements (such as response SLAs and conformance tiers) and provides platform-specific guidance that generic standards cannot offer. Where a topic is fully covered by an external standard, this document states the requirement and references the authoritative source. +These guidelines build on established open source security standards — in particular the [OpenSSF Security Baseline](https://baseline.openssf.org/), [SLSA](https://slsa.dev/), and the [OpenSSF Best Practices Badge](https://www.bestpractices.dev/). This document adopts OpenSSF standards as the baseline and adds NeoNephos-specific requirements only where generic standards do not provide concrete guidance — such as severity-based response SLAs, platform-specific implementation paths, and a conformance model tied to foundation lifecycle stages. Where a topic is fully covered by an external standard, this document states the requirement and references the authoritative source. Related sections: [2 — Normative Language](#2-normative-language); [3 — Conformance Model](#3-conformance-model); [4 — Scope](#4-scope). @@ -75,6 +73,8 @@ This document covers: - **Supply chain security**: Requirements for signing, provenance, SBOMs, and dependency management of released artifacts. - **Operational security controls**: Authentication, CI/CD security, access governance, code scanning, and data retention requirements. +For the purposes of this document, a repository contains **publishable code or artifacts** if it produces software that is distributed to users or other systems — including libraries, binaries, container images, Helm charts, CLI tools, SDKs, or any package published to a registry. Repositories that contain only documentation, governance files, or meeting notes are excluded. + This document does **not** cover: - OpenSSF Best Practices Badge requirements — see [Project Lifecycle Policy](../lifecycle-policy/project-lifecycle-policy.md). @@ -153,13 +153,15 @@ Related sections: [6 — Vulnerability Response Process](#6-vulnerability-respon Each project's TSC **MUST** designate at least two maintainers as security contacts responsible for handling vulnerability reports. These contacts **MUST** be documented in the project's `SECURITY.md`. -### 6.1 Acknowledgement +### 6.1 Initial Response + +Projects **MUST** provide an initial response to a vulnerability report within **14 calendar days** of receiving it, in line with the [OpenSSF Best Practices](https://www.bestpractices.dev/) passing-level requirement. The response **MUST** be sent via the same channel the report was received on (e.g., GitHub Security Advisory, GitLab confidential issue, or encrypted email). -Projects **MUST** acknowledge receipt of a vulnerability report within **3 business days**. The acknowledgement **MUST** be sent via the same channel the report was received on (e.g., GitHub Security Advisory, GitLab confidential issue, or encrypted email). +Projects **SHOULD** acknowledge receipt within **2 business days** where maintainer availability permits. ### 6.2 Triage and Severity Assessment -Projects **MUST** perform an initial triage within **7 calendar days** of receiving a report. Triage **MUST** include: +The initial response **MUST** include — or be followed promptly by — a triage that covers: 1. Validation: confirming whether the report describes a genuine vulnerability. 2. Severity assessment using [CVSS v3.1](https://www.first.org/cvss/v3.1/specification-document) or later. @@ -169,7 +171,7 @@ The reporter **SHOULD** be informed of the triage outcome and the planned remedi ### 6.3 Fix Coordination -Fix development **SHOULD** happen in a private fork, draft advisory, or other non-public workspace to prevent premature disclosure. The fix **MUST** be reviewed by at least one additional maintainer before merging. +Fix development **SHOULD** happen in a private fork, draft advisory, or other non-public workspace to prevent premature disclosure (the **MUST** requirement in the Section 6 conformance table applies to designating security contacts and following the response process; the choice of private workspace is **RECOMMENDED**). The fix **MUST** be reviewed by at least one additional maintainer before merging. > **Platform-specific guidance:** On GitHub, use a [temporary private fork within a Security Advisory](https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/collaborating-in-a-temporary-private-fork-to-resolve-a-repository-security-vulnerability). On GitLab, use a [confidential merge request](https://docs.gitlab.com/ee/user/project/merge_requests/confidential.html). On other platforms, use a private branch or out-of-band patch review. @@ -233,6 +235,7 @@ Projects **MUST** classify vulnerabilities using [CVSS v3.1](https://www.first.o - **Fix SLA**: Time from triage completion to a fix being merged. - **Disclosure SLA**: Time from triage completion to publishing a security advisory (see [Section 6.5](#65-coordinated-disclosure)). The disclosure SLA **MUST NOT** exceed the 90-day embargo defined in [Section 6.5](#65-coordinated-disclosure). +- When the fix and disclosure SLAs coincide (as with Medium severity), the fix and disclosure **MAY** happen simultaneously. If the fix is not ready when the disclosure SLA expires, the TSC **MUST** publish a mitigation advisory and disclose per [Section 6.5](#65-coordinated-disclosure). If a project cannot meet a Fix SLA, the TSC **MUST** communicate an updated timeline to the reporter and publish a mitigation or workaround advisory. Transparent communication about delays is always preferable to silently missing a deadline. @@ -252,7 +255,7 @@ Related sections: [6 — Vulnerability Response Process](#6-vulnerability-respon Projects **SHOULD** sign all published release artifacts (container images, binaries, packages) using [Sigstore cosign](https://docs.sigstore.dev/cosign/signing/overview/) or an equivalent signing mechanism. Signing **SHOULD** be integrated into the CI/CD pipeline. -> **Practical note:** Artifact signing, build provenance, and SBOM generation (Sections 8.1–8.3) are intended to be adopted incrementally. Projects **SHOULD** prioritize dependency scanning ([Section 8.4](#84-dependency-scanning)) first, as it provides the highest security value with the least effort. The remaining supply chain practices can be introduced as the project matures and publishes artifacts to external consumers. +> **Practical note:** Artifact signing, build provenance, and SBOM generation (Sections 8.1–8.3) are intended to be adopted incrementally. Projects **SHOULD** prioritize software composition analysis ([Section 8.4](#84-software-composition-analysis-sca)) first, as it provides the highest security value with the least effort. The remaining supply chain practices can be introduced as the project matures and publishes artifacts to external consumers. ### 8.2 Build Provenance (SLSA) @@ -270,49 +273,34 @@ For implementation guidance and tooling options, see the [SLSA specification](ht |------------|----------------------------------------------|-------| | **SHOULD** | When publishing artifacts to external consumers | TSC | -Projects **SHOULD** generate a Software Bill of Materials (SBOM) for each published release artifact. SBOMs **MUST** use either [SPDX](https://spdx.dev/) or [CycloneDX](https://cyclonedx.org/) format. +Projects **SHOULD** generate a Software Bill of Materials (SBOM) for each published release artifact. When an SBOM is published, it **MUST** use either [SPDX](https://spdx.dev/) or [CycloneDX](https://cyclonedx.org/) format. SBOMs **SHOULD** be published alongside release artifacts (e.g., attached to GitHub releases or pushed to the OCI registry as a referrer). -### 8.4 Dependency Scanning +### 8.4 Software Composition Analysis (SCA) | Priority | Resolution | Owner | |----------|-----------------|-------| | **MUST** | ASAP (≤30 days) | TSC | -Projects **MUST** enable automated dependency scanning to detect known vulnerabilities in direct and transitive dependencies for all repositories containing publishable code. Examples of acceptable tools include [Dependabot](https://docs.github.com/en/code-security/dependabot), [Renovate](https://docs.renovatebot.com/), or equivalent. - -Projects **SHOULD** configure automated dependency update pull requests to reduce time-to-remediation. - -Related sections: [Project Guidelines §15.3.2 — Supplemental Compliance](../project-guidelines/project-guidelines.md#1532-supplemental-compliance); [Project Guidelines §6 — Technical and Development Practices](../project-guidelines/project-guidelines.md#6-technical-and-development-practices). - -### 8.5 Container Image Scanning - -| Priority | Resolution | Owner | -|------------|----------------------------------------------|-------| -| **SHOULD** | When publishing container images | TSC | - -Projects that publish container images **SHOULD** scan all images for known vulnerabilities before pushing them to a registry. Image scanning **SHOULD** be integrated into the CI/CD pipeline so that every built image is evaluated before publication. - -Projects **SHOULD** fail the pipeline (or at minimum generate a warning) when vulnerabilities at or above a project-defined severity threshold are detected. Projects **SHOULD** define this threshold explicitly (e.g., "Critical and High"). - -Examples of acceptable tools include [Trivy](https://github.com/aquasecurity/trivy), [Grype](https://github.com/anchore/grype), or [OSV-Scanner](https://google.github.io/osv-scanner/). See [OpenSSF Security Baseline](https://baseline.openssf.org/) controls `OSPS-VM-05.01` through `OSPS-VM-05.03` (Level 3) for additional guidance on SCA thresholds and policy evaluation. +Projects **MUST** enable automated software composition analysis (SCA) covering vulnerability detection, container image scanning, and license compliance for all repositories containing publishable code. Modern SCA tools — such as [Trivy](https://github.com/aquasecurity/trivy), [Grype](https://github.com/anchore/grype), [OSV-Scanner](https://google.github.io/osv-scanner/), [Dependabot](https://docs.github.com/en/code-security/dependabot), or [Renovate](https://docs.renovatebot.com/) — typically cover multiple of these concerns in a single scan. See [OpenSSF Security Baseline](https://baseline.openssf.org/) controls `OSPS-VM-05.01` through `OSPS-VM-05.03` (Level 3) and `OSPS-LE-02.01`, `OSPS-LE-02.02` (Level 1). -Related sections: [8.3 — Software Bill of Materials (SBOM)](#83-software-bill-of-materials-sbom); [8.4 — Dependency Scanning](#84-dependency-scanning). +**Dependency vulnerability scanning** (**MUST**) -### 8.6 License Compliance Scanning +- Projects **MUST** scan direct and transitive dependencies for known vulnerabilities. +- Projects **SHOULD** configure automated dependency update pull requests to reduce time-to-remediation. -| Priority | Resolution | Owner | -|------------|-----------------|-------| -| **SHOULD** | ASAP (≤90 days) | TSC | +**Container image scanning** (**SHOULD** — when publishing container images) -Projects **SHOULD** automate license scanning of all direct and transitive dependencies to detect incompatible, unknown, or unlicensed components. License scanning **SHOULD** be integrated into the CI/CD pipeline. +- Projects that publish container images **SHOULD** scan all images for known vulnerabilities before pushing them to a registry, integrated into the CI/CD pipeline. +- Projects **SHOULD** fail the pipeline (or at minimum generate a warning) when vulnerabilities at or above a project-defined severity threshold are detected (e.g., "Critical and High"). -Projects **SHOULD** define an allowlist of acceptable licenses (e.g., OSI-approved permissive licenses such as MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause) and flag any dependency whose license is not on the allowlist. Dependencies with incompatible or unknown licenses **SHOULD** be resolved before release. +**License compliance scanning** (**SHOULD**) -Examples of acceptable tools include [Trivy](https://github.com/aquasecurity/trivy), [REUSE](https://reuse.software/), or equivalent. See [OpenSSF Security Baseline](https://baseline.openssf.org/) controls `OSPS-LE-02.01`, `OSPS-LE-02.02` (Level 1) and `OSPS-VM-05.01`, `OSPS-VM-05.02` (Level 3) for alignment with broader license compliance requirements. +- Projects **SHOULD** automate license scanning of all direct and transitive dependencies to detect incompatible, unknown, or unlicensed components. +- Projects **SHOULD** define an allowlist of acceptable licenses (e.g., MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause) and flag any dependency whose license is not on the allowlist. Dependencies with incompatible or unknown licenses **SHOULD** be resolved before release. -Related sections: [8.4 — Dependency Scanning](#84-dependency-scanning); [8.5 — Container Image Scanning](#85-container-image-scanning). +Related sections: [8.3 — Software Bill of Materials (SBOM)](#83-software-bill-of-materials-sbom); [Project Guidelines §15.3.2 — Supplemental Compliance](../project-guidelines/project-guidelines.md#1532-supplemental-compliance). --- @@ -324,7 +312,7 @@ Related sections: [8.4 — Dependency Scanning](#84-dependency-scanning); [8.5 Projects **MUST** publish security advisories for all confirmed vulnerabilities with a CVSS score ≥ 4.0 via the platform's advisory mechanism. On GitHub, use [GitHub Security Advisories](https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/about-repository-security-advisories). On GitLab, use [project-level vulnerability records](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/). On other platforms, publish advisories on the project website or mailing list and link to them from `SECURITY.md`. -Projects **MUST** reference CVE identifiers and advisory links in the release notes of patched versions. +Projects **MUST** reference CVE identifiers and advisory links in the release notes of patched versions. If a CVE has not yet been assigned at the time of publication, the advisory **SHOULD** note that CVE assignment is pending and be updated once the identifier is issued. Release changelogs **SHOULD** explicitly flag security-relevant modifications (fixes, dependency updates addressing CVEs, configuration changes with security impact). See [OpenSSF Security Baseline](https://baseline.openssf.org/) control `OSPS-BR-04.01` (Level 2). @@ -346,7 +334,9 @@ This section defines security-relevant operational controls for NeoNephos projec Projects **MUST** enforce Two-Factor Authentication (2FA) for all organization members. -Projects **SHOULD** disable SSH deploy keys at the organization level. Deploy keys lack per-user accountability; personal or machine accounts with MFA are preferred. +Projects **SHOULD** disable SSH deploy keys at the organization level (strengthening the Project Guidelines' position, which does not enforce a global policy). Deploy keys lack per-user accountability; personal or machine accounts with MFA are preferred. + +Related sections: [Project Guidelines §15.3 — Security and Compliance](../project-guidelines/project-guidelines.md#153-security-and-compliance). ### 10.2 CI/CD Security @@ -354,6 +344,8 @@ Projects **SHOULD** disable SSH deploy keys at the organization level. Deploy ke |----------|-----------------|-------| | **MUST** | ASAP (≤30 days) | TSC | +*The priority above applies to the core CI/CD controls (self-hosted runners, fork workflows, workflow permissions). Sub-controls below carry their own conformance tables.* + **Self-hosted runners** - Repository-level self-hosted runners **MUST NOT** be enabled. @@ -403,6 +395,8 @@ Projects **SHOULD** disable SSH deploy keys at the organization level. Deploy ke > **Exemplary implementation:** The [Open Component Model CI workflows](https://github.com/open-component-model/open-component-model/tree/main/.github/workflows) demonstrate SHA-pinned actions, minimal `GITHUB_TOKEN` permissions with per-job escalation, and safe `pull_request_target` handling. +Related sections: [Project Guidelines §15.3 — Security and Compliance](../project-guidelines/project-guidelines.md#153-security-and-compliance); [8 — Supply Chain Security](#8-supply-chain-security). + ### 10.3 Branch Protection | Priority | Resolution | Owner | @@ -463,7 +457,7 @@ Projects **SHOULD** require that maintainer candidates: Projects **SHOULD** enable static application security testing (SAST) — such as [CodeQL](https://codeql.github.com/) or [SonarQube](https://www.sonarsource.com/products/sonarqube/) — to detect code-level vulnerabilities. Projects **SHOULD** define a severity threshold (e.g., "Critical and High") and gate the CI pipeline on it. See [OpenSSF Security Baseline](https://baseline.openssf.org/) controls `OSPS-VM-06.01` and `OSPS-VM-06.02` (Level 3). -For dependency-level vulnerability scanning, see [Section 8.4 — Dependency Scanning](#84-dependency-scanning). +For dependency-level vulnerability scanning, see [Section 8.4 — Software Composition Analysis](#84-software-composition-analysis-sca). ### 10.7 Data Retention @@ -471,8 +465,10 @@ For dependency-level vulnerability scanning, see [Section 8.4 — Dependency Sca |----------|-----------------|-------| | **MUST** | ASAP (≤30 days) | TSC | -- **Private repositories**: Artifact and log retention **MUST** be configured to 180 days. -- **Public repositories**: Retention defaults to 90 days (GitHub platform limitation). +- **Private repositories**: Artifact and log retention **MUST** be configured to at least 180 days. +- **Public repositories**: Artifact and log retention **SHOULD** be configured to at least 180 days. On platforms where the maximum is lower (e.g., GitHub limits public repositories to 90 days), projects **MUST** configure the platform maximum. + +Related sections: [Project Guidelines §15.3 — Security and Compliance](../project-guidelines/project-guidelines.md#153-security-and-compliance). ### 10.8 Security Assessment @@ -502,16 +498,12 @@ Projects **MAY** integrate Scorecard into their CI pipeline via the [Scorecard G > **Exemplary implementation:** The [Open Component Model Scorecard workflow](https://github.com/open-component-model/open-component-model/blob/main/.github/workflows/openssf-scorecard.yml) runs Scorecard with SARIF upload to the code-scanning dashboard. -Related sections: [8 — Supply Chain Security](#8-supply-chain-security); [8.4 — Dependency Scanning](#84-dependency-scanning); [10.2 — CI/CD Security](#102-cicd-security). +Related sections: [8 — Supply Chain Security](#8-supply-chain-security); [8.4 — Software Composition Analysis](#84-software-composition-analysis-sca); [10.2 — CI/CD Security](#102-cicd-security). --- ## 11. Acknowledgements -| Priority | Resolution | Owner | -|------------|-----------------|-------| -| **SHOULD** | ASAP (≤30 days) | TSC | - Projects **SHOULD** credit security researchers who responsibly report vulnerabilities, unless the reporter requests anonymity. Acknowledgement **SHOULD** be included in the published security advisory and **MAY** also be included in release notes. Related sections: [6.5 — Coordinated Disclosure](#65-coordinated-disclosure); [9 — Security Transparency](#9-security-transparency). diff --git a/templates/SECURITY.md b/templates/SECURITY.md index 91a63d1..c07ffcd 100644 --- a/templates/SECURITY.md +++ b/templates/SECURITY.md @@ -3,6 +3,9 @@ *This is a template for a SECURITY.md file. Adjust the placeholders (marked with `<...>`) to match your project. Remove this italic guidance text before publishing. For projects with multiple repositories, each repository containing publishable code or artifacts MUST have its own SECURITY.md. +On GitHub, a SECURITY.md placed in the organization's `.github` repository serves as the default for +all repositories that do not have their own — this satisfies the per-repository requirement, but +cannot include repository-specific direct links (see Option A below). See the [NeoNephos Security Guidelines](../security-guidelines/security-guidelines.md) for the full set of requirements.* @@ -50,11 +53,11 @@ You may report vulnerabilities via email to **\**. a link to the public key or a fingerprint. Projects SHOULD also publish a [`security.txt`](https://securitytxt.org/) file following [RFC 9116](https://www.rfc-editor.org/rfc/rfc9116).* -### Alternative Contact +### Fallback Contact -*If your project offers an additional private reporting channel beyond the primary one above -(e.g., email as fallback for a GitHub/GitLab-hosted project), list it here. -Otherwise, remove this section.* +*If your project uses Option A or Option B above as the primary channel, add an email fallback here +for reporters who do not have an account on the hosting platform. If you chose Option C as your +primary channel, remove this section to avoid duplication.* You may also report vulnerabilities via email to **\**. @@ -64,10 +67,12 @@ The following maintainers are responsible for handling vulnerability reports: | Name | Handle | Role | |------|--------|------| -| *\* | [@\](https://github.com/) | Security Officer | -| *\* | [@\](https://github.com/) | Maintainer | +| *\* | [@\](https://github.com/) | Lead Security Contact | +| *\* | [@\](https://github.com/) | Security Contact | -*Adjust the profile links to match your hosting platform.* +*The [NeoNephos Security Guidelines](../security-guidelines/security-guidelines.md#6-vulnerability-response-process) +require at least two security contacts. Add more rows as needed but do not reduce below two. +Adjust the profile links to match your hosting platform.* ## Supported Versions @@ -92,22 +97,21 @@ text before publishing. Examples:* This project follows the [NeoNephos Security Guidelines](../security-guidelines/security-guidelines.md) for vulnerability handling. In summary: -- **Acknowledgement**: We will acknowledge your report within **3 business days**. -- **Triage**: We will assess the severity (using [CVSS v3.1](https://www.first.org/cvss/v3.1/specification-document)) within **7 calendar days**. -- **Embargo**: Vulnerability details will remain confidential for up to **90 days** while a fix is developed. +- **Initial response**: We will respond to your report within **14 calendar days**, in line with the [OpenSSF Best Practices](https://www.bestpractices.dev/) requirement. +- **Embargo**: Vulnerability details will remain confidential for up to **90 days** while a fix is developed. Fix timelines (see table below) are measured from triage completion. - **Disclosure**: Once a fix is available, we will publish a security advisory with full details. ### Severity Response SLAs -| Severity | CVSS Score | Fix Target (calendar days) | -|----------|------------|----------------------------| -| Critical | 9.0 – 10.0 | ≤ 7 days | -| High | 7.0 – 8.9 | ≤ 30 days | -| Medium | 4.0 – 6.9 | ≤ 90 days | -| Low | 0.1 – 3.9 | Best effort | +| Severity | CVSS Score | Fix Target | Disclosure Target | +|----------|------------|------------|-------------------| +| Critical | 9.0 – 10.0 | ≤ 7 days | ≤ 14 days | +| High | 7.0 – 8.9 | ≤ 30 days | ≤ 30 days | +| Medium | 4.0 – 6.9 | ≤ 90 days | ≤ 90 days | +| Low | 0.1 – 3.9 | Best effort | Best effort | -*If your project cannot meet a target, communicate an updated timeline to the reporter and publish -a workaround or mitigation advisory. Transparency matters more than speed.* +*Timelines are in calendar days, measured from triage completion. For the full SLA definitions, see the +[NeoNephos Security Guidelines, Section 7](../security-guidelines/security-guidelines.md#7-severity-classification-and-response-slas).* ## Disclosure Policy From 7c60a718c9246a90206ace7f053ddd31b29fae53 Mon Sep 17 00:00:00 2001 From: Gerald Morrison Date: Mon, 20 Apr 2026 19:02:53 +0200 Subject: [PATCH 10/14] add link to openssf Vulnerability Disclosure Guide --- security-guidelines/security-guidelines.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/security-guidelines/security-guidelines.md b/security-guidelines/security-guidelines.md index f6fae5b..6d6189c 100644 --- a/security-guidelines/security-guidelines.md +++ b/security-guidelines/security-guidelines.md @@ -157,7 +157,7 @@ Each project's TSC **MUST** designate at least two maintainers as security conta Projects **MUST** provide an initial response to a vulnerability report within **14 calendar days** of receiving it, in line with the [OpenSSF Best Practices](https://www.bestpractices.dev/) passing-level requirement. The response **MUST** be sent via the same channel the report was received on (e.g., GitHub Security Advisory, GitLab confidential issue, or encrypted email). -Projects **SHOULD** acknowledge receipt within **2 business days** where maintainer availability permits. +Projects **SHOULD** acknowledge receipt within **2 business days** where maintainer availability permits, in line with the [OpenSSF Vulnerability Disclosure Guide](https://github.com/ossf/oss-vulnerability-guide/blob/main/maintainer-guide.md). ### 6.2 Triage and Severity Assessment From 16f80dd65e9fd8e126df28711467d92587b1857f Mon Sep 17 00:00:00 2001 From: Gerald Morrison Date: Tue, 21 Apr 2026 13:29:55 +0200 Subject: [PATCH 11/14] soften SLAs Signed-off-by: Gerald Morrison --- security-guidelines/security-guidelines.md | 64 ++++++++++++---------- templates/SECURITY.md | 10 ++-- 2 files changed, 39 insertions(+), 35 deletions(-) diff --git a/security-guidelines/security-guidelines.md b/security-guidelines/security-guidelines.md index 6d6189c..49f3b5d 100644 --- a/security-guidelines/security-guidelines.md +++ b/security-guidelines/security-guidelines.md @@ -19,7 +19,7 @@ * [6.4 CVE Assignment](#64-cve-assignment) * [6.5 Coordinated Disclosure](#65-coordinated-disclosure) * [6.6 Post-Disclosure](#66-post-disclosure) - * [7. Severity Classification and Response SLAs](#7-severity-classification-and-response-slas) + * [7. Severity Classification and Response Targets](#7-severity-classification-and-response-targets) * [8. Supply Chain Security](#8-supply-chain-security) * [8.1 Artifact Signing](#81-artifact-signing) * [8.2 Build Provenance (SLSA)](#82-build-provenance-slsa) @@ -45,7 +45,7 @@ This document defines the security guidelines for projects governed by the **Neo These guidelines complement the [NeoNephos Project Guidelines](../project-guidelines/project-guidelines.md), which reference this document in [Section 11 — Security](../project-guidelines/project-guidelines.md#11-security). Some operational security controls defined here overlap with [§15.3 — Security and Compliance](../project-guidelines/project-guidelines.md#153-security-and-compliance) of the Project Guidelines; this document provides the normative requirements while the Project Guidelines retain the operational context. -These guidelines build on established open source security standards — in particular the [OpenSSF Security Baseline](https://baseline.openssf.org/), [SLSA](https://slsa.dev/), and the [OpenSSF Best Practices Badge](https://www.bestpractices.dev/). This document adopts OpenSSF standards as the baseline and adds NeoNephos-specific requirements only where generic standards do not provide concrete guidance — such as severity-based response SLAs, platform-specific implementation paths, and a conformance model tied to foundation lifecycle stages. Where a topic is fully covered by an external standard, this document states the requirement and references the authoritative source. +These guidelines build on established open source security standards — in particular the [OpenSSF Security Baseline](https://baseline.openssf.org/), [SLSA](https://slsa.dev/), and the [OpenSSF Best Practices Badge](https://www.bestpractices.dev/). This document adopts OpenSSF standards as the baseline and adds NeoNephos-specific requirements only where generic standards do not provide concrete guidance — such as severity-based response targets, platform-specific implementation paths, and a conformance model tied to foundation lifecycle stages. Where a topic is fully covered by an external standard, this document states the requirement and references the authoritative source. Related sections: [2 — Normative Language](#2-normative-language); [3 — Conformance Model](#3-conformance-model); [4 — Scope](#4-scope). @@ -141,7 +141,7 @@ A template is available at [`../templates/SECURITY.md`](../templates/SECURITY.md > **Exemplary implementation:** [Gardener's SECURITY.md](https://github.com/gardener/.github/blob/main/SECURITY.md) includes named security contacts, a detailed disclosure process, and severity-based handling. -Related sections: [6 — Vulnerability Response Process](#6-vulnerability-response-process); [7 — Severity Classification and Response SLAs](#7-severity-classification-and-response-slas). +Related sections: [6 — Vulnerability Response Process](#6-vulnerability-response-process); [7 — Severity Classification and Response Targets](#7-severity-classification-and-response-targets). --- @@ -161,11 +161,11 @@ Projects **SHOULD** acknowledge receipt within **2 business days** where maintai ### 6.2 Triage and Severity Assessment -The initial response **MUST** include — or be followed promptly by — a triage that covers: +The initial response **SHOULD** include — or be followed promptly by — a triage that covers: 1. Validation: confirming whether the report describes a genuine vulnerability. -2. Severity assessment using [CVSS v3.1](https://www.first.org/cvss/v3.1/specification-document) or later. -3. Assignment of a severity level per [Section 7](#7-severity-classification-and-response-slas). +2. Severity assessment using [CVSS v3.1](https://www.first.org/cvss/v3.1/specification-document) or later, where practical. +3. Assignment of a severity level per [Section 7](#7-severity-classification-and-response-targets). The reporter **SHOULD** be informed of the triage outcome and the planned remediation timeline. @@ -214,32 +214,34 @@ After public disclosure: - The CVE and advisory **SHOULD** be referenced in the release notes of the patched version. - Projects **SHOULD** conduct a retrospective for Critical and High severity vulnerabilities to identify process improvements. -Related sections: [5 — Security Contact per Project](#5-security-contact-per-project); [7 — Severity Classification and Response SLAs](#7-severity-classification-and-response-slas); [9 — Security Transparency](#9-security-transparency). +Related sections: [5 — Security Contact per Project](#5-security-contact-per-project); [7 — Severity Classification and Response Targets](#7-severity-classification-and-response-targets); [9 — Security Transparency](#9-security-transparency). --- -## 7. Severity Classification and Response SLAs +## 7. Severity Classification and Response Targets | Priority | Resolution | Owner | |----------|-----------------|-------| | **MUST** | ASAP (≤30 days) | TSC | -Projects **MUST** classify vulnerabilities using [CVSS v3.1](https://www.first.org/cvss/v3.1/specification-document) or later and apply the following response SLAs: +Projects **MUST** classify vulnerabilities using [CVSS v3.1](https://www.first.org/cvss/v3.1/specification-document) or later. Maintainers **MAY** exercise judgment when the CVSS score does not fully reflect the practical impact of a vulnerability. -| Severity | CVSS Score | Fix SLA | Disclosure SLA | +Projects **MUST** publish a security advisory within the 90-day disclosure ceiling defined in [Section 6.5](#65-coordinated-disclosure). Within that ceiling, projects **SHOULD** aim for the following response targets: + +| Severity | CVSS Score | Fix Target | Disclosure Target | |--------------|------------|------------------------|------------------------| -| **Critical** | 9.0 – 10.0 | ≤ 7 calendar days | ≤ 14 calendar days | -| **High** | 7.0 – 8.9 | ≤ 30 calendar days | ≤ 30 calendar days | +| **Critical** | 9.0 – 10.0 | ≤ 14 calendar days | ≤ 30 calendar days | +| **High** | 7.0 – 8.9 | ≤ 30 calendar days | ≤ 60 calendar days | | **Medium** | 4.0 – 6.9 | ≤ 90 calendar days | ≤ 90 calendar days | | **Low** | 0.1 – 3.9 | Best effort | Best effort | -- **Fix SLA**: Time from triage completion to a fix being merged. -- **Disclosure SLA**: Time from triage completion to publishing a security advisory (see [Section 6.5](#65-coordinated-disclosure)). The disclosure SLA **MUST NOT** exceed the 90-day embargo defined in [Section 6.5](#65-coordinated-disclosure). -- When the fix and disclosure SLAs coincide (as with Medium severity), the fix and disclosure **MAY** happen simultaneously. If the fix is not ready when the disclosure SLA expires, the TSC **MUST** publish a mitigation advisory and disclose per [Section 6.5](#65-coordinated-disclosure). +- **Fix Target**: Time from triage completion to a fix being merged. +- **Disclosure Target**: Time from triage completion to publishing a security advisory (see [Section 6.5](#65-coordinated-disclosure)). The disclosure **MUST NOT** exceed the 90-day embargo defined in [Section 6.5](#65-coordinated-disclosure). +- When the fix and disclosure targets coincide (as with Medium severity), the fix and disclosure **MAY** happen simultaneously. If the fix is not ready when the disclosure target expires, the TSC **SHOULD** publish a mitigation advisory and disclose per [Section 6.5](#65-coordinated-disclosure). -If a project cannot meet a Fix SLA, the TSC **MUST** communicate an updated timeline to the reporter and publish a mitigation or workaround advisory. Transparent communication about delays is always preferable to silently missing a deadline. +If a project cannot meet a fix target, the TSC **SHOULD** communicate an updated timeline to the reporter and publish a mitigation or workaround advisory. Transparent communication about delays is always preferable to silently missing a deadline. -> **Rationale:** These SLAs are aligned with industry practice. The 90-day embargo follows the [OpenSSF Model Outbound Vulnerability Disclosure Policy](https://github.com/ossf/oss-vulnerability-guide/blob/main/maintainer-guide.md) and is consistent with CNCF projects such as Envoy. The severity-based fix timelines are comparable to those used by GitLab and Chainguard, adjusted from "patch availability" to "triage completion" to reflect the realities of volunteer-maintained open source projects. +> **Rationale:** The 90-day disclosure ceiling is a **MUST** aligned with the [OpenSSF Model Outbound Vulnerability Disclosure Policy](https://github.com/ossf/oss-vulnerability-guide/blob/main/maintainer-guide.md), Google Project Zero, and CNCF projects such as Envoy. The severity-based fix targets are **SHOULD**-level goals — no major open source foundation (including CNCF) mandates hard, severity-tiered fix SLAs, and volunteer-maintained projects cannot guarantee timelines the way commercial vendors can. The targets are comparable to those used by GitLab and Chainguard and provide a reasonable benchmark for projects to measure against. Related sections: [6 — Vulnerability Response Process](#6-vulnerability-response-process); [6.5 — Coordinated Disclosure](#65-coordinated-disclosure). @@ -283,7 +285,9 @@ SBOMs **SHOULD** be published alongside release artifacts (e.g., attached to Git |----------|-----------------|-------| | **MUST** | ASAP (≤30 days) | TSC | -Projects **MUST** enable automated software composition analysis (SCA) covering vulnerability detection, container image scanning, and license compliance for all repositories containing publishable code. Modern SCA tools — such as [Trivy](https://github.com/aquasecurity/trivy), [Grype](https://github.com/anchore/grype), [OSV-Scanner](https://google.github.io/osv-scanner/), [Dependabot](https://docs.github.com/en/code-security/dependabot), or [Renovate](https://docs.renovatebot.com/) — typically cover multiple of these concerns in a single scan. See [OpenSSF Security Baseline](https://baseline.openssf.org/) controls `OSPS-VM-05.01` through `OSPS-VM-05.03` (Level 3) and `OSPS-LE-02.01`, `OSPS-LE-02.02` (Level 1). +*The priority above applies to dependency vulnerability scanning. Container image scanning and license compliance scanning carry their own conformance levels below.* + +Projects **SHOULD** enable automated software composition analysis (SCA) covering vulnerability detection, container image scanning, and license compliance for all repositories containing publishable code. Modern SCA tools — such as [Trivy](https://github.com/aquasecurity/trivy), [Grype](https://github.com/anchore/grype), [OSV-Scanner](https://google.github.io/osv-scanner/), [Dependabot](https://docs.github.com/en/code-security/dependabot), or [Renovate](https://docs.renovatebot.com/) — typically cover multiple of these concerns in a single scan. See [OpenSSF Security Baseline](https://baseline.openssf.org/) controls `OSPS-VM-05.01` through `OSPS-VM-05.03` (Level 3) and `OSPS-LE-02.01`, `OSPS-LE-02.02` (Level 1). **Dependency vulnerability scanning** (**MUST**) @@ -344,13 +348,13 @@ Related sections: [Project Guidelines §15.3 — Security and Compliance](../pro |----------|-----------------|-------| | **MUST** | ASAP (≤30 days) | TSC | -*The priority above applies to the core CI/CD controls (self-hosted runners, fork workflows, workflow permissions). Sub-controls below carry their own conformance tables.* +*The priority above applies to the core CI/CD controls (fork workflows, workflow permissions). Sub-controls below carry their own conformance levels.* **Self-hosted runners** -- Repository-level self-hosted runners **MUST NOT** be enabled. -- Organization-level self-hosted runners **SHOULD NOT** be enabled unless necessary, and **MUST** be approved by GitHub Enterprise Cloud account administrators who record the decision via a TAC vote. -- *Rationale*: GitHub-hosted runners are preferred; self-hosted runners require careful hardening to prevent exploitation. +- Repository-level self-hosted runners **SHOULD NOT** be enabled. Organization-level policies **SHOULD** be used to prevent repositories from registering their own runners. +- Organization-level self-hosted runners **SHOULD NOT** be enabled unless necessary, and **SHOULD** be approved by GitHub Enterprise Cloud account administrators who record the decision via a TAC vote. +- *Rationale*: GitHub-hosted runners are preferred; self-hosted runners require careful hardening to prevent exploitation. Centralizing runner management at the organization level improves governance and auditability. **Fork pull-request workflows** @@ -360,8 +364,8 @@ Related sections: [Project Guidelines §15.3 — Security and Compliance](../pro **Workflow permissions** - The default `GITHUB_TOKEN` permission **MUST** be set to "Read repository contents and packages." -- Write access **MUST** be explicitly requested via the `permissions` key in workflow files. -- *Rationale*: Limits blast radius by preventing workflows from gaining unnecessary write access. +- Write access **SHOULD** be explicitly requested via the `permissions` key in workflow files. +- *Rationale*: Limits blast radius by preventing workflows from gaining unnecessary write access. See [OpenSSF Security Baseline](https://baseline.openssf.org/) control `OSPS-AC-04.01` (Level 2) for default permissions and `OSPS-AC-04.02` (Level 3) for per-job scoping. **Credential handling** @@ -371,7 +375,7 @@ Related sections: [Project Guidelines §15.3 — Security and Compliance](../pro - Projects **SHOULD** use workload identities (OIDC) or short-lived GitHub access tokens for interactions with external services. - Where workload identity is not supported, projects **SHOULD** use fine-grained personal access tokens with the minimum required scopes. -- Temporary access tokens created for exceptional local batch jobs **MUST** be deleted immediately after use and **MUST NOT** exceed a lifetime of 6 hours. +- Temporary access tokens created for exceptional local batch jobs **MUST** be deleted immediately after use and **SHOULD NOT** exceed a short lifetime (e.g., 6 hours). - Projects **SHOULD** conduct package releases via CI/CD pipelines (GitHub Actions recommended) rather than from local machines. See also [Section 8.1 — Artifact Signing](#81-artifact-signing) and [Section 8.2 — Build Provenance](#82-build-provenance-slsa). **Pipeline input sanitization** @@ -461,12 +465,12 @@ For dependency-level vulnerability scanning, see [Section 8.4 — Software Compo ### 10.7 Data Retention -| Priority | Resolution | Owner | -|----------|-----------------|-------| -| **MUST** | ASAP (≤30 days) | TSC | +| Priority | Resolution | Owner | +|------------|-----------------|-------| +| **SHOULD** | ASAP (≤90 days) | TSC | -- **Private repositories**: Artifact and log retention **MUST** be configured to at least 180 days. -- **Public repositories**: Artifact and log retention **SHOULD** be configured to at least 180 days. On platforms where the maximum is lower (e.g., GitHub limits public repositories to 90 days), projects **MUST** configure the platform maximum. +- **Private repositories**: Artifact and log retention **SHOULD** be configured to at least 180 days. +- **Public repositories**: Artifact and log retention **SHOULD** be configured to at least 180 days. On platforms where the maximum is lower (e.g., GitHub limits public repositories to 90 days), projects **SHOULD** configure the platform maximum. Related sections: [Project Guidelines §15.3 — Security and Compliance](../project-guidelines/project-guidelines.md#153-security-and-compliance). diff --git a/templates/SECURITY.md b/templates/SECURITY.md index c07ffcd..e070154 100644 --- a/templates/SECURITY.md +++ b/templates/SECURITY.md @@ -101,17 +101,17 @@ This project follows the [NeoNephos Security Guidelines](../security-guidelines/ - **Embargo**: Vulnerability details will remain confidential for up to **90 days** while a fix is developed. Fix timelines (see table below) are measured from triage completion. - **Disclosure**: Once a fix is available, we will publish a security advisory with full details. -### Severity Response SLAs +### Severity Response Targets | Severity | CVSS Score | Fix Target | Disclosure Target | |----------|------------|------------|-------------------| -| Critical | 9.0 – 10.0 | ≤ 7 days | ≤ 14 days | -| High | 7.0 – 8.9 | ≤ 30 days | ≤ 30 days | +| Critical | 9.0 – 10.0 | ≤ 14 days | ≤ 30 days | +| High | 7.0 – 8.9 | ≤ 30 days | ≤ 60 days | | Medium | 4.0 – 6.9 | ≤ 90 days | ≤ 90 days | | Low | 0.1 – 3.9 | Best effort | Best effort | -*Timelines are in calendar days, measured from triage completion. For the full SLA definitions, see the -[NeoNephos Security Guidelines, Section 7](../security-guidelines/security-guidelines.md#7-severity-classification-and-response-slas).* +*Timelines are in calendar days, measured from triage completion. For the full response target definitions, see the +[NeoNephos Security Guidelines, Section 7](../security-guidelines/security-guidelines.md#7-severity-classification-and-response-targets).* ## Disclosure Policy From aa3ed568bf63384ccdfc7150c81dd93e9790d013 Mon Sep 17 00:00:00 2001 From: Gerald Morrison Date: Thu, 23 Apr 2026 12:26:54 +0200 Subject: [PATCH 12/14] docs: condense security guidelines from 513 to 300 lines Major restructuring to make the guidelines actionable and easy to adopt: - Add Quick-Start Checklist (Section 4) with deep-links to exact MUSTs - Go platform-agnostic: remove GitHub/GitLab/Other subsections, defer to SECURITY.md template for platform-specific setup - Merge Conformance Model into Introduction, Security Transparency into Vulnerability Response Process (Section 6) - Drop Data Retention section (no OpenSSF precedent) - Replace 13 inline conformance tables with single Conformance Matrix - Add 60-day dependency remediation SLA (OpenSSF Best Practices) - Add explicit low-severity (<4.0) informal tracking clause - Soften maintainer vetting from fixed "6 months" to "sustained history" - Drop fixed ">=2 security contacts" requirement (delegate to project) - Remove all "Related sections" footers, "Exemplary implementation" callouts, and "Practical note" boxes - Update SECURITY.md template: add link-adjustment note, default "Past Security Advisories" to present Signed-off-by: Gerald Morrison --- security-guidelines/security-guidelines.md | 427 ++++++--------------- templates/SECURITY.md | 31 +- 2 files changed, 122 insertions(+), 336 deletions(-) diff --git a/security-guidelines/security-guidelines.md b/security-guidelines/security-guidelines.md index 49f3b5d..f420935 100644 --- a/security-guidelines/security-guidelines.md +++ b/security-guidelines/security-guidelines.md @@ -4,13 +4,10 @@ * [Security Guidelines — NeoNephos Foundation](#security-guidelines--neonephos-foundation) * [1. Introduction](#1-introduction) * [2. Normative Language](#2-normative-language) - * [3. Conformance Model](#3-conformance-model) - * [4. Scope](#4-scope) + * [3. Scope](#3-scope) + * [4. Quick-Start Checklist](#4-quick-start-checklist) * [5. Security Contact per Project](#5-security-contact-per-project) * [5.1 Private Vulnerability Intake Channel](#51-private-vulnerability-intake-channel) - * [5.1.1 GitHub](#511-github) - * [5.1.2 GitLab](#512-gitlab) - * [5.1.3 Other Platforms and Self-Hosted Setups](#513-other-platforms-and-self-hosted-setups) * [5.2 SECURITY.md](#52-securitymd) * [6. Vulnerability Response Process](#6-vulnerability-response-process) * [6.1 Initial Response](#61-initial-response) @@ -25,17 +22,15 @@ * [8.2 Build Provenance (SLSA)](#82-build-provenance-slsa) * [8.3 Software Bill of Materials (SBOM)](#83-software-bill-of-materials-sbom) * [8.4 Software Composition Analysis (SCA)](#84-software-composition-analysis-sca) - * [9. Security Transparency](#9-security-transparency) - * [10. Operational Security Controls](#10-operational-security-controls) - * [10.1 Authentication](#101-authentication) - * [10.2 CI/CD Security](#102-cicd-security) - * [10.3 Branch Protection](#103-branch-protection) - * [10.4 Secret Scanning and Prevention](#104-secret-scanning-and-prevention) - * [10.5 Access Governance](#105-access-governance) - * [10.6 Code Quality and Scanning](#106-code-quality-and-scanning) - * [10.7 Data Retention](#107-data-retention) - * [10.8 Security Assessment](#108-security-assessment) - * [10.9 Automated Security Posture Verification](#109-automated-security-posture-verification) + * [9. Operational Security Controls](#9-operational-security-controls) + * [9.1 Authentication](#91-authentication) + * [9.2 CI/CD Security](#92-cicd-security) + * [9.3 Branch Protection](#93-branch-protection) + * [9.4 Secret Scanning](#94-secret-scanning) + * [9.5 Access Governance](#95-access-governance) + * [9.6 Code Quality and Scanning](#96-code-quality-and-scanning) + * [9.7 Security Assessment and Posture Verification](#97-security-assessment-and-posture-verification) + * [10. Conformance Matrix](#10-conformance-matrix) * [11. Acknowledgements](#11-acknowledgements) @@ -43,11 +38,9 @@ This document defines the security guidelines for projects governed by the **NeoNephos Foundation**. It establishes requirements for vulnerability disclosure, incident response, supply chain security, and operational security controls that all NeoNephos projects must follow. -These guidelines complement the [NeoNephos Project Guidelines](../project-guidelines/project-guidelines.md), which reference this document in [Section 11 — Security](../project-guidelines/project-guidelines.md#11-security). Some operational security controls defined here overlap with [§15.3 — Security and Compliance](../project-guidelines/project-guidelines.md#153-security-and-compliance) of the Project Guidelines; this document provides the normative requirements while the Project Guidelines retain the operational context. +These guidelines complement the [NeoNephos Project Guidelines](../project-guidelines/project-guidelines.md), which reference this document in [Section 11 — Security](../project-guidelines/project-guidelines.md#11-security). They build on the [OpenSSF Security Baseline](https://baseline.openssf.org/), [SLSA](https://slsa.dev/), and the [OpenSSF Best Practices Badge](https://www.bestpractices.dev/), adding NeoNephos-specific requirements only where generic standards do not provide concrete guidance. -These guidelines build on established open source security standards — in particular the [OpenSSF Security Baseline](https://baseline.openssf.org/), [SLSA](https://slsa.dev/), and the [OpenSSF Best Practices Badge](https://www.bestpractices.dev/). This document adopts OpenSSF standards as the baseline and adds NeoNephos-specific requirements only where generic standards do not provide concrete guidance — such as severity-based response targets, platform-specific implementation paths, and a conformance model tied to foundation lifecycle stages. Where a topic is fully covered by an external standard, this document states the requirement and references the authoritative source. - -Related sections: [2 — Normative Language](#2-normative-language); [3 — Conformance Model](#3-conformance-model); [4 — Scope](#4-scope). +Each requirement carries a conformance priority (**MUST**/**SHOULD** per RFC 2119) and a resolution timeframe; see the [Conformance Matrix](#10-conformance-matrix). Enforcement follows [Project Guidelines §13a](../project-guidelines/project-guidelines.md#13a-enforcement-and-remediation). --- @@ -55,32 +48,36 @@ Related sections: [2 — Normative Language](#2-normative-language); [3 — Conf The key words **MUST**, **MUST NOT**, **REQUIRED**, **SHALL**, **SHALL NOT**, **SHOULD**, **SHOULD NOT**, **RECOMMENDED**, **MAY**, and **OPTIONAL** in this document are to be interpreted as described in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119.html) and [RFC 8174](https://www.rfc-editor.org/rfc/rfc8174.html). -Related sections: [3 — Conformance Model](#3-conformance-model). - --- -## 3. Conformance Model - -This document follows the same conformance model defined in the [NeoNephos Project Guidelines, Section 3](../project-guidelines/project-guidelines.md#3-conformance-model). Each guideline carries a *conformance priority statement* and a *resolution timeframe*. Enforcement follows the process described in [Section 13a — Enforcement and Remediation](../project-guidelines/project-guidelines.md#13a-enforcement-and-remediation) of the Project Guidelines. - ---- - -## 4. Scope +## 3. Scope This document covers: - **Vulnerability disclosure and response**: How projects receive, handle, and disclose security vulnerabilities. - **Supply chain security**: Requirements for signing, provenance, SBOMs, and dependency management of released artifacts. -- **Operational security controls**: Authentication, CI/CD security, access governance, code scanning, and data retention requirements. +- **Operational security controls**: Authentication, CI/CD security, access governance, and code scanning requirements. For the purposes of this document, a repository contains **publishable code or artifacts** if it produces software that is distributed to users or other systems — including libraries, binaries, container images, Helm charts, CLI tools, SDKs, or any package published to a registry. Repositories that contain only documentation, governance files, or meeting notes are excluded. -This document does **not** cover: +--- -- OpenSSF Best Practices Badge requirements — see [Project Lifecycle Policy](../lifecycle-policy/project-lifecycle-policy.md). -- Governance, maintainer access, and operational policies — see [Project Guidelines](../project-guidelines/project-guidelines.md). +## 4. Quick-Start Checklist -Where applicable, individual sections reference the corresponding controls from the [OpenSSF Security Baseline (OSPS)](https://baseline.openssf.org/) to help projects map these guidelines to the broader open source security ecosystem. +Every project with publishable code or artifacts **MUST** complete these items. Details in linked sections. + +1. Designate security contacts and document in SECURITY.md ([Section 5.2](#52-securitymd), [Section 6](#6-vulnerability-response-process)) +2. Enable private vulnerability reporting ([Section 5.1](#51-private-vulnerability-intake-channel)) +3. Publish a SECURITY.md in every repository ([Section 5.2](#52-securitymd)) +4. Respond to vulnerability reports within 14 calendar days ([Section 6.1](#61-initial-response)) +5. Follow coordinated disclosure with 90-day embargo ceiling ([Section 6.5](#65-coordinated-disclosure)) +6. Classify vulnerabilities using CVSS v3.1+ ([Section 7](#7-severity-classification-and-response-targets)) +7. Scan dependencies for known vulnerabilities ([Section 8.4](#84-software-composition-analysis-sca)) +8. Enforce 2FA for all organization members ([Section 9.1](#91-authentication)) +9. Enable branch protection on primary branch ([Section 9.3](#93-branch-protection)) +10. Enable secret scanning and push protection ([Section 9.4](#94-secret-scanning)) +11. Require approval for first-time contributor CI workflows ([Section 9.2](#92-cicd-security)) +12. Set default GITHUB_TOKEN to read-only ([Section 9.2](#92-cicd-security)) --- @@ -88,111 +85,58 @@ Where applicable, individual sections reference the corresponding controls from ### 5.1 Private Vulnerability Intake Channel -| Priority | Resolution | Owner | -|----------|-----------------|-------| -| **MUST** | ASAP (≤30 days) | TSC | - -Projects **MUST** provide a private channel through which external reporters can submit vulnerability reports confidentially. The specific mechanism depends on the hosting platform, but **MUST** ensure that: +Projects **MUST** provide a private channel through which external reporters can submit vulnerability reports confidentially. The channel **MUST** ensure that: -1. Reports are visible only to designated security contacts (see [Section 6](#6-vulnerability-response-process)) and **MUST NOT** be publicly accessible. +1. Reports are visible only to designated security contacts and **MUST NOT** be publicly accessible. 2. The channel is documented in the project's `SECURITY.md` (see [Section 5.2](#52-securitymd)). 3. Reporters receive a confirmation that their report has been received. -The following subsections define platform-specific requirements. - -#### 5.1.1 GitHub - -Projects hosted on **GitHub** **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 preferred intake channel for GitHub-hosted projects. - -Projects **SHOULD** enable Private Vulnerability Reporting at the organization level to ensure newly created repositories inherit this setting. - -#### 5.1.2 GitLab - -Projects hosted on **GitLab** **MUST** accept vulnerability reports via [confidential issues](https://docs.gitlab.com/ee/user/project/issues/confidential_issues.html). The `SECURITY.md` **MUST** instruct reporters to mark issues as confidential when submitting vulnerability reports. - -Projects **SHOULD** configure an [issue template](https://docs.gitlab.com/ee/user/project/description_templates.html) named "Security Vulnerability" that pre-selects the confidentiality checkbox and provides a structured reporting form. - -#### 5.1.3 Other Platforms and Self-Hosted Setups - -Projects that are **not** hosted on GitHub or GitLab (e.g., self-hosted Gitea, Forgejo, Bitbucket, or other platforms) **MUST** provide at least one of the following private intake channels: - -1. **Encrypted email**: A dedicated security contact email address published in `SECURITY.md` and in a [`security.txt`](https://securitytxt.org/) file following [RFC 9116](https://www.rfc-editor.org/rfc/rfc9116). The project **SHOULD** publish a PGP/GPG public key to enable encrypted communication. -2. **Platform-native private reporting**: If the hosting platform offers a built-in confidential issue or vulnerability reporting mechanism, the project **MUST** enable and use it. - -Projects **SHOULD** additionally publish a `/.well-known/security.txt` file on any project website, conforming to [RFC 9116](https://www.rfc-editor.org/rfc/rfc9116), with at minimum the `Contact` and `Expires` fields. - -> **Practical note:** Regardless of platform, projects **SHOULD** provide an email address or alternative private channel in `SECURITY.md` as a fallback for reporters who do not have an account on the project's hosting platform. +Projects **SHOULD** additionally provide an email address or alternative private channel as a fallback for reporters who do not have an account on the project's hosting platform. See the [SECURITY.md template](../templates/SECURITY.md) for platform-specific setup. ### 5.2 SECURITY.md -| Priority | Resolution | Owner | -|----------|-----------------|-------| -| **MUST** | ASAP (≤30 days) | TSC | - Projects **MUST** provide a `SECURITY.md` file in every repository that contains publishable code or artifacts. The `SECURITY.md` **MUST** include at minimum: 1. Instructions for reporting a vulnerability via the project's private intake channel (see [Section 5.1](#51-private-vulnerability-intake-channel)), including a direct link where applicable. -2. A version support policy stating which releases receive security updates (e.g., "the latest two minor releases" or a version table). +2. A version support policy stating which releases receive security updates. 3. The expected response timeline (referencing [Section 6](#6-vulnerability-response-process) of this document). -Projects **SHOULD** additionally provide an email address or alternative private channel for reporters who do not have an account on the project's hosting platform. - A template is available at [`../templates/SECURITY.md`](../templates/SECURITY.md). -> **Exemplary implementation:** [Gardener's SECURITY.md](https://github.com/gardener/.github/blob/main/SECURITY.md) includes named security contacts, a detailed disclosure process, and severity-based handling. - -Related sections: [6 — Vulnerability Response Process](#6-vulnerability-response-process); [7 — Severity Classification and Response Targets](#7-severity-classification-and-response-targets). - --- ## 6. Vulnerability Response Process -| Priority | Resolution | Owner | -|----------|-----------------|-------| -| **MUST** | ASAP (≤30 days) | TSC | - -Each project's TSC **MUST** designate at least two maintainers as security contacts responsible for handling vulnerability reports. These contacts **MUST** be documented in the project's `SECURITY.md`. +Each project's TSC **MUST** designate security contacts responsible for handling vulnerability reports. These contacts **MUST** be documented in the project's `SECURITY.md`. ### 6.1 Initial Response -Projects **MUST** provide an initial response to a vulnerability report within **14 calendar days** of receiving it, in line with the [OpenSSF Best Practices](https://www.bestpractices.dev/) passing-level requirement. The response **MUST** be sent via the same channel the report was received on (e.g., GitHub Security Advisory, GitLab confidential issue, or encrypted email). - -Projects **SHOULD** acknowledge receipt within **2 business days** where maintainer availability permits, in line with the [OpenSSF Vulnerability Disclosure Guide](https://github.com/ossf/oss-vulnerability-guide/blob/main/maintainer-guide.md). +Projects **MUST** provide an initial response to a vulnerability report within **14 calendar days** of receiving it. Projects **SHOULD** acknowledge receipt within **2 business days** where maintainer availability permits. ### 6.2 Triage and Severity Assessment The initial response **SHOULD** include — or be followed promptly by — a triage that covers: 1. Validation: confirming whether the report describes a genuine vulnerability. -2. Severity assessment using [CVSS v3.1](https://www.first.org/cvss/v3.1/specification-document) or later, where practical. +2. Severity assessment using [CVSS v3.1](https://www.first.org/cvss/v3.1/specification-document) or later. 3. Assignment of a severity level per [Section 7](#7-severity-classification-and-response-targets). The reporter **SHOULD** be informed of the triage outcome and the planned remediation timeline. ### 6.3 Fix Coordination -Fix development **SHOULD** happen in a private fork, draft advisory, or other non-public workspace to prevent premature disclosure (the **MUST** requirement in the Section 6 conformance table applies to designating security contacts and following the response process; the choice of private workspace is **RECOMMENDED**). The fix **MUST** be reviewed by at least one additional maintainer before merging. - -> **Platform-specific guidance:** On GitHub, use a [temporary private fork within a Security Advisory](https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/collaborating-in-a-temporary-private-fork-to-resolve-a-repository-security-vulnerability). On GitLab, use a [confidential merge request](https://docs.gitlab.com/ee/user/project/merge_requests/confidential.html). On other platforms, use a private branch or out-of-band patch review. +Fix development **SHOULD** happen in a non-public workspace. The fix **MUST** be reviewed by at least one additional maintainer before merging. If the vulnerability affects multiple NeoNephos projects, the reporting project's TSC **SHOULD** coordinate with the affected projects' TSCs before disclosure. The TAC **MAY** facilitate cross-project coordination. ### 6.4 CVE Assignment -| Priority | Resolution | Owner | -|------------|-----------------|-------| -| **SHOULD** | ASAP (≤30 days) | TSC | +Projects **SHOULD** request a CVE identifier for confirmed vulnerabilities with a CVSS score ≥ 4.0 (Medium or higher). -Projects **SHOULD** request a CVE identifier for confirmed vulnerabilities with a CVSS score ≥ 4.0 (Medium or higher). Projects hosted on GitHub **SHOULD** obtain CVE identifiers via [GitHub's CNA program](https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/publishing-a-repository-security-advisory#requesting-a-cve-identification-number). Projects on other platforms **MAY** request CVEs through [MITRE's CVE Request form](https://cveform.mitre.org/) or another authorized CNA. - -> **Practical note:** CVE assignment adds credibility and traceability but involves administrative overhead. Early-stage projects or projects with a small user base **MAY** defer CVE assignment until a stable release has been published and external adoption is established. A platform security advisory alone already provides adequate transparency for most cases. +Vulnerabilities scoring below 4.0 (Low) **MAY** be tracked informally and do not require a CVE or public advisory. ### 6.5 Coordinated Disclosure -| Priority | Resolution | Owner | -|----------|-----------------|-------| -| **MUST** | ASAP (≤30 days) | TSC | - Projects **MUST** follow a coordinated disclosure process: 1. **Embargo period**: The maximum embargo duration is **90 calendar days** from the date the report is acknowledged. During this period, details of the vulnerability **MUST NOT** be disclosed publicly. @@ -202,29 +146,21 @@ Projects **MUST** follow a coordinated disclosure process: - The CVSS score and vector. - The CVE identifier (if assigned). - Remediation steps or patched versions. - - On GitHub, use [GitHub Security Advisories](https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/publishing-a-repository-security-advisory). On GitLab, use a [project-level vulnerability record](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/). On other platforms, publish the advisory on the project website or mailing list and link to it from `SECURITY.md`. -3. **Early disclosure**: If active exploitation is detected in the wild, the TSC **MAY** shorten the embargo period and disclose early with whatever fix or mitigation is available. +3. **Advisory publication**: Projects **MUST** publish advisories for all confirmed vulnerabilities with a CVSS score ≥ 4.0 via the platform's advisory mechanism. +4. **Release notes**: Projects **MUST** reference CVE identifiers and advisory links in the release notes of patched versions. +5. **Changelogs**: Release changelogs **SHOULD** explicitly flag security-relevant modifications (fixes, dependency updates addressing CVEs, configuration changes with security impact). +6. **Advisory history**: Projects **SHOULD** maintain a public record of past security advisories accessible from the project's `SECURITY.md`. +7. **Early disclosure**: If active exploitation is detected in the wild, the TSC **MAY** shorten the embargo period and disclose early with whatever fix or mitigation is available. ### 6.6 Post-Disclosure -After public disclosure: - -- The fix **MUST** be released in a patch version for all supported release branches. -- The CVE and advisory **SHOULD** be referenced in the release notes of the patched version. -- Projects **SHOULD** conduct a retrospective for Critical and High severity vulnerabilities to identify process improvements. - -Related sections: [5 — Security Contact per Project](#5-security-contact-per-project); [7 — Severity Classification and Response Targets](#7-severity-classification-and-response-targets); [9 — Security Transparency](#9-security-transparency). +The fix **MUST** be released in a patch version for all supported release branches. The CVE and advisory **SHOULD** be referenced in the release notes of the patched version. --- ## 7. Severity Classification and Response Targets -| Priority | Resolution | Owner | -|----------|-----------------|-------| -| **MUST** | ASAP (≤30 days) | TSC | - -Projects **MUST** classify vulnerabilities using [CVSS v3.1](https://www.first.org/cvss/v3.1/specification-document) or later. Maintainers **MAY** exercise judgment when the CVSS score does not fully reflect the practical impact of a vulnerability. +Projects **MUST** classify vulnerabilities using [CVSS v3.1](https://www.first.org/cvss/v3.1/specification-document) or later. Maintainers **MAY** exercise judgment when the CVSS score does not fully reflect practical impact. Projects **MUST** publish a security advisory within the 90-day disclosure ceiling defined in [Section 6.5](#65-coordinated-disclosure). Within that ceiling, projects **SHOULD** aim for the following response targets: @@ -236,14 +172,11 @@ Projects **MUST** publish a security advisory within the 90-day disclosure ceili | **Low** | 0.1 – 3.9 | Best effort | Best effort | - **Fix Target**: Time from triage completion to a fix being merged. -- **Disclosure Target**: Time from triage completion to publishing a security advisory (see [Section 6.5](#65-coordinated-disclosure)). The disclosure **MUST NOT** exceed the 90-day embargo defined in [Section 6.5](#65-coordinated-disclosure). -- When the fix and disclosure targets coincide (as with Medium severity), the fix and disclosure **MAY** happen simultaneously. If the fix is not ready when the disclosure target expires, the TSC **SHOULD** publish a mitigation advisory and disclose per [Section 6.5](#65-coordinated-disclosure). - -If a project cannot meet a fix target, the TSC **SHOULD** communicate an updated timeline to the reporter and publish a mitigation or workaround advisory. Transparent communication about delays is always preferable to silently missing a deadline. +- **Disclosure Target**: Time from triage completion to publishing a security advisory. The disclosure **MUST NOT** exceed the 90-day embargo defined in [Section 6.5](#65-coordinated-disclosure). -> **Rationale:** The 90-day disclosure ceiling is a **MUST** aligned with the [OpenSSF Model Outbound Vulnerability Disclosure Policy](https://github.com/ossf/oss-vulnerability-guide/blob/main/maintainer-guide.md), Google Project Zero, and CNCF projects such as Envoy. The severity-based fix targets are **SHOULD**-level goals — no major open source foundation (including CNCF) mandates hard, severity-tiered fix SLAs, and volunteer-maintained projects cannot guarantee timelines the way commercial vendors can. The targets are comparable to those used by GitLab and Chainguard and provide a reasonable benchmark for projects to measure against. +If a project cannot meet a fix target, the TSC **SHOULD** communicate an updated timeline to the reporter and publish a mitigation or workaround advisory. -Related sections: [6 — Vulnerability Response Process](#6-vulnerability-response-process); [6.5 — Coordinated Disclosure](#65-coordinated-disclosure). +The 90-day ceiling aligns with the [OpenSSF Vulnerability Disclosure Guide](https://github.com/ossf/oss-vulnerability-guide/blob/main/maintainer-guide.md) and Google Project Zero. Severity-based fix targets are **SHOULD**-level goals — volunteer-maintained projects cannot guarantee timelines the way commercial vendors can. --- @@ -251,263 +184,117 @@ Related sections: [6 — Vulnerability Response Process](#6-vulnerability-respon ### 8.1 Artifact Signing -| Priority | Resolution | Owner | -|------------|----------------------------------------------|-------| -| **SHOULD** | When publishing artifacts to external consumers | TSC | - -Projects **SHOULD** sign all published release artifacts (container images, binaries, packages) using [Sigstore cosign](https://docs.sigstore.dev/cosign/signing/overview/) or an equivalent signing mechanism. Signing **SHOULD** be integrated into the CI/CD pipeline. - -> **Practical note:** Artifact signing, build provenance, and SBOM generation (Sections 8.1–8.3) are intended to be adopted incrementally. Projects **SHOULD** prioritize software composition analysis ([Section 8.4](#84-software-composition-analysis-sca)) first, as it provides the highest security value with the least effort. The remaining supply chain practices can be introduced as the project matures and publishes artifacts to external consumers. +Projects **SHOULD** sign all published release artifacts (container images, binaries, packages) using [Sigstore](https://docs.sigstore.dev/) or an equivalent signing mechanism. Signing **SHOULD** be integrated into the CI/CD pipeline. ### 8.2 Build Provenance (SLSA) -| Priority | Resolution | Owner | -|------------|----------------------------------------------|-------| -| **SHOULD** | When publishing artifacts to external consumers | TSC | - -Projects **SHOULD** generate [SLSA](https://slsa.dev/) provenance attestations for published artifacts. The target level is at minimum [SLSA Build Level 2](https://slsa.dev/spec/v1.0/levels) (scripted build, hosted build platform). - -For implementation guidance and tooling options, see the [SLSA specification](https://slsa.dev/spec/v1.0/) and [OpenSSF Security Baseline](https://baseline.openssf.org/) controls `OSPS-DO-03.01` and `OSPS-DO-03.02` (Level 3). +Projects **SHOULD** generate [SLSA](https://slsa.dev/) provenance attestations for published artifacts, targeting at minimum [SLSA Build Level 2](https://slsa.dev/spec/v1.0/levels). ### 8.3 Software Bill of Materials (SBOM) -| Priority | Resolution | Owner | -|------------|----------------------------------------------|-------| -| **SHOULD** | When publishing artifacts to external consumers | TSC | - Projects **SHOULD** generate a Software Bill of Materials (SBOM) for each published release artifact. When an SBOM is published, it **MUST** use either [SPDX](https://spdx.dev/) or [CycloneDX](https://cyclonedx.org/) format. -SBOMs **SHOULD** be published alongside release artifacts (e.g., attached to GitHub releases or pushed to the OCI registry as a referrer). - ### 8.4 Software Composition Analysis (SCA) -| Priority | Resolution | Owner | -|----------|-----------------|-------| -| **MUST** | ASAP (≤30 days) | TSC | - -*The priority above applies to dependency vulnerability scanning. Container image scanning and license compliance scanning carry their own conformance levels below.* - -Projects **SHOULD** enable automated software composition analysis (SCA) covering vulnerability detection, container image scanning, and license compliance for all repositories containing publishable code. Modern SCA tools — such as [Trivy](https://github.com/aquasecurity/trivy), [Grype](https://github.com/anchore/grype), [OSV-Scanner](https://google.github.io/osv-scanner/), [Dependabot](https://docs.github.com/en/code-security/dependabot), or [Renovate](https://docs.renovatebot.com/) — typically cover multiple of these concerns in a single scan. See [OpenSSF Security Baseline](https://baseline.openssf.org/) controls `OSPS-VM-05.01` through `OSPS-VM-05.03` (Level 3) and `OSPS-LE-02.01`, `OSPS-LE-02.02` (Level 1). - -**Dependency vulnerability scanning** (**MUST**) - - Projects **MUST** scan direct and transitive dependencies for known vulnerabilities. - Projects **SHOULD** configure automated dependency update pull requests to reduce time-to-remediation. +- Projects **SHOULD** remediate known vulnerabilities of medium or higher severity within 60 calendar days of public disclosure, per [OpenSSF Best Practices](https://www.bestpractices.dev/). +- Projects that publish container images **SHOULD** scan all images for known vulnerabilities before pushing them to a registry. +- Projects **SHOULD** automate license scanning of all dependencies and define an allowlist of acceptable licenses. -**Container image scanning** (**SHOULD** — when publishing container images) - -- Projects that publish container images **SHOULD** scan all images for known vulnerabilities before pushing them to a registry, integrated into the CI/CD pipeline. -- Projects **SHOULD** fail the pipeline (or at minimum generate a warning) when vulnerabilities at or above a project-defined severity threshold are detected (e.g., "Critical and High"). - -**License compliance scanning** (**SHOULD**) - -- Projects **SHOULD** automate license scanning of all direct and transitive dependencies to detect incompatible, unknown, or unlicensed components. -- Projects **SHOULD** define an allowlist of acceptable licenses (e.g., MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause) and flag any dependency whose license is not on the allowlist. Dependencies with incompatible or unknown licenses **SHOULD** be resolved before release. - -Related sections: [8.3 — Software Bill of Materials (SBOM)](#83-software-bill-of-materials-sbom); [Project Guidelines §15.3.2 — Supplemental Compliance](../project-guidelines/project-guidelines.md#1532-supplemental-compliance). +See [OpenSSF Security Baseline](https://baseline.openssf.org/) controls `OSPS-VM-05.01` through `OSPS-VM-05.03` and `OSPS-LE-02.01`, `OSPS-LE-02.02`. --- -## 9. Security Transparency - -| Priority | Resolution | Owner | -|----------|-----------------|-------| -| **MUST** | ASAP (≤30 days) | TSC | - -Projects **MUST** publish security advisories for all confirmed vulnerabilities with a CVSS score ≥ 4.0 via the platform's advisory mechanism. On GitHub, use [GitHub Security Advisories](https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/about-repository-security-advisories). On GitLab, use [project-level vulnerability records](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/). On other platforms, publish advisories on the project website or mailing list and link to them from `SECURITY.md`. - -Projects **MUST** reference CVE identifiers and advisory links in the release notes of patched versions. If a CVE has not yet been assigned at the time of publication, the advisory **SHOULD** note that CVE assignment is pending and be updated once the identifier is issued. - -Release changelogs **SHOULD** explicitly flag security-relevant modifications (fixes, dependency updates addressing CVEs, configuration changes with security impact). See [OpenSSF Security Baseline](https://baseline.openssf.org/) control `OSPS-BR-04.01` (Level 2). - -Projects **SHOULD** maintain a public record of past security advisories accessible from the project's `SECURITY.md`. - -Related sections: [6.6 — Post-Disclosure](#66-post-disclosure); [5.2 — SECURITY.md](#52-securitymd). - ---- - -## 10. Operational Security Controls +## 9. Operational Security Controls This section defines security-relevant operational controls for NeoNephos projects. These requirements complement the supply chain security practices in [Section 8](#8-supply-chain-security) and the infrastructure guarantees in the [Project Guidelines §15](../project-guidelines/project-guidelines.md#15-operational-guarantees). -### 10.1 Authentication - -| Priority | Resolution | Owner | -|----------|-----------------|-------| -| **MUST** | ASAP (≤30 days) | TSC | +### 9.1 Authentication Projects **MUST** enforce Two-Factor Authentication (2FA) for all organization members. -Projects **SHOULD** disable SSH deploy keys at the organization level (strengthening the Project Guidelines' position, which does not enforce a global policy). Deploy keys lack per-user accountability; personal or machine accounts with MFA are preferred. - -Related sections: [Project Guidelines §15.3 — Security and Compliance](../project-guidelines/project-guidelines.md#153-security-and-compliance). - -### 10.2 CI/CD Security - -| Priority | Resolution | Owner | -|----------|-----------------|-------| -| **MUST** | ASAP (≤30 days) | TSC | - -*The priority above applies to the core CI/CD controls (fork workflows, workflow permissions). Sub-controls below carry their own conformance levels.* - -**Self-hosted runners** +Projects **SHOULD** disable SSH deploy keys at the organization level. Deploy keys lack per-user accountability; personal or machine accounts with MFA are preferred. -- Repository-level self-hosted runners **SHOULD NOT** be enabled. Organization-level policies **SHOULD** be used to prevent repositories from registering their own runners. -- Organization-level self-hosted runners **SHOULD NOT** be enabled unless necessary, and **SHOULD** be approved by GitHub Enterprise Cloud account administrators who record the decision via a TAC vote. -- *Rationale*: GitHub-hosted runners are preferred; self-hosted runners require careful hardening to prevent exploitation. Centralizing runner management at the organization level improves governance and auditability. - -**Fork pull-request workflows** +### 9.2 CI/CD Security - Projects **MUST** require approval for first-time contributors before workflows execute on fork pull requests. -- *Rationale*: Prevents unauthorized code execution from external contributors. - -**Workflow permissions** - -- The default `GITHUB_TOKEN` permission **MUST** be set to "Read repository contents and packages." +- The default `GITHUB_TOKEN` permission **MUST** be set to read-only. - Write access **SHOULD** be explicitly requested via the `permissions` key in workflow files. -- *Rationale*: Limits blast radius by preventing workflows from gaining unnecessary write access. See [OpenSSF Security Baseline](https://baseline.openssf.org/) control `OSPS-AC-04.01` (Level 2) for default permissions and `OSPS-AC-04.02` (Level 3) for per-job scoping. - -**Credential handling** - -| Priority | Resolution | Owner | -|------------|-----------------|-------| -| **SHOULD** | ASAP (≤90 days) | TSC | - -- Projects **SHOULD** use workload identities (OIDC) or short-lived GitHub access tokens for interactions with external services. -- Where workload identity is not supported, projects **SHOULD** use fine-grained personal access tokens with the minimum required scopes. -- Temporary access tokens created for exceptional local batch jobs **MUST** be deleted immediately after use and **SHOULD NOT** exceed a short lifetime (e.g., 6 hours). -- Projects **SHOULD** conduct package releases via CI/CD pipelines (GitHub Actions recommended) rather than from local machines. See also [Section 8.1 — Artifact Signing](#81-artifact-signing) and [Section 8.2 — Build Provenance](#82-build-provenance-slsa). - -**Pipeline input sanitization** - -| Priority | Resolution | Owner | -|------------|-----------------|-------| -| **SHOULD** | ASAP (≤90 days) | TSC | - -- Workflows **SHOULD** treat all externally supplied metadata (issue titles, PR bodies, branch names, commit messages) as untrusted input and sanitize it before use in shell commands, environment variables, or script interpolation. -- Workflows triggered by events from untrusted sources (e.g., `pull_request_target`, `issue_comment`) **SHOULD NOT** check out or execute code from the untrusted source in a context that has access to repository secrets. -- *Rationale*: Prevents script injection and privilege escalation via CI/CD pipelines. See [OpenSSF Security Baseline](https://baseline.openssf.org/) `OSPS-BR-01.01` (Level 1) and the [OpenSSF SCM Best Practices](https://best.openssf.org/SCM-BestPractices/). - -**Workflow dependency pinning and action provenance** - -| Priority | Resolution | Owner | -|------------|-----------------|-------| -| **SHOULD** | ASAP (≤90 days) | TSC | - -- Third-party GitHub Actions **SHOULD** be pinned to a specific commit SHA rather than a mutable tag (e.g., `actions/checkout@` instead of `actions/checkout@v4`). -- Projects **SHOULD** restrict allowed GitHub Actions to actions created by GitHub and verified creators, or to an explicit allowlist maintained by the project. See the [OpenSSF Scorecard `Pinned-Dependencies` check](https://github.com/ossf/scorecard/blob/main/docs/checks.md#pinned-dependencies). +- Projects **SHOULD** use workload identities (OIDC) or short-lived tokens for interactions with external services. +- Third-party actions **SHOULD** be pinned to a specific commit SHA rather than a mutable tag. +- Workflows **SHOULD** treat all externally supplied metadata as untrusted input and sanitize it before use in shell commands. +- Projects **SHOULD** conduct package releases via CI/CD pipelines rather than from local machines. +- Repository-level self-hosted runners **SHOULD NOT** be enabled unless approved by organization administrators. -> **Exemplary implementation:** The [Open Component Model CI workflows](https://github.com/open-component-model/open-component-model/tree/main/.github/workflows) demonstrate SHA-pinned actions, minimal `GITHUB_TOKEN` permissions with per-job escalation, and safe `pull_request_target` handling. +See [OpenSSF Security Baseline](https://baseline.openssf.org/) controls `OSPS-AC-04.01`, `OSPS-AC-04.02`, `OSPS-BR-01.01`. -Related sections: [Project Guidelines §15.3 — Security and Compliance](../project-guidelines/project-guidelines.md#153-security-and-compliance); [8 — Supply Chain Security](#8-supply-chain-security). - -### 10.3 Branch Protection - -| Priority | Resolution | Owner | -|----------|-----------------|-------| -| **MUST** | ASAP (≤30 days) | TSC | +### 9.3 Branch Protection Projects **MUST** enable branch protection rules on the primary branch (e.g., `main`) of every repository containing publishable code. At minimum: -1. Direct commits to the primary branch **MUST** be prevented; all changes **MUST** go through a pull request or merge request. +1. Direct commits to the primary branch **MUST** be prevented; all changes **MUST** go through a pull request. 2. Force-pushes to the primary branch **MUST** be disabled. 3. Deletion of the primary branch **MUST** be prevented. 4. At least one approving review from a non-author maintainer **MUST** be required before merge. 5. Required status checks (CI build, tests, security scans) **SHOULD** pass before merge. -> **OpenSSF alignment:** [OpenSSF Security Baseline](https://baseline.openssf.org/) controls `OSPS-AC-03.01` and `OSPS-AC-03.02` (Level 1) require preventing unauthorized commits and deletion of the primary branch. Control `OSPS-QA-07.01` (Level 3) requires non-author approval before merge. See also the [OpenSSF SCM Best Practices](https://best.openssf.org/SCM-BestPractices/) for platform-specific configuration guidance. - -### 10.4 Secret Scanning and Prevention +### 9.4 Secret Scanning -| Priority | Resolution | Owner | -|----------|-----------------|-------| -| **MUST** | ASAP (≤30 days) | TSC | - -Projects **MUST** enable automated secret scanning on all repositories to detect accidentally committed credentials, API keys, and tokens. On GitHub, enable [Secret Scanning](https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning) and [Push Protection](https://docs.github.com/en/code-security/secret-scanning/introduction/about-push-protection). On GitLab, enable [Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/). On other platforms, integrate a tool such as [Gitleaks](https://github.com/gitleaks/gitleaks) or [TruffleHog](https://github.com/trufflesecurity/trufflehog) into the CI pipeline. +Projects **MUST** enable automated secret scanning on all repositories to detect accidentally committed credentials, API keys, and tokens. Projects **SHOULD** enable push protection to block commits containing detected secrets before they enter the repository history. -> **OpenSSF alignment:** [OpenSSF Security Baseline](https://baseline.openssf.org/) control `OSPS-BR-07.01` (Level 1) requires that the project's version control system **MUST** prevent secrets from being included in a commit. The [OpenSSF Concise Guide for Developing More Secure Software](https://best.openssf.org/Concise-Guide-for-Developing-More-Secure-Software) (Recommendation #9) reinforces this requirement. - -### 10.5 Access Governance - -| Priority | Resolution | Owner | -|------------|-----------------|-------| -| **SHOULD** | ASAP (≤90 days) | TSC | +### 9.5 Access Governance Projects **SHOULD** follow the principle of least privilege for all access grants: -- Limit GitHub Organization Owner access to a small number of administrative accounts. +- Limit organization owner access to a small number of administrative accounts. - Limit the number of maintainers with repository admin permissions. -- Ensure settings and permissions changes are made only by trusted administrators. -- Use pull requests for all repository changes; consider preventing direct push access by requiring pull-request merges from forks. +- Use pull requests for all repository changes. - Maintain an up-to-date inventory of maintainer permissions across all platforms used by the project. -**Maintainer vetting** - -Projects **SHOULD** require that maintainer candidates: - -1. Have a demonstrated history of contributions for at least 6 months. -2. Are vouched for by an existing maintainer. -3. Have verified their real identity with an existing maintainer, preferably in person. - -*Rationale*: Vetting contributors before granting commit or release access mitigates supply chain risks from compromised or malicious accounts (cf. the [xz-utils incident](https://en.wikipedia.org/wiki/XZ_Utils_backdoor)). For the broader contributor promotion process, see the [Project Lifecycle Policy](../lifecycle-policy/project-lifecycle-policy.md). - -### 10.6 Code Quality and Scanning - -| Priority | Resolution | Owner | -|------------|-----------------|-------| -| **SHOULD** | ASAP (≤90 days) | TSC | - -Projects **SHOULD** enable static application security testing (SAST) — such as [CodeQL](https://codeql.github.com/) or [SonarQube](https://www.sonarsource.com/products/sonarqube/) — to detect code-level vulnerabilities. Projects **SHOULD** define a severity threshold (e.g., "Critical and High") and gate the CI pipeline on it. See [OpenSSF Security Baseline](https://baseline.openssf.org/) controls `OSPS-VM-06.01` and `OSPS-VM-06.02` (Level 3). +Projects **SHOULD** require that maintainer candidates have a sustained history of contributions, are vouched for by an existing maintainer, and have verified their real identity with an existing maintainer, preferably in person. Vetting contributors before granting commit or release access mitigates supply chain risks from compromised or malicious accounts (cf. the [xz-utils incident](https://en.wikipedia.org/wiki/XZ_Utils_backdoor)). -For dependency-level vulnerability scanning, see [Section 8.4 — Software Composition Analysis](#84-software-composition-analysis-sca). +### 9.6 Code Quality and Scanning -### 10.7 Data Retention +Projects **SHOULD** enable static application security testing (SAST) to detect code-level vulnerabilities. Projects **SHOULD** define a severity threshold and gate the CI pipeline on it. -| Priority | Resolution | Owner | -|------------|-----------------|-------| -| **SHOULD** | ASAP (≤90 days) | TSC | +### 9.7 Security Assessment and Posture Verification -- **Private repositories**: Artifact and log retention **SHOULD** be configured to at least 180 days. -- **Public repositories**: Artifact and log retention **SHOULD** be configured to at least 180 days. On platforms where the maximum is lower (e.g., GitHub limits public repositories to 90 days), projects **SHOULD** configure the platform maximum. +Projects **SHOULD** perform an initial security assessment when entering the Growth or Graduated lifecycle stage, covering trust boundaries, a lightweight threat model, and documentation of known security assumptions and residual risks. -Related sections: [Project Guidelines §15.3 — Security and Compliance](../project-guidelines/project-guidelines.md#153-security-and-compliance). +Projects **SHOULD** enable the [OpenSSF Scorecard](https://github.com/ossf/scorecard) on all repositories containing publishable code. Scorecard provides automated checks for many of the requirements in this document, including branch protection, dependency scanning, CI permissions, and vulnerability disclosure. -### 10.8 Security Assessment - -| Priority | Resolution | Owner | -|------------|-----------------|-------| -| **SHOULD** | ASAP (≤90 days) | TSC | - -Projects **SHOULD** perform an initial security assessment when entering the Growth or Graduated lifecycle stage. The assessment **SHOULD** include: - -1. Identification of the project's trust boundaries and external interfaces. -2. A lightweight threat model covering the project's primary attack surfaces (e.g., using [STRIDE](https://en.wikipedia.org/wiki/STRIDE_%28security%29) or equivalent). -3. Documentation of known security assumptions and residual risks. - -The assessment does not need to be formal; a section in the project's documentation or a dedicated `SECURITY_ASSESSMENT.md` is sufficient. Projects **SHOULD** review and update the assessment when significant architectural changes occur. - -> **OpenSSF alignment:** [OpenSSF Security Baseline](https://baseline.openssf.org/) controls `OSPS-SA-03.01` (Level 2) and `OSPS-SA-03.02` (Level 3) require security assessment, threat modeling, and attack surface analysis for mature projects. - -### 10.9 Automated Security Posture Verification - -| Priority | Resolution | Owner | -|------------|-----------------|-------| -| **SHOULD** | ASAP (≤90 days) | TSC | - -Projects **SHOULD** enable the [OpenSSF Scorecard](https://github.com/ossf/scorecard) on all repositories containing publishable code. Scorecard provides automated checks for many of the requirements in this document and the [Project Guidelines](../project-guidelines/project-guidelines.md), including branch protection, dependency scanning, CI permissions, and vulnerability disclosure. - -Projects **MAY** integrate Scorecard into their CI pipeline via the [Scorecard GitHub Action](https://github.com/ossf/scorecard-action) to receive continuous feedback on security posture. - -> **Exemplary implementation:** The [Open Component Model Scorecard workflow](https://github.com/open-component-model/open-component-model/blob/main/.github/workflows/openssf-scorecard.yml) runs Scorecard with SARIF upload to the code-scanning dashboard. +--- -Related sections: [8 — Supply Chain Security](#8-supply-chain-security); [8.4 — Software Composition Analysis](#84-software-composition-analysis-sca); [10.2 — CI/CD Security](#102-cicd-security). +## 10. Conformance Matrix + +Each requirement carries a conformance priority and a resolution timeframe. The TSC of each project is the responsible owner for all requirements. + +| Section | Requirement | Priority | Resolution | Owner | +|---------|-------------|----------|------------|-------| +| Section 5 | Private vulnerability intake channel | **MUST** | ≤30 days | TSC | +| Section 5 | SECURITY.md in every publishable repository | **MUST** | ≤30 days | TSC | +| Section 6 | Designated security contacts | **MUST** | ≤30 days | TSC | +| Section 6 | Initial response within 14 days | **MUST** | ≤30 days | TSC | +| Section 6 | Coordinated disclosure, 90-day embargo ceiling | **MUST** | ≤30 days | TSC | +| Section 6 | CVE assignment for CVSS ≥ 4.0 | **SHOULD** | ≤30 days | TSC | +| Section 7 | Severity classification using CVSS v3.1+ | **MUST** | ≤30 days | TSC | +| Section 8 | Dependency vulnerability scanning | **MUST** | ≤30 days | TSC | +| Section 8 | Artifact signing, SLSA provenance, SBOM | **SHOULD** | When publishing | TSC | +| Section 9 | 2FA for all organization members | **MUST** | ≤30 days | TSC | +| Section 9 | Branch protection on primary branch | **MUST** | ≤30 days | TSC | +| Section 9 | Secret scanning and push protection | **MUST** | ≤30 days | TSC | +| Section 9 | First-time contributor CI approval | **MUST** | ≤30 days | TSC | +| Section 9 | Default GITHUB_TOKEN read-only | **MUST** | ≤30 days | TSC | +| Section 9 | OIDC/short-lived tokens, action pinning, input sanitization | **SHOULD** | ≤90 days | TSC | +| Section 9 | Access governance and maintainer vetting | **SHOULD** | ≤90 days | TSC | +| Section 9 | SAST scanning | **SHOULD** | ≤90 days | TSC | +| Section 9 | Security assessment and Scorecard | **SHOULD** | ≤90 days | TSC | --- ## 11. Acknowledgements -Projects **SHOULD** credit security researchers who responsibly report vulnerabilities, unless the reporter requests anonymity. Acknowledgement **SHOULD** be included in the published security advisory and **MAY** also be included in release notes. - -Related sections: [6.5 — Coordinated Disclosure](#65-coordinated-disclosure); [9 — Security Transparency](#9-security-transparency). +Projects **SHOULD** credit security researchers who responsibly report vulnerabilities, unless the reporter requests anonymity. diff --git a/templates/SECURITY.md b/templates/SECURITY.md index e070154..d38a9ec 100644 --- a/templates/SECURITY.md +++ b/templates/SECURITY.md @@ -9,6 +9,10 @@ cannot include repository-specific direct links (see Option A below). See the [NeoNephos Security Guidelines](../security-guidelines/security-guidelines.md) for the full set of requirements.* +*Note: The relative links below (e.g., `../security-guidelines/...`) assume this file lives in a +repository alongside the guidelines. If placed in an organization-level `.github` repository, adjust +links to point to the guidelines repository.* + ## Reporting a Vulnerability If you discover a security vulnerability in **\**, please report it responsibly @@ -49,15 +53,13 @@ Please report vulnerabilities as a **confidential issue**: You may report vulnerabilities via email to **\**. -*If your project publishes a PGP/GPG key for encrypted communication, mention it here and provide -a link to the public key or a fingerprint. Projects SHOULD also publish a -[`security.txt`](https://securitytxt.org/) file following [RFC 9116](https://www.rfc-editor.org/rfc/rfc9116).* +*If your project publishes a PGP/GPG key for encrypted communication, mention it here. Projects +SHOULD also publish a [`security.txt`](https://securitytxt.org/) file per [RFC 9116](https://www.rfc-editor.org/rfc/rfc9116).* ### Fallback Contact -*If your project uses Option A or Option B above as the primary channel, add an email fallback here -for reporters who do not have an account on the hosting platform. If you chose Option C as your -primary channel, remove this section to avoid duplication.* +*If your project uses Option A or Option B as the primary channel, add an email fallback here for +reporters without an account on that platform. Remove this section if you chose Option C as primary.* You may also report vulnerabilities via email to **\**. @@ -71,15 +73,14 @@ The following maintainers are responsible for handling vulnerability reports: | *\* | [@\](https://github.com/) | Security Contact | *The [NeoNephos Security Guidelines](../security-guidelines/security-guidelines.md#6-vulnerability-response-process) -require at least two security contacts. Add more rows as needed but do not reduce below two. +require designated security contacts. Add rows as needed. Adjust the profile links to match your hosting platform.* ## Supported Versions -*State clearly which versions receive security updates. This should express a version support policy -(e.g., "the latest two minor releases") rather than naming specific branches. Choose whichever format -fits your project — a table, a simple sentence, or a link to your release policy. Remove this guidance -text before publishing. Examples:* +*State which versions receive security updates — prefer a version support policy (e.g., "the latest +two minor releases") over naming specific branches. Choose any format that fits your project. Remove +this guidance text before publishing. Examples:* **Option A — Single active branch (common for early-stage projects):** @@ -110,8 +111,7 @@ This project follows the [NeoNephos Security Guidelines](../security-guidelines/ | Medium | 4.0 – 6.9 | ≤ 90 days | ≤ 90 days | | Low | 0.1 – 3.9 | Best effort | Best effort | -*Timelines are in calendar days, measured from triage completion. For the full response target definitions, see the -[NeoNephos Security Guidelines, Section 7](../security-guidelines/security-guidelines.md#7-severity-classification-and-response-targets).* +*Timelines are in calendar days, measured from triage completion. For the full definitions, see the [NeoNephos Security Guidelines, Section 7](../security-guidelines/security-guidelines.md#7-severity-classification-and-response-targets).* ## Disclosure Policy @@ -125,7 +125,6 @@ We are committed to crediting reporters in our security advisories unless you pr ## Past Security Advisories -*Optional — include this section only if your project has published advisories. Remove it entirely -for new projects. Adjust the link to match your hosting platform.* +*Replace with a link to your platform's published advisories page, or list "None yet" for new projects.* -See [Published Security Advisories](https://github.com///security/advisories?state=published). +None yet. See [Published Security Advisories](https://github.com///security/advisories?state=published) once advisories are available. From 5df2757e81e6f9ea191e819d9c1fdad8b214df92 Mon Sep 17 00:00:00 2001 From: Gerald Morrison Date: Tue, 5 May 2026 16:48:10 +0200 Subject: [PATCH 13/14] address PR review feedback from Skarlso - Resolve CVE MUST/SHOULD contradiction: advisory links MUST be in release notes, CVE identifier MUST only when assigned (Section 6.4 stays SHOULD) - Align all timelines to report receipt (Day 0), matching Google Project Zero practice; remove "from triage completion" phrasing - Clarify embargo starts from report receipt, not acknowledgement - Fix conformance matrix: split secret scanning (MUST) from push protection (SHOULD) into separate rows - Make CI/CD section platform-neutral: generic requirements with "On GitHub:"/"On GitLab:" implementation guidance - Quick-start checklist: fix item #10 (secret scanning only, push protection is SHOULD) and #12 (platform-neutral wording) - Template: convert italic instructions to HTML comments - Template: add PVR enablement reminder before GitHub section - Template: use absolute URLs for cross-repo portability - Template: add "What to Include" section for reporters - Template: make security contacts table platform-neutral - Template: clarify attribution (OpenSSF vs NeoNephos) per item - Template: add footnote explaining 90-day ceiling vs fix targets Signed-off-by: Gerald Morrison --- security-guidelines/security-guidelines.md | 38 +++++---- templates/SECURITY.md | 98 +++++++++++++--------- 2 files changed, 80 insertions(+), 56 deletions(-) diff --git a/security-guidelines/security-guidelines.md b/security-guidelines/security-guidelines.md index f420935..8954793 100644 --- a/security-guidelines/security-guidelines.md +++ b/security-guidelines/security-guidelines.md @@ -75,9 +75,9 @@ Every project with publishable code or artifacts **MUST** complete these items. 7. Scan dependencies for known vulnerabilities ([Section 8.4](#84-software-composition-analysis-sca)) 8. Enforce 2FA for all organization members ([Section 9.1](#91-authentication)) 9. Enable branch protection on primary branch ([Section 9.3](#93-branch-protection)) -10. Enable secret scanning and push protection ([Section 9.4](#94-secret-scanning)) +10. Enable secret scanning ([Section 9.4](#94-secret-scanning)) 11. Require approval for first-time contributor CI workflows ([Section 9.2](#92-cicd-security)) -12. Set default GITHUB_TOKEN to read-only ([Section 9.2](#92-cicd-security)) +12. Set default CI/CD token to read-only ([Section 9.2](#92-cicd-security)) --- @@ -113,6 +113,8 @@ Each project's TSC **MUST** designate security contacts responsible for handling Projects **MUST** provide an initial response to a vulnerability report within **14 calendar days** of receiving it. Projects **SHOULD** acknowledge receipt within **2 business days** where maintainer availability permits. +> **Timeline anchor:** All timelines in this document are measured from **report receipt** (Day 0) — the date the project receives the vulnerability report. This follows [Google Project Zero's practice](https://googleprojectzero.blogspot.com/2021/04/policy-and-disclosure-2021-edition.html) of starting the clock at vendor notification. + ### 6.2 Triage and Severity Assessment The initial response **SHOULD** include — or be followed promptly by — a triage that covers: @@ -139,7 +141,7 @@ Vulnerabilities scoring below 4.0 (Low) **MAY** be tracked informally and do not Projects **MUST** follow a coordinated disclosure process: -1. **Embargo period**: The maximum embargo duration is **90 calendar days** from the date the report is acknowledged. During this period, details of the vulnerability **MUST NOT** be disclosed publicly. +1. **Embargo period**: The maximum embargo duration is **90 calendar days** from report receipt (Day 0), consistent with the [Google Project Zero disclosure policy](https://googleprojectzero.blogspot.com/2021/04/policy-and-disclosure-2021-edition.html). During this period, details of the vulnerability **MUST NOT** be disclosed publicly. 2. **Disclosure**: Once a fix is available (or the embargo expires), the project **MUST** publish a security advisory containing: - A description of the vulnerability. - Affected versions. @@ -147,14 +149,14 @@ Projects **MUST** follow a coordinated disclosure process: - The CVE identifier (if assigned). - Remediation steps or patched versions. 3. **Advisory publication**: Projects **MUST** publish advisories for all confirmed vulnerabilities with a CVSS score ≥ 4.0 via the platform's advisory mechanism. -4. **Release notes**: Projects **MUST** reference CVE identifiers and advisory links in the release notes of patched versions. +4. **Release notes**: Projects **MUST** reference advisory links in the release notes of patched versions. When a CVE has been assigned (see [Section 6.4](#64-cve-assignment)), the CVE identifier **MUST** also be referenced. 5. **Changelogs**: Release changelogs **SHOULD** explicitly flag security-relevant modifications (fixes, dependency updates addressing CVEs, configuration changes with security impact). 6. **Advisory history**: Projects **SHOULD** maintain a public record of past security advisories accessible from the project's `SECURITY.md`. 7. **Early disclosure**: If active exploitation is detected in the wild, the TSC **MAY** shorten the embargo period and disclose early with whatever fix or mitigation is available. ### 6.6 Post-Disclosure -The fix **MUST** be released in a patch version for all supported release branches. The CVE and advisory **SHOULD** be referenced in the release notes of the patched version. +The fix **MUST** be released in a patch version for all supported release branches. The advisory **MUST** be referenced in the release notes of the patched version. The CVE identifier **SHOULD** also be referenced when assigned (see [Section 6.4](#64-cve-assignment)). --- @@ -162,7 +164,7 @@ The fix **MUST** be released in a patch version for all supported release branch Projects **MUST** classify vulnerabilities using [CVSS v3.1](https://www.first.org/cvss/v3.1/specification-document) or later. Maintainers **MAY** exercise judgment when the CVSS score does not fully reflect practical impact. -Projects **MUST** publish a security advisory within the 90-day disclosure ceiling defined in [Section 6.5](#65-coordinated-disclosure). Within that ceiling, projects **SHOULD** aim for the following response targets: +Projects **MUST** publish a security advisory within the 90-day disclosure ceiling defined in [Section 6.5](#65-coordinated-disclosure). Within that ceiling, projects **SHOULD** aim for the following response targets (measured from report receipt, Day 0): | Severity | CVSS Score | Fix Target | Disclosure Target | |--------------|------------|------------------------|------------------------| @@ -171,12 +173,12 @@ Projects **MUST** publish a security advisory within the 90-day disclosure ceili | **Medium** | 4.0 – 6.9 | ≤ 90 calendar days | ≤ 90 calendar days | | **Low** | 0.1 – 3.9 | Best effort | Best effort | -- **Fix Target**: Time from triage completion to a fix being merged. -- **Disclosure Target**: Time from triage completion to publishing a security advisory. The disclosure **MUST NOT** exceed the 90-day embargo defined in [Section 6.5](#65-coordinated-disclosure). +- **Fix Target**: Time from report receipt to a fix being merged. +- **Disclosure Target**: Time from report receipt to publishing a security advisory. The disclosure **MUST NOT** exceed the 90-day embargo defined in [Section 6.5](#65-coordinated-disclosure). If a project cannot meet a fix target, the TSC **SHOULD** communicate an updated timeline to the reporter and publish a mitigation or workaround advisory. -The 90-day ceiling aligns with the [OpenSSF Vulnerability Disclosure Guide](https://github.com/ossf/oss-vulnerability-guide/blob/main/maintainer-guide.md) and Google Project Zero. Severity-based fix targets are **SHOULD**-level goals — volunteer-maintained projects cannot guarantee timelines the way commercial vendors can. +The 90-day ceiling aligns with the [Google Project Zero disclosure policy](https://googleprojectzero.blogspot.com/2021/04/policy-and-disclosure-2021-edition.html) and the [OpenSSF Vulnerability Disclosure Guide](https://github.com/ossf/oss-vulnerability-guide/blob/main/maintainer-guide.md). All timelines start from report receipt (Day 0), following Project Zero's practice of measuring from vendor notification. Severity-based fix targets are **SHOULD**-level goals — volunteer-maintained projects cannot guarantee timelines the way commercial vendors can. --- @@ -218,14 +220,15 @@ Projects **SHOULD** disable SSH deploy keys at the organization level. Deploy ke ### 9.2 CI/CD Security -- Projects **MUST** require approval for first-time contributors before workflows execute on fork pull requests. -- The default `GITHUB_TOKEN` permission **MUST** be set to read-only. -- Write access **SHOULD** be explicitly requested via the `permissions` key in workflow files. -- Projects **SHOULD** use workload identities (OIDC) or short-lived tokens for interactions with external services. -- Third-party actions **SHOULD** be pinned to a specific commit SHA rather than a mutable tag. +- Projects **MUST** require approval for first-time contributors before CI/CD workflows execute on fork pull requests. +- The default CI/CD token permission **MUST** be set to read-only (repository contents and packages). On GitHub, this means the `GITHUB_TOKEN` default; on GitLab, configure [protected CI/CD variables](https://docs.gitlab.com/ee/ci/variables/#protect-a-cicd-variable) with minimal scope. +- Write access **SHOULD** be explicitly requested per job or workflow. On GitHub, use the `permissions` key in workflow files. On GitLab, use protected environments and approval gates. +- Projects **SHOULD** use workload identities (OIDC) or short-lived access tokens for interactions with external services. +- Third-party CI/CD actions or templates **SHOULD** be pinned to a specific commit SHA or immutable digest rather than a mutable tag. On GitHub, pin actions by SHA (e.g., `actions/checkout@`). On GitLab, pin included templates by ref. - Workflows **SHOULD** treat all externally supplied metadata as untrusted input and sanitize it before use in shell commands. +- Workflows triggered by events from untrusted sources (e.g., on GitHub: `pull_request_target`, `issue_comment`; on GitLab: merge request pipelines from forks) **SHOULD NOT** execute untrusted code in a context with access to repository secrets. - Projects **SHOULD** conduct package releases via CI/CD pipelines rather than from local machines. -- Repository-level self-hosted runners **SHOULD NOT** be enabled unless approved by organization administrators. +- Repository-level self-hosted runners **SHOULD NOT** be enabled unless approved by platform administrators. See [OpenSSF Security Baseline](https://baseline.openssf.org/) controls `OSPS-AC-04.01`, `OSPS-AC-04.02`, `OSPS-BR-01.01`. @@ -285,9 +288,10 @@ Each requirement carries a conformance priority and a resolution timeframe. The | Section 8 | Artifact signing, SLSA provenance, SBOM | **SHOULD** | When publishing | TSC | | Section 9 | 2FA for all organization members | **MUST** | ≤30 days | TSC | | Section 9 | Branch protection on primary branch | **MUST** | ≤30 days | TSC | -| Section 9 | Secret scanning and push protection | **MUST** | ≤30 days | TSC | +| Section 9 | Secret scanning | **MUST** | ≤30 days | TSC | +| Section 9 | Push protection | **SHOULD** | ≤30 days | TSC | | Section 9 | First-time contributor CI approval | **MUST** | ≤30 days | TSC | -| Section 9 | Default GITHUB_TOKEN read-only | **MUST** | ≤30 days | TSC | +| Section 9 | Default CI/CD token read-only | **MUST** | ≤30 days | TSC | | Section 9 | OIDC/short-lived tokens, action pinning, input sanitization | **SHOULD** | ≤90 days | TSC | | Section 9 | Access governance and maintainer vetting | **SHOULD** | ≤90 days | TSC | | Section 9 | SAST scanning | **SHOULD** | ≤90 days | TSC | diff --git a/templates/SECURITY.md b/templates/SECURITY.md index d38a9ec..dfc6244 100644 --- a/templates/SECURITY.md +++ b/templates/SECURITY.md @@ -1,28 +1,41 @@ -# Security Policy (Template) - -*This is a template for a SECURITY.md file. Adjust the placeholders (marked with `<...>`) to match -your project. Remove this italic guidance text before publishing. For projects with multiple -repositories, each repository containing publishable code or artifacts MUST have its own SECURITY.md. -On GitHub, a SECURITY.md placed in the organization's `.github` repository serves as the default for -all repositories that do not have their own — this satisfies the per-repository requirement, but -cannot include repository-specific direct links (see Option A below). -See the [NeoNephos Security Guidelines](../security-guidelines/security-guidelines.md) for the full -set of requirements.* - -*Note: The relative links below (e.g., `../security-guidelines/...`) assume this file lives in a -repository alongside the guidelines. If placed in an organization-level `.github` repository, adjust -links to point to the guidelines repository.* +# Security Policy + + ## Reporting a Vulnerability If you discover a security vulnerability in **\**, please report it responsibly through one of the channels below. **Do not open a public issue for security vulnerabilities.** -*Choose the section that matches your hosting platform. Remove the other sections and this guidance -text before publishing.* +### What to Include in Your Report + +To help us assess and address the vulnerability efficiently, please include: + +- **Affected component(s)** and version(s) +- **Steps to reproduce** the vulnerability +- **Impact assessment** — what an attacker could achieve +- Whether the vulnerability is **already publicly known** +- Any suggested fix or mitigation (optional) ### Option A: GitHub Private Vulnerability Reporting (Preferred for GitHub-hosted projects) + + Please use GitHub's built-in private vulnerability reporting: 1. Navigate to the **Security** tab of this repository. @@ -31,11 +44,11 @@ Please use GitHub's built-in private vulnerability reporting: Direct link: [Report a vulnerability](https://github.com///security/advisories/new) -*For more information, see [Privately reporting a security vulnerability](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability).* + -*If this SECURITY.md is used as an organization-level file in a `.github` repository, remove the -direct link above and keep only the step-by-step instructions, since the link cannot point to a -specific repository.* +*For more information, see [Privately reporting a security vulnerability](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability).* ### Option B: GitLab Confidential Issues (Preferred for GitLab-hosted projects) @@ -53,34 +66,39 @@ Please report vulnerabilities as a **confidential issue**: You may report vulnerabilities via email to **\**. -*If your project publishes a PGP/GPG key for encrypted communication, mention it here. Projects -SHOULD also publish a [`security.txt`](https://securitytxt.org/) file per [RFC 9116](https://www.rfc-editor.org/rfc/rfc9116).* + ### Fallback Contact -*If your project uses Option A or Option B as the primary channel, add an email fallback here for -reporters without an account on that platform. Remove this section if you chose Option C as primary.* + You may also report vulnerabilities via email to **\**. ## Security Contacts + + The following maintainers are responsible for handling vulnerability reports: | Name | Handle | Role | |------|--------|------| -| *\* | [@\](https://github.com/) | Lead Security Contact | -| *\* | [@\](https://github.com/) | Security Contact | - -*The [NeoNephos Security Guidelines](../security-guidelines/security-guidelines.md#6-vulnerability-response-process) -require designated security contacts. Add rows as needed. -Adjust the profile links to match your hosting platform.* +| \ | [\]() | Lead Security Contact | +| \ | [\]() | Security Contact | ## Supported Versions -*State which versions receive security updates — prefer a version support policy (e.g., "the latest -two minor releases") over naming specific branches. Choose any format that fits your project. Remove -this guidance text before publishing. Examples:* + **Option A — Single active branch (common for early-stage projects):** @@ -96,11 +114,11 @@ this guidance text before publishing. Examples:* ## Response Process -This project follows the [NeoNephos Security Guidelines](../security-guidelines/security-guidelines.md) for vulnerability handling. In summary: +This project follows the [NeoNephos Security Guidelines](https://github.com/neonephos/guidelines-development/blob/main/security-guidelines/security-guidelines.md) for vulnerability handling. In summary: -- **Initial response**: We will respond to your report within **14 calendar days**, in line with the [OpenSSF Best Practices](https://www.bestpractices.dev/) requirement. -- **Embargo**: Vulnerability details will remain confidential for up to **90 days** while a fix is developed. Fix timelines (see table below) are measured from triage completion. -- **Disclosure**: Once a fix is available, we will publish a security advisory with full details. +- **Initial response**: We will respond to your report within **14 calendar days** of receipt, in line with the [OpenSSF Best Practices](https://www.bestpractices.dev/) requirement. +- **Embargo**: Vulnerability details will remain confidential for up to **90 days** from report receipt while a fix is developed, consistent with the [Google Project Zero disclosure policy](https://googleprojectzero.blogspot.com/2021/04/policy-and-disclosure-2021-edition.html). +- **Disclosure**: Once a fix is available (or the embargo expires), we will publish a security advisory with full details. ### Severity Response Targets @@ -111,7 +129,7 @@ This project follows the [NeoNephos Security Guidelines](../security-guidelines/ | Medium | 4.0 – 6.9 | ≤ 90 days | ≤ 90 days | | Low | 0.1 – 3.9 | Best effort | Best effort | -*Timelines are in calendar days, measured from triage completion. For the full definitions, see the [NeoNephos Security Guidelines, Section 7](../security-guidelines/security-guidelines.md#7-severity-classification-and-response-targets).* +*These are **SHOULD**-level targets as defined by the [NeoNephos Security Guidelines](https://github.com/neonephos/guidelines-development/blob/main/security-guidelines/security-guidelines.md#7-severity-classification-and-response-targets). The 90-day embargo ceiling is a **MUST** aligned with Google Project Zero. All timelines are measured from report receipt (Day 0); fix and disclosure may occur simultaneously.* ## Disclosure Policy @@ -125,6 +143,8 @@ We are committed to crediting reporters in our security advisories unless you pr ## Past Security Advisories -*Replace with a link to your platform's published advisories page, or list "None yet" for new projects.* + None yet. See [Published Security Advisories](https://github.com///security/advisories?state=published) once advisories are available. From 1cc72694c210b77dbd27288823a3bfccbe655fa8 Mon Sep 17 00:00:00 2001 From: Gerald Morrison Date: Tue, 5 May 2026 17:34:25 +0200 Subject: [PATCH 14/14] make push protection a MUST --- security-guidelines/security-guidelines.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/security-guidelines/security-guidelines.md b/security-guidelines/security-guidelines.md index 8954793..68686b9 100644 --- a/security-guidelines/security-guidelines.md +++ b/security-guidelines/security-guidelines.md @@ -75,7 +75,7 @@ Every project with publishable code or artifacts **MUST** complete these items. 7. Scan dependencies for known vulnerabilities ([Section 8.4](#84-software-composition-analysis-sca)) 8. Enforce 2FA for all organization members ([Section 9.1](#91-authentication)) 9. Enable branch protection on primary branch ([Section 9.3](#93-branch-protection)) -10. Enable secret scanning ([Section 9.4](#94-secret-scanning)) +10. Enable secret scanning and push protection ([Section 9.4](#94-secret-scanning)) 11. Require approval for first-time contributor CI workflows ([Section 9.2](#92-cicd-security)) 12. Set default CI/CD token to read-only ([Section 9.2](#92-cicd-security)) @@ -246,7 +246,7 @@ Projects **MUST** enable branch protection rules on the primary branch (e.g., `m Projects **MUST** enable automated secret scanning on all repositories to detect accidentally committed credentials, API keys, and tokens. -Projects **SHOULD** enable push protection to block commits containing detected secrets before they enter the repository history. +Projects **MUST** enable push protection to block commits containing detected secrets before they enter the repository history. ### 9.5 Access Governance