docs: add security guidelines and SECURITY.md template

[morri-son]

Initial proposal for security guidelines and SECURITY.md template to be used in every repository.

[nexus49]

Should we also move the Operational Security aspects from here: https://github.com/neonephos/guidelines-development/blob/main/project-guidelines/project-guidelines.md#153-security-and-compliance

into this document?

[jmertic]

I think it would be a lot easier to just adopt using the OpenSSF Scorecard, which will do checks to align with best practices.

https://github.com/ossf/scorecard

[morri-son]

@jmertic

I think it would be a lot easier to just adopt using the OpenSSF Scorecard, which will do checks to align with best practices.

https://github.com/ossf/scorecard

I created a section 10.6 Automated Security Posture Verification that links to the OpnSSF scorecard.

[morri-son]

@nexus49

Should we also move the Operational Security aspects from here: https://github.com/neonephos/guidelines-development/blob/main/project-guidelines/project-guidelines.md#153-security-and-compliance

into this document?

I copied the content over from §15.3 and reworked with conformance tables, cross-references to §8, and proper MUST/SHOULD language

[jmertic]

@morri-son Good question. Generally we see projects adopt the OpenSSF Best Practices Badge ( https://www.bestpractices.dev/ ) and map to the various tiers ( for example, Passing Badge for Incubation, Gold for Graduated ). The Scorecard could be then a tool to manage ongoing alignment, just in the same way LFX Insights is used for measuring contributions.

Let me know your thoughts...

[morri-son]

@jmertic

@morri-son Good question. Generally we see projects adopt the OpenSSF Best Practices Badge ( https://www.bestpractices.dev/ ) and map to the various tiers ( for example, Passing Badge for Incubation, Gold for Graduated ). The Scorecard could be then a tool to manage ongoing alignment, just in the same way LFX Insights is used for measuring contributions.

Let me know your thoughts...

I added https://github.com/neonephos/guidelines-development/pull/7/changes#diff-1c57ac02b0e896c0a58ee0a4467770159c4a4c5b0e2c6c0e7b2ad989c4d73cd0R353-R364. Pls check if this fits your idea.

[jmertic]

Hi @morri-son I still think we are just restating things already covered in existing materials.

Take a look at the TAC site in progress ( https://special-couscous-6qv9rv3.pages.github.io/best_practices/repo.html ) and let me know your thoughts.

[morri-son]

@jmertic

Take a look at the TAC site in progress ( https://neonephos.github.io/tac/ ) and let me know your thoughts.

link gives 404. But apart from anything proposed there, I guess we can keep best-practices in topic specific repos instead of always linking them to a central best practices doc, or? I would vote for keeping it in the SECURITY.md for the time being, getting it merged and evolve it over time.

[jmertic]

@morri-son Sorry - changed the URL to https://neonephos.github.io/tac/. LMK if that doesn't work for you.

[morri-son]

OpenSSF Security Baseline Alignment (commit d7b21b0)

Cross-referenced the security guidelines against the OpenSSF Security Baseline (OSPS), the OpenSSF Concise Guide, and the OpenSSF SCM Best Practices. Added the following based on identified gaps:

New sections

Section	Priority	OSPS Controls	Summary
§10.3 Branch Protection	MUST	AC-03.01/02 (L1), QA-07.01 (L3)	No direct commits, no force push, no branch deletion, require non-author review, status checks before merge
§10.4 Secret Scanning and Prevention	MUST	BR-07.01 (L1)	Enable secret scanning + push protection; platform-specific guidance for GitHub, GitLab, and others
§10.8 Security Assessment	SHOULD	SA-03.01 (L2), SA-03.02 (L3)	Lightweight threat model and trust boundary identification at Growth/Graduated stage (mirrors CNCF TAG-Security practice)

Strengthened existing sections

Section	Change	OSPS Controls
§10.2 CI/CD Security	Added pipeline input sanitization, action pinning by SHA, restrict to verified/allowlisted actions	BR-01.01 (L1), Scorecard Pinned-Dependencies
§10.6 Code Quality (renumbered from 10.4)	Added SAST severity threshold and CI gate/block requirement	VM-06.01/06.02 (L3)
§8.2 Build Provenance	Added provenance verification instructions for consumers	DO-03.01/03.02 (L3)
§9 Security Transparency	Added release changelog security-flagging requirement	BR-04.01 (L2)
§4 Scope	Added OpenSSF Security Baseline mapping note	—

Design decisions

• MUST level reserved for Level 1 OSPS controls (branch protection, secret scanning) — these are baseline for any project.
• SHOULD for Level 2/3 controls — proportionate to project maturity.
• §10.8 Security Assessment scoped to Growth/Graduated only — consistent with CNCF practice where self-assessments are required at Incubation and joint assessments at Graduation.
• All additions link to upstream OpenSSF docs rather than duplicating content.
• Sections renumbered: old §10.3→10.5, §10.4→10.6, §10.5→10.7, §10.6→10.9.

[morri-son]

@jmertic yes, that was a working link :-) And yes, you're right, the doc mentions things that are available at various other places. I took over many things from OpenSSF docs.

But I'm not sure, what an enduser should do with https://neonephos.github.io/tac/best_practices/documentation.html#security or with looking at the mentioned OpenSSF docs when it comes to understand what needs to be done to onboard to Neonephos. I'm fine with cross referencing docs, either in the NeoNephos repo and external ones like OpenSSF, whenever possible we should deduplicate docs.

But if I would be an enduser that needs to secure his repo(s) for joining the NeoNephos foundation, then I would like to have one central security guide that I can follow start to end.

[jmertic]

I'd advise against "NeoNephos" specific security guidance; this world is fast moving, and leaning on a group with expertise in this space is best advised versus doing work in silo.

What I have seen done, which could be helpful, is showcasing a few projects who have done this well that could be an inspiration to others. But overindexing on specific requirements is going to be a neverending cycle, and most projects I work with tend to yield that to expert guidance and focus more on the domain expertise they have.

[morri-son]

@jmertic, sorry for the longer answer, but there are quite some things to explain :-)

Adopted from your feedback:

• Doc now explicitly adopts OpenSSF as the baseline — every section references authoritative sources (OSPS control IDs, SCM Best Practices, Concise Guide) instead of restating how-to content.
• Initial response timeline aligned to the OpenSSF Best Practices Badge 14-day standard, replacing our custom 3+7 day split.
• Dependency, container, and license scanning merged into a single SCA section (§8.4), matching how OpenSSF and tooling (Trivy, Grype, Black Duck) treat these.
• Exemplary project references added: Gardener for SECURITY.md, Open Component Model for CI/CD and Scorecard.

What remains NeoNephos-specific are things OpenSSF explicitly delegates to adopting organizations: severity-based response SLAs (§7, benchmarked against Envoy/GitLab/Chainguard), a conformance model tied to lifecycle stages, and platform-specific guidance (GitHub/GitLab/other) that abstract standards can't provide.

Why not the TAC site today: Most of the 13 NeoNephos projects have no SECURITY.md or use vendor boilerplate. The TAC site's security section lists three badge links with no actionable path for maintainers. Happy to revisit when that evolves — today, projects need a self-contained guide to actually get this done.

[morri-son]

@jmertic I tried to incorporate your feedback again and cut the doc by a lot (from ~500 to ~300 lines) 🙂

The guidelines now state what NeoNephos requires and link to OpenSSF for the how — no more restating existing materials.

Removed: all platform-specific subsections (deferred to SECURITY.md template), Data Retention (no OpenSSF precedent), 13 inline conformance tables (single matrix appendix)

Added: Quick-Start Checklist with 12 MUSTs deep-linked to exact subsections — a team can scan it in 30 seconds. Conformance table that sums up all requirements at the end, moving them from tables scattered inline throughout each section.

On strictness: Audited all MUSTs against OpenSSF. 20 of 24 align directly. The 4 that are stricter (SECURITY.md file, CVSS in advisories, non-author review, 90-day embargo ceiling) are things OpenSSF delegates to adopting organizations. They are best practices from other large OS project like Google's Project Zero.

On Scorecard: Referenced in Section 9.7 as a SHOULD. It covers repo config checks; the guidelines cover process (response SLAs, disclosure). Complementary, not alternatives.

Pls check if this now comes closer to what you envisioned. I still stand to my point that especially for security requirements teams and projects should have a single entry point/doc with an easy to copy template that they can adopt.

[Skarlso]

I would like to clarify a couple of things here. The more pressing one is the timeline, the templating with italic and the discrepancies between MUST and SHOULD for CVEs. The rest if UX.