Skip to content

docs: deduplicate security content and align with onboarding guidelines #9

New issue

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

Sign up for GitHub

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

Already on GitHub? Sign in to your account

Open
nexus49 wants to merge 2 commits into
base: main
Choose a base branch
from
Open

docs: deduplicate security content and align with onboarding guidelines #9

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
40f303e
docs: deduplicate security content and align with onboarding guidelines
nexus49 Apr 7, 2026
fa81ae7
docs: require linking to LF-hosted charter instead of copying it
nexus49 Apr 10, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions onboarding/onboarding-guidelines.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -14,15 +14,15 @@ The onboarding process ensures that new projects adopt baseline governance, tech

**Governance and Administration**

* **MUST** publish a project charter (canonical + Markdown).
* **MUST** adopt the Linux Foundation Code of Conduct.
* **MUST** link to the project charter hosted by the Linux Foundation.
* **MUST** adopt the [NeoNephos Code of Conduct](https://github.com/neonephos/.github/blob/main/CODE_OF_CONDUCT.md).
Copy link
Copy Markdown

@jmertic jmertic Apr 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is problematic, as each project has definied in it's techincal charter to use the LF Europe CoC unless the project has it's own pre-approved ( see 4c).

Copy link
Copy Markdown
Contributor

@fmui fmui Apr 10, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See PR #3.

Copy link
Copy Markdown
Author

@nexus49 nexus49 Apr 10, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok is it NeoNephos Code of Conduct or LF Europe CoC ?

Copy link
Copy Markdown
Contributor

@fmui fmui Apr 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LF Europe CoC for now.

Copy link
Copy Markdown

@jmertic jmertic Apr 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess my point is this doesn't need called out, as it's already in each project's Technical Charter.

Bigger picture, restating things in the project's Technical Charter seems a bit overkill.

* **MUST** provide `CONTRIBUTING.md` with DCO/CLA details.
* **MUST** document maintainers and TSC members publicly.
* **MUST** designate a Security Officer.

**Technical and Development Practices**

* **MUST** use LF-approved licenses (SPDX or REUSE).
* **MUST** use licenses approved through their Project Charter (SPDX or REUSE).
* **MUST** enable CI for builds, tests, linting, and security scanning.
* **MUST** provide `SECURITY.md` with disclosure policy and contacts.
* **MUST** track third-party licenses.
Expand Down
103 changes: 17 additions & 86 deletions project-guidelines/project-guidelines.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -38,16 +38,14 @@
* [15.1 Infrastructure Guarantees](#151-infrastructure-guarantees)
* [15.2 Availability Targets](#152-availability-targets)
* [15.3 Security and Compliance](#153-security-and-compliance)
* [15.3.1 Mandatory Compliance Requirements](#1531-mandatory-compliance-requirements)
* [15.3.2 Supplemental Compliance](#1532-supplemental-compliance)
* [15.4 Escalation and Support](#154-escalation-and-support)
* [15.5 Service Review](#155-service-review)
* [16. Project Onboarding](#16-project-onboarding)
<!-- TOC -->

## 1. Introduction

This document defines the current guidelines for projects goverened by the **NeoNephos Foundation**, a subfoundation of the Linux Foundation. All guidelines contained herein have been approved by the governing body and are binding unless otherwise stated.
This document defines the current guidelines for projects governed by the **NeoNephos Foundation**, a subfoundation of the Linux Foundation. All guidelines contained herein have been approved by the governing body and are binding unless otherwise stated.

The following terms are used throughout this document:

Expand Down Expand Up @@ -108,11 +106,11 @@ The following timelines for resolution may be defined in this document:

### Technical Charters

| Priority | Resolution | Owner |
|------------|-----------------------|-------|
| **SHOULD** | By next minor release | TSC |
| Priority | Resolution | Owner |
|----------|-----------------------|-------|
| **MUST** | By next minor release | TSC |

Each project **SHOULD** make its project charter publicly available (website or repository). If converted to Markdown, the Markdown version **MUST** remain synchronized with the canonical source.
Each project **MUST** link to its project charter hosted by the Linux Foundation (website or repository).

### Meetings

Expand Down Expand Up @@ -146,6 +144,7 @@ All TSC members and their roles **MUST** be listed publicly (e.g., website or re
* **Contribution Guidelines**: Projects **MUST** provide a `CONTRIBUTING.md` including CLA/DCO details.
* **Voting and Decision-Making**: The TSC **MUST** document its voting model (consensus, majority, or lazy consensus).
* **Ownership Documentation**: `OWNERS.md` or equivalent **MUST** define maintainers and approvers.
* **Security Officer**: Projects **MUST** designate a Security Officer responsible for coordinating vulnerability response (see [NeoNephos Security Guidelines](../security-guidelines/security-guidelines.md)).

### 5.1 Contribution Authentication

Expand Down Expand Up @@ -177,14 +176,15 @@ Related sections: [4 — Administration](#4-administration); [6 — Technical an
* **Dependency Management**:

* Projects **MUST** track third-party licenses.
* Projects **MAY** generate SBOMs for generated artifacts.
* For dependency scanning and SBOM requirements, see [NeoNephos Security Guidelines §8 — Supply Chain Security](../security-guidelines/security-guidelines.md#8-supply-chain-security).
Copy link
Copy Markdown

@jmertic jmertic Apr 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should bring in the LF License Scanning program to help here. I can have that lead come to a TAC meeting to discuss.


* **Security Disclosure**:
* **Security Disclosure**: See [NeoNephos Security Guidelines](../security-guidelines/security-guidelines.md) for vulnerability disclosure, response process, and `SECURITY.md` requirements.

* Projects **MUST** provide a [`SECURITY.md`](https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository) defining their security policy.
* Projects **MUST** define disclosure contacts (see Security Officer above).
* Projects **MUST** Configure GitHub to allow [reporting vulnerabilities privately](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability)
* Projects **SHOULD** provide an alternative method (e.g. email) to allow private disclosure of vulnerabilities
* **Data Collection and Privacy**:

* Projects that collect data **MUST** document the collection with an opt-out mechanism.
* Projects **MUST** exclude personally identifiable information (PII) from telemetry by default.
* If PII is collected, projects **MUST** publish a Data Processing Notice within 180 days.

Related sections: [11 — Security](#11-security); [15 — Operational Guarantees](#15-operational-guarantees); [10 — Operations and Infrastructure](#10-operations-and-infrastructure).

Expand Down Expand Up @@ -256,7 +256,7 @@ Related sections: [10 — Operations and Infrastructure](#10-operations-and-infr

* Projects **MAY** use LFX Insights for community metrics.

Related sections: [14 — Project Lifecycle and Graduation Criteria](#14-project-lifecycle-and-graduation-criteria); [5 — Governance and Process](#5-governance-and-process); [12 — Funding Acknowledgements](#12-funding-acknowledgements);
Related sections: [14 — Project Lifecycle and Graduation Criteria](#14-project-lifecycle-and-graduation-criteria); [5 — Governance and Process](#5-governance-and-process); [12 — Funding Acknowledgements](#12-funding-acknowledgements).

---

Expand Down Expand Up @@ -286,7 +286,7 @@ Related sections: [15 — Operational Guarantees](#15-operational-guarantees); [
|----------|-----------------|-------|
| **MUST** | ASAP (≤30 days) | TSC |

Projects **MUST** follow the guidelines defined within the [NeoNephos Security Guidelines](../security-guidelines/security-guidelines.md)
Projects **MUST** follow the [NeoNephos Security Guidelines](../security-guidelines/security-guidelines.md), which cover vulnerability disclosure and response, supply chain security, and security transparency.

---

Expand Down Expand Up @@ -379,7 +379,7 @@ The **NeoNephos Foundation** provides baseline operational guarantees for hosted
* **Artifact Hosting**:

* Projects **MUST** publish release artifacts to foundation-controlled registries, package repositories, or distribution systems.
* Projects **SHOULD** sign release artifacts and provide provenance metadata (see [11 — Security](#11-security)).
* Projects **SHOULD** sign release artifacts and provide provenance metadata (see [Security Guidelines §8 — Supply Chain Security](../security-guidelines/security-guidelines.md#8-supply-chain-security)).

* **Domains and DNS**:

Expand Down Expand Up @@ -408,76 +408,7 @@ The **NeoNephos Foundation** provides baseline operational guarantees for hosted

### 15.3 Security and Compliance

#### 15.3.1 Mandatory Compliance Requirements

All projects seeking to become part of NeoNephos **MUST** comply with the following enterprise-wide security and operational requirements.

**Security Policies**

* **Authentication**

* **MUST** enforce Two-Factor Authentication (2FA) for all organization members.
* **SSH Deploy Keys**: No global policy enforced. Projects **SHOULD** disable deploy keys at the organization level. Deploy keys pose security risks; personal or machine accounts with MFA are preferred.

* **GitHub Actions Security**

* **Self-hosted Runners**

* **Repository-level**: **MUST NOT** be enabled.
* **Organization-level**: **SHOULD NOT** be enabled unless necessary, and **MUST** be approved by GitHub Enterprise Cloud account administrators who record decisions via TAC vote.
* Rationale: GitHub-hosted runners are preferred; self-hosted runners require careful setup to avoid exploitation.
* **Fork Pull Request Workflows**

* **MUST** require approval for first-time contributors.
* Purpose: Prevents unauthorized code execution from external contributors.
* **Workflow Permissions**

* Default **MUST** be set to “Read repository contents and packages.”
* Write access **MUST** be explicitly requested via the `permissions` key in workflow files.
* Rationale: Minimizes risk by preventing workflows from gaining unnecessary write access.

**Operational Policies**

* **Data Retention**

* **Private Repositories**: Artifact and log retention **MUST** be configured to 180 days.
* **Public Repositories**: Retention defaults to 90 days (GitHub limitation).

#### 15.3.2 Supplemental Compliance

Any project **SHOULD** abide by following additional guidelines:

**Minimize Overarching Permissions of Maintainers:**

- Only necessary permissions should be provided.
- Limit GitHub Owner access to a few admin accounts
- Limit the number of maintainers with admin permissions
- Ensure settings and permissions changes are made by trusted admins
- Use pull requests for repository changes
- Conduct package releases via CI/CD pipelines (recommend GitHub Actions)
- Have an up-to-date overview of maintainer permissions across different platforms
- Consider preventing maintainers from direct write access, requiring pull request merges from forks.
- Maintainer candidates have a history of contributions for at least 6 months
- Maintainer candidates are known to an existing maintainer
- Maintainer candidates provide a real identity to an existing maintainer in an in person event

**CI/GitHub Actions Hardening:**

- Use GitHub Actions for CI
- Avoid self-hosted runners wherever possible
- Use workload identities/OIDC or short-lived GitHub Access tokens for external interactions
- Utilize fine-grained access tokens if workload identity is unsupported
- Use attestation/signing of packages
- Limit GITHUB_TOKEN permissions to read-only by default
- For other CI systems, consult experts
- Temporary creating access tokens to perform a local batch job can be accepted in exceptional circumstances,
but must they must be deleted afterwards (e.g. max lifetime ~6h)

**Other**

- Use automation (e.g., Dependabot, Renovate) for dependency updates
- Use automation (e.g., CodeQL, SonarQube) for finding code flaws and vulnerabilities
- Implement automatic tests for code validation
For all security and compliance requirements — including infrastructure security controls (2FA, GitHub Actions, runner policies, data retention), supply chain security, and supplemental hardening practices — see the [NeoNephos Security Guidelines](../security-guidelines/security-guidelines.md).

---

Expand Down