docs: add SECURITY.md

[Mesut Oezdil (mesutoezdil)]

Most open-source projects include a SECURITY.md so contributors and users know how to report vulnerabilities without opening a public issue.
This repo currently has no such file, which means reporters have no obvious path and may default to opening a public issue instead, which exposes the vulnerability before a fix is ready.

This PR adds a minimal SECURITY.md that covers:

• A private reporting path (GitHub Advisory + ate-dev mailing list)
• Severity-based response time targets, honest about the team size
• Supported versions (none yet, main only)
• Scope: what is and is not covered

[Benjamin Elder (BenTheElder)]

I'm not sure how we want to handle these yet, but it seems premature while the repo is in pre-alpha state to issue vulns etc ...

[Mesut Oezdil (mesutoezdil)]

I'm not sure how we want to handle these yet, but it seems premature while the repo is in pre-alpha state to issue vulns etc ...

i can close this and reopen once the team has decided how to handle sec reports. alternatively, if you want a placeholder that just points to github advisory and omits the response time targets, i can simplify it to that. up2yu.

[Mesut Oezdil (mesutoezdil)]

Michael Taufen (@mtaufen) gentle nudge, would you have a moment to take a look?

[Mesut Oezdil (mesutoezdil)]

Haven Xia (@HavenXia) This one adds SECURITY.md, could you take a look when you have a moment?

[Michael Taufen (mtaufen)]

+1 thanks for sending this, having something even this basic is important. However there's some nuance of what we want to support while the project is in an immature state.

We should discuss this in the community meeting, particularly:

• When do we consider the project mature enough for this process to make sense? GA?
• Do we want to incentivize reports with a bounty? K8s has HackerOne.
• How will we handle triage? K8s has SRC.
• How do we want to announce vulns (privately and publicly)? Private mailing list of trusted vendors, and then ate-dev@?
• What SLOs do we consider reasonable?
• How do we want to handle embargos?
• What will the patching/release process look like? K8s has a very mature process, Substrate has virtually none.

There are probably some other things I missed.

I think it could work to have something like the below while we're in a preview state, and then improve as part of GA milestone:

• Report via advisories
• No bounty
• Google maintainers (who own the repo) do triage and fix
• No mailing list announcements
• No SLOs on fixes
• No embargos
• Patching/release is best effort, but all valid reports need to be patched by GA

[Mesut Oezdil (mesutoezdil)]

+1 thanks for sending this, having something even this basic is important. However there's some nuance of what we want to support while the project is in an immature state.

We should discuss this in the community meeting, particularly:

• When do we consider the project mature enough for this process to make sense? GA?
• Do we want to incentivize reports with a bounty? K8s has HackerOne.
• How will we handle triage? K8s has SRC.
• How do we want to announce vulns (privately and publicly)? Private mailing list of trusted vendors, and then ate-dev@?
• What SLOs do we consider reasonable?
• How do we want to handle embargos?
• What will the patching/release process look like? K8s has a very mature process, Substrate has virtually none.

There are probably some other things I missed.

I think it could work to have something like the below while we're in a preview state, and then improve as part of GA milestone:

• Report via advisories
• No bounty
• Google maintainers (who own the repo) do triage and fix
• No mailing list announcements
• No SLOs on fixes
• No embargos
• Patching/release is best effort, but all valid reports need to be patched by GA

Thanks, makes sense, reworked the doc to match your preview-state proposal and moved the open questions into a "Road to GA" section for the community meeting.
Also added a Substrate-specific threat model, a non-qualifying issues list, a good-faith research statement, and a dependency policy based on the existing govulncheck CI. PTAL.

[Michael Taufen (mtaufen)]

Discussion in community meeting was overall aligned with best-effort until GA, and formal process as a GA blocker. I'll review this PR in detail later today.

[Michael Taufen (mtaufen)]

Had just one more minor comment, then I think we're good to merge.

[Mesut Oezdil (mesutoezdil)]

Had just one more minor comment, then I think we're good to merge.

Had just one more minor comment, then I think we're good to merge.

Thx! PTAL