Repository navigation
Update project-logo-guidelines.md - #12
Merged
Merged
Conversation
Signed-off-by: banannadreams <a.helmke@sap.com>
CowFreedom
reviewed
May 19, 2026
|
|
||
| ## Introduction | ||
|
|
||
| These logo guidelines only relate to projects that can provide a logo themselves. |
Contributor
There was a problem hiding this comment.
I would cut this sentence. This guideline applies for all projects. Those that have no logo just outsource the implementation of this guideline to the assigned designer. But they still adhere to it.
deleted first sentence Signed-off-by: banannadreams <a.helmke@sap.com>
fmui
approved these changes
May 19, 2026
jakobmoellerdev
approved these changes
May 19, 2026
morri-son
added a commit
to morri-son/guidelines-development
that referenced
this pull request
Sep 14, 2026
- 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
* 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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
changed the into for the guidelines to make sure it's clear to the project that we're supporting with logo and they don't have to have one.