Skip to content

Introduce Sandbox Stage in project lifecycle policy - #10

Merged
fmui merged 3 commits into
mainfrom
lifecycle-doc-sandbox-stage
May 11, 2026
Merged

Introduce Sandbox Stage in project lifecycle policy#10
fmui merged 3 commits into
mainfrom
lifecycle-doc-sandbox-stage

Conversation

@CowFreedom

@CowFreedom CowFreedom commented Apr 8, 2026

Copy link
Copy Markdown
Contributor

Situation

We currently have four stages: Incubation, Growth, Graduated and Emeritus.
Many other foundations have an additional stage, called Sandbox.

This stage is for projects that are either experimental or too nascent for Incubation.

The Sandbox stage is a low threshold way for projects to join our foundation. To not have projects build up in this stage, a Sandbox project must become compatible to the other stages quickly.

Why do we need a low threshold way to join?

It can be reasonably expected that there are interesting projects that want to apply for NeoNephos inclusion but are in a very early stage. Nevertheless, it could be useful to have them in the "NeoNephos portfolio", in order to nurture them "from the start". Lastly, some of our projects might come from initiatives (e.g. IPCEI-CIS, IPCEI-AI) and are experimental. We might still want to have them as we know they will be worthwhile to our ecosystem.

Why not use Incubation?

The Incubation stage usually places additional requirements in terms of governance, openssf badging and community contributions. Since NeoNephos' stage requirements are still in flux, it is expected that our Incubation stage will also be strengthened. Sandbox would then remain the only low threshold way for projects to join the foundation (on a trial basis).

Precedence

Next to LF Energy , the CNCF is another prominent foundation with this kind of setup (Note: CNCF has no growth stage).

@CowFreedom
Introduce Sandbox Stage in project lifecycle policy
b12bcd9 
Added 'Sandbox Stage' section with definitions, examples, expectations, acceptance criteria, approval process, and benefits for projects.
@CowFreedom
CowFreedom requested a review from a team April 8, 2026 11:31
fmui
fmui reviewed Apr 10, 2026
View reviewed changes
Comment thread lifecycle-policy/project-lifecycle-policy.md Outdated

##### Expectations

A project can remain a Sandbox project for a maximum of one year.

@fmui fmui Apr 10, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Could we add here, that sandbox projects are experimental and their outputs are not intended for end‑user or production use. Projects that release production‑ready artifacts should transition to a more mature stage.

@jakobmoellerdev jakobmoellerdev Apr 10, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I think a project can already have production use without it being accepted into incubation. I dont see this as an issue tbh. I thought project stage can declare maturity, but who are we to judge if someone uses the project in production?

@fmui fmui Apr 10, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

It's not meant to be rule, it's more about setting expectations. Sandbox projects may already be used in production (however we define that). But the default end-user expectation should be that this is unfinished software.

@jakobmoellerdev jakobmoellerdev Apr 10, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Agreed totally on that caution note, makes sense 💯

@CowFreedom CowFreedom Apr 10, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Good additions, added to the expectations chapter.

@fmui

fmui commented Apr 10, 2026

Copy link
Copy Markdown
Contributor

+1
Adding a sandbox stage makes sense to lower the barrier for entering into the foundation.

@CowFreedom
Update Sandbox project expectations in lifecycle policy
9e6810e 
Clarified the definition and expectations for Sandbox projects, emphasizing their experimental nature and production readiness.
jmertic
jmertic reviewed Apr 29, 2026
View reviewed changes
Comment thread lifecycle-policy/project-lifecycle-policy.md

##### Expectations

A project can remain a Sandbox project for a maximum of one year. Sandbox projects are experimental and their output is not intended to be used in production. Projects that release production-ready artifacts should transition to a more mature stage.

@jmertic jmertic Apr 29, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

You might want to give the TAC some wiggle room here that allows the TAC to extend being in Sandbox longer under certian circumstances.

@CowFreedom CowFreedom May 5, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

What do you think about:

A project can remain a Sandbox project for a maximum of one year unless extended by the TAC.

jmertic
jmertic reviewed Apr 29, 2026
View reviewed changes
Comment thread lifecycle-policy/project-lifecycle-policy.md
* Submission of the Project Proposal, as defined above.
* A TAC sponsor to champion the project and provide mentorship as needed.
* Have a charter document with an intellectual property policy that leverages open licenses, including, in the case of contributions of code, the use of one or more licenses approved as "open" by the Open Source Initiative. The staff of the NeoNephos Foundation can assist projects in preparing a technical charter following the NeoNephos Foundation’s standard template.
* In the case of existing projects, an agreement to transfer the project name and electronic account assets (source code repository, social media accounts, domain names, etc.) to Linux Foundation Europe for the benefit of the NeoNephos Foundation.

@jmertic jmertic Apr 29, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

L126-L130 likely should be changed, as this is the same requirement for Sandbox

@CowFreedom CowFreedom May 5, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Yes, that is correct.

jmertic
jmertic reviewed Apr 29, 2026
View reviewed changes
Comment thread lifecycle-policy/project-lifecycle-policy.md

To be considered for the Sandbox Stage, the project must meet the following requirements:
* Submission of the Project Proposal, as defined above.
* Have a charter document with an intellectual property policy that leverages open licenses, including, in the case of contributions of code, the use of one or more licenses approved as "open" by the Open Source Initiative. The staff of the NeoNephos Foundation can assist projects in preparing a technical charter following the NeoNephos Foundation’s standard template.

@jmertic jmertic Apr 29, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

I'd recommend replacing L94-95 with:

  • Complete and approve the Technical Charter and agree to transfer any relevant trademarks and/or assets to Linux Foundation Europe, and to assist in filing for any relevant unregistered ones.

@CowFreedom CowFreedom May 5, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Sounds good, thanks.

morri-son added a commit to morri-son/guidelines-development that referenced this pull request May 5, 2026
@morri-son
address PR review feedback from Skarlso
5df2757 
- 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 neonephos#10 (secret scanning only, push
  protection is SHOULD) and neonephos#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 <gerald.gm.morrison@gmail.com>
@morri-son morri-son mentioned this pull request May 5, 2026
Merged
@fmui
fmui merged commit c337ab9 into main May 11, 2026
morri-son added a commit to morri-son/guidelines-development that referenced this pull request Sep 14, 2026
@morri-son @morrison-sap
address PR review feedback from Skarlso
738d748 
- 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 neonephos#10 (secret scanning only, push
  protection is SHOULD) and neonephos#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 <gerald.gm.morrison@gmail.com>
Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>
jakobmoellerdev pushed a commit that referenced this pull request Sep 14, 2026
@morri-son @ScheererJ @morrison-sap
docs: add security guidelines and SECURITY.md template (#7)
ef07f6a 
* docs: add security guidelines and SECURITY.md template

Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>

* docs: improve practicality of security docs — make guidelines livable

- 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

Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>

* docs: relax supply chain resolution timelines to match project maturity

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.

Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>

* docs: integrate PR feedback — add operational security controls, OpenSSF Scorecard, and template improvements

- Relax SECURITY.md link requirement to support org-level .github repos (nexus49)
- Clarify supported versions as a version support policy, not branch names (nexus49)
- Add §10 Operational Security Controls reworked from Project Guidelines §15.3:
  authentication, CI/CD security, access governance, code scanning, data retention
- Frame maintainer vetting criteria as supply-chain trust controls (§10.3)
- Add §10.6 OpenSSF Scorecard recommendation (jmertic)
- Update scope, introduction, and TOC; renumber Acknowledgements to §11
- Add org-level SECURITY.md guidance note to template

Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>

* 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 <gerald.gm.morrison@gmail.com>
Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>

* docs: add container image scanning and license compliance scanning sections

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.

Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>

* 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.

Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>

* docs: trim implementation details, add SLA rationale and exemplary project references

- 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)

Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>

* consolidate section 8, Revise introduction statement and point to OpenSSF

Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>

* add link to openssf Vulnerability Disclosure Guide

Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>

* soften SLAs

Signed-off-by: Gerald Morrison <gerald.gm.morrison@gmail.com>
Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>

* 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 <gerald.gm.morrison@gmail.com>
Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>

* 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 <gerald.gm.morrison@gmail.com>
Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>

* make push protection a MUST

Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>

* Update security-guidelines/security-guidelines.md

Co-authored-by: Johannes Scheerer <johannes.scheerer@sap.com>
Signed-off-by: Gerald Morrison <67469729+morri-son@users.noreply.github.com>
Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>

* docs: clarify security guidelines scope is dev/build/release lifecycle

Addresses ScheererJ review comment on §3 (PR #7): "operational security
controls" was ambiguous. Adds an explicit sentence stating the doc covers
the development, build, and release lifecycle, and that runtime security
of services deployed by consumers is out of scope.

Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>
On-behalf-of: Gerald Morrison (SAP) <gerald.morrison@sap.com>
Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>

* docs: spell out CVSS judgment criteria in §7

Addresses ScheererJ review comment on §7 (PR #7). Replaces vague
"maintainers MAY exercise judgment" with concrete examples (mitigating
default configurations, evidence of active exploitation) and requires
any deviation from the raw CVSS score to be documented in the published
advisory together with the original score and rationale.

Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>
On-behalf-of: Gerald Morrison (SAP) <gerald.morrison@sap.com>
Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>

* docs: tie SCA scan frequency and visibility to OpenSSF Baseline

Addresses ScheererJ review comment on §8.4 (PR #7). The previous
"projects MUST scan dependencies" did not specify frequency or whether
results have to be visible. Aligns with OpenSSF Baseline OSPS-VM-05.03
(per-change evaluation against a documented threshold, with blocking
on violations) instead of inventing a calendar cadence. Adds a SHOULD
that scan results are surfaced via the platform's native mechanism
(Dependabot alerts, GitLab Security dashboard) so conformance is
externally verifiable.

Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>
On-behalf-of: Gerald Morrison (SAP) <gerald.morrison@sap.com>
Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>

* docs: anchor license allowlist to TSC + foundation licensing policy

Addresses ScheererJ review comment on §8.4 (PR #7). Each TSC defines
its own allowlist, but the allowlist must be compatible with the
project's own license and Project Guidelines §6.

Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>
On-behalf-of: Gerald Morrison (SAP) <gerald.morrison@sap.com>
Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>

* docs: scope 2FA and deploy-key controls to SCM/CI/registry plane

Addresses ScheererJ review comments on §9.1 (PR #7). "Organization
members" and "organization level" were too generic. Restricts both
controls to the project's source-control, CI/CD, and artifact-publishing
accounts (GitHub/GitLab organizations, container and package
registries) — i.e., the systems where unauthorized access could lead
to malicious code or artifacts being shipped.

Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>
On-behalf-of: Gerald Morrison (SAP) <gerald.morrison@sap.com>
Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>

* docs: note Dependabot/Renovate update SHA-pinned actions automatically

Addresses ScheererJ review comment on §9.2 (PR #7). SHA pinning is
compatible with automated update tooling — Dependabot updates the SHA
and keeps a version comment, Renovate has pinDigests. Adds links to
both so it's clear automation is not lost.

Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>
On-behalf-of: Gerald Morrison (SAP) <gerald.morrison@sap.com>
Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>

* docs: anchor org owner count and clarify repo admin role in §9.5

Addresses ScheererJ review comments on §9.5 (PR #7). "Small number"
and "limit admin permissions" were not actionable.

- Organization owners: anchored to a concrete range (2-5), required to
  be human named accounts with 2FA enforced.
- Repository admin: reframed around intent — admin is for repository
  configuration (branch protection, secrets, releases); routine
  review/merge work belongs in the maintain or write role.

Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>
On-behalf-of: Gerald Morrison (SAP) <gerald.morrison@sap.com>
Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>

* docs: restructure maintainer vetting criteria into numbered list

Addresses ScheererJ review comment on §9.5 (PR #7) which suggested
upgrading SHOULD to SHALL.

Priority kept at SHOULD: OpenSSF Scorecard has no maintainer-vetting
check, the OpenSSF Vulnerability Disclosure maintainer guide only says
"select trusted maintainers" without normative wording, and OpenSSF
Baseline access controls (OSPS-AC-*) are at the organization level
rather than individual onboarding. There is no upstream MUST/SHALL for
this control today, so the priority is not upgraded ahead of OpenSSF
or peer foundations.

Restructured the three criteria (sustained contributions, vouching,
identity verification) into a numbered list so each is auditable, and
allowed video-call verification against a previously verified identity
as an equivalent to in-person verification.

Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>
On-behalf-of: Gerald Morrison (SAP) <gerald.morrison@sap.com>
Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>

* docs: add threat-modelling references to §9.7

Addresses ScheererJ review comment on §9.7 (PR #7). Lists STRIDE, the
OWASP Threat Modeling Process, and the CNCF Cloud Native Security
Whitepaper as accepted methodologies, and points to the OpenSSF
security-reviews repository for example reviews.

Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>
On-behalf-of: Gerald Morrison (SAP) <gerald.morrison@sap.com>
Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>

* docs: clarify Resolution column reference date in §10

Addresses ScheererJ review comment on §10 (PR #7). The Resolution
timeline is measured from the latest of: the requirement's effective
date, the project's onboarding date, or the lifecycle stage at which
the requirement applies. Effective dates for new or amended
requirements are set by the TAC.

Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>
On-behalf-of: Gerald Morrison (SAP) <gerald.morrison@sap.com>
Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>

* docs: clarify multi-repo SECURITY.md fall-through (GitHub vs GitLab)

Addresses ScheererJ review comment on templates/SECURITY.md (PR #7):
"Is a single SECURITY.md on the organisation level enough for a
multi-repo project or not?"

On GitHub, a SECURITY.md in the organization's .github repository is
automatically used by every repository without its own — this
satisfies the per-repository requirement, except where a repository
needs its own intake link or contacts. GitLab has no equivalent
fall-through, so each GitLab project needs its own SECURITY.md.

Spelled out in both the security guidelines (§5.2) and the
templates/SECURITY.md comment block.

Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>
On-behalf-of: Gerald Morrison (SAP) <gerald.morrison@sap.com>
Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>

* docs: add EU Cyber Resilience Act (CRA) compliance requirements

- Add §11 explaining CRA stewardship framework and NeoNephos responsibilities
- Include simplified CRA stewardship statement per LF guidance
- Document escalation procedure for actively exploited vulns/severe incidents
- Update Quick-Start Checklist and Conformance Matrix with CRA tasks
- Add CRA section to SECURITY.md template

Per guidance from John Mertic (jmertic@linuxfoundation.org):
- LF steward email: steward@linuxfoundation.org
- Stewardship statement is standardized across all LF projects
- LF handles regulatory reporting; projects document commercial intent
- See https://www.linuxfoundation.org/security for details

Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>
On-behalf-of: Gerald Morrison (SAP) <gerald.morrison@sap.com>
Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>

---------

Signed-off-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>
Signed-off-by: Gerald Morrison <gerald.gm.morrison@gmail.com>
Signed-off-by: Gerald Morrison <67469729+morri-son@users.noreply.github.com>
Co-authored-by: Johannes Scheerer <johannes.scheerer@sap.com>
Co-authored-by: Gerald Morrison (SAP) <gerald.morrison@sap.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@jmertic jmertic jmertic left review comments
@jakobmoellerdev jakobmoellerdev jakobmoellerdev approved these changes
@fmui fmui fmui approved these changes
@c0ffee c0ffee c0ffee approved these changes
@hardl hardl hardl approved these changes
@ScheererJ ScheererJ ScheererJ approved these changes

Assignees

@jmertic jmertic

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

7 participants

@CowFreedom @fmui @jmertic @c0ffee @hardl @ScheererJ @jakobmoellerdev