You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A 2026-09-11 live re-audit of an older external audit found that WorldScript's current .github/SECURITY.md already has a meaningful vulnerability-disclosure policy:
GitHub Private Vulnerability Reporting is the preferred private channel;
public issues are explicitly discouraged for vulnerabilities;
initial maintainer response target: 72 hours;
default coordinated-disclosure embargo: 90 days;
triage, patching, validation and release coordination occur during embargo;
public advisory follows release/embargo as appropriate.
Therefore the old audit's claim that the repository lacks a security-response process is too broad.
The remaining gap is narrower: there is no durable maintainer operating runbook for going from a private report or detected compromise to evidence-preserving triage, an exact affected-version decision, a safely qualified emergency release, disclosure and post-incident reconciliation.
This issue owns that process contract. It is intentionally P3 because it does not represent a currently known exploitable product defect and must not preempt the active P0/P1 data-integrity/security queue.
Goal
Create a concise, usable solo-maintainer runbook that answers:
A security report/incident arrives
→ what do I do first?
→ what must I preserve?
→ what must I NOT publish/log?
→ how do I determine affected versions/SHAs?
→ how is the fix reviewed and qualified without leaking the issue?
→ how is an emergency release cut without bypassing the trust gates that matter?
→ when/how are users notified?
→ what follow-up becomes durable engineering work?
The runbook should complement .github/SECURITY.md, not duplicate its public reporting policy.
1. Incident classes
Define a small triage taxonomy sufficient for operational decisions, for example:
Do not build a complex CVSS bureaucracy for a solo project. Use CVSS/CWE/GHSA terminology where useful, but severity must drive concrete action.
At minimum distinguish:
EMERGENCY — immediate containment/release decision
HIGH — private remediation before ordinary roadmap work
NORMAL EMBARGOED — standard coordinated disclosure
NOT SECURITY — route to normal issue workflow
2. First-response checklist
For a new private report:
acknowledge receipt through the private channel;
preserve the original report/evidence;
avoid copying secrets/payloads into public issues, Slack-like channels or ordinary logs;
establish whether the report is reproducible and in current scope;
identify the earliest known affected and first-fixed commit/release where possible;
determine whether exploitation is active/credible;
choose containment before broad refactoring;
assign a private advisory/fix owner and decision log.
For suspected active compromise, include immediate containment choices such as disabling an affected hosted endpoint/feature/release path when that reduces harm and is technically justified.
Do not prescribe destructive evidence cleanup as containment.
3. Evidence preservation and privacy
Record only evidence necessary to reproduce/triage.
Never put into normal public artifacts by default:
API keys/tokens;
user passphrases/encryption keys;
manuscript/project contents;
full Claude/AI prompts or responses;
private filesystem paths/user identities where unnecessary;
signing/private keys;
unredacted provider credentials or headers.
Reuse #551's structured-redaction semantics for generated diagnostic evidence where practical.
Preserve exact technical provenance where safe:
commit SHA
tag/release
workflow run/check IDs
package versions/lockfile state
platform/runtime
minimal reproduction class
relevant sanitized logs
4. Affected-version determination
Define how to answer:
CURRENT MAIN AFFECTED?
LATEST STABLE AFFECTED?
WHICH HISTORICAL RELEASES?
WEB/PWA ONLY?
TAURI DESKTOP ONLY?
PROVIDER/HOST SPECIFIC?
PLATFORM SPECIFIC?
Use Git history and tagged release evidence rather than guessing from changelog prose.
Coordinate public supported-version truth with #549.
If the vulnerability exists only in unreleased main, do not publish an advisory claiming released users are affected.
5. Private remediation workflow
Document the preferred GitHub Security Advisory/private-fork flow where available.
The fix should still receive the strongest practical evidence without prematurely disclosing the vulnerability.
Define how to handle:
tests that reveal exploit details;
bot/reviewer systems that may publish comments externally;
CI logs/artifacts that might contain PoCs/secrets;
dependencies requiring upstream coordination;
embargoed commit messages/release notes.
Do not put a live exploit recipe into a public PR merely to preserve the ordinary review style.
At the same time, do not bypass source review/testing entirely because the work is embargoed.
6. Emergency release protocol
An emergency patch release must remain tied to a known source SHA.
Default target:
fixed exact SHA
→ required source/security validation appropriate to the changed surface
→ CodeQL/SAST evidence where applicable
→ Tauri parity/preflight if native dependencies changed
→ package/sign from that exact admitted SHA
→ verify release assets/manifest/signatures
→ publish advisory/mitigation according to disclosure decision
Coordinate release trust with #574 and supply-chain/provenance with #529.
Define a bounded break-glass exception policy only for a genuinely urgent case where waiting for a normal non-security gate increases user harm.
Any break-glass use must record:
which gate was bypassed;
why it was unrelated/unavailable;
compensating evidence;
who/what authorized the decision;
mandatory post-release reconciliation.
Never normalize disabling signature/security/dependency gates merely because the release is urgent.
7. Credential/key compromise
For compromised credentials/signing material/provider secrets, define a provider-specific decision checklist rather than one fake universal rotation command.
At minimum cover categories:
GitHub/repository credentials
hosting/deployment tokens
provider API keys if repository-controlled
Tauri updater signing material
OS signing/notarization credentials when present
registry/package credentials
User BYOK keys are user-controlled; WorldScript must not imply it can rotate users' provider credentials centrally.
If a signing key is compromised, distribution trust/revocation semantics are materially different from an ordinary secret leak — coordinate with #574/#529.
8. Hosted-service incident boundary
WorldScript is primarily local-first but currently has hosted surfaces such as deploy hosting and the Claude serverless proxy on supported web hosts.
The runbook should define what to do if a hosted path is suspected compromised:
disable/rollback affected deployment where safe;
preserve provider/platform evidence;
determine whether request content/secrets could have transited the affected layer;
avoid asserting provider/platform logs do or do not contain content without evidence;
communicate the exact affected runtime (e.g. hosted Claude proxy vs desktop-direct Anthropic) rather than saying all AI is affected.
Public advisory should state, once disclosure is appropriate:
what happened
who/what is affected
which versions/runtimes
impact
fixed version/SHA
mitigation/workaround
whether credential rotation is required
whether data loss/exposure is known vs merely possible
references to released fix
Avoid certainty beyond evidence.
Do not include exploit-enabling details before users have a reasonable remediation path unless coordinated-disclosure norms require otherwise.
10. Post-incident reconciliation
After containment/release:
create/link durable public engineering issues for systemic follow-ups once disclosure permits;
update threat model/security truth if the incident disproved an assumption;
update regression tests/gates only where they provide unique causal prevention;
reconcile dependency/provenance/CI controls where relevant;
record why the defect escaped existing tests/review;
close private advisory only when released/communicated state is accurate.
Do not respond to every incident by adding another broad CI gate. Prefer the smallest authority/gate that prevents the actual defect class.
Suggested artifact
Prefer one concise maintainer document, e.g.:
docs/SECURITY-INCIDENT-RESPONSE.md
linked from .github/SECURITY.md and the documentation hub.
It should be operational, checklist-oriented and versionable. Avoid copying confidential incident records into the repository.
Context
A 2026-09-11 live re-audit of an older external audit found that WorldScript's current
.github/SECURITY.mdalready has a meaningful vulnerability-disclosure policy:Therefore the old audit's claim that the repository lacks a security-response process is too broad.
The remaining gap is narrower: there is no durable maintainer operating runbook for going from a private report or detected compromise to evidence-preserving triage, an exact affected-version decision, a safely qualified emergency release, disclosure and post-incident reconciliation.
This issue owns that process contract. It is intentionally P3 because it does not represent a currently known exploitable product defect and must not preempt the active P0/P1 data-integrity/security queue.
Goal
Create a concise, usable solo-maintainer runbook that answers:
The runbook should complement
.github/SECURITY.md, not duplicate its public reporting policy.1. Incident classes
Define a small triage taxonomy sufficient for operational decisions, for example:
Do not build a complex CVSS bureaucracy for a solo project. Use CVSS/CWE/GHSA terminology where useful, but severity must drive concrete action.
At minimum distinguish:
2. First-response checklist
For a new private report:
For suspected active compromise, include immediate containment choices such as disabling an affected hosted endpoint/feature/release path when that reduces harm and is technically justified.
Do not prescribe destructive evidence cleanup as containment.
3. Evidence preservation and privacy
Record only evidence necessary to reproduce/triage.
Never put into normal public artifacts by default:
Reuse #551's structured-redaction semantics for generated diagnostic evidence where practical.
Preserve exact technical provenance where safe:
4. Affected-version determination
Define how to answer:
Use Git history and tagged release evidence rather than guessing from changelog prose.
Coordinate public supported-version truth with #549.
If the vulnerability exists only in unreleased
main, do not publish an advisory claiming released users are affected.5. Private remediation workflow
Document the preferred GitHub Security Advisory/private-fork flow where available.
The fix should still receive the strongest practical evidence without prematurely disclosing the vulnerability.
Define how to handle:
Do not put a live exploit recipe into a public PR merely to preserve the ordinary review style.
At the same time, do not bypass source review/testing entirely because the work is embargoed.
6. Emergency release protocol
An emergency patch release must remain tied to a known source SHA.
Default target:
Coordinate release trust with #574 and supply-chain/provenance with #529.
Define a bounded break-glass exception policy only for a genuinely urgent case where waiting for a normal non-security gate increases user harm.
Any break-glass use must record:
Never normalize disabling signature/security/dependency gates merely because the release is urgent.
7. Credential/key compromise
For compromised credentials/signing material/provider secrets, define a provider-specific decision checklist rather than one fake universal rotation command.
At minimum cover categories:
User BYOK keys are user-controlled; WorldScript must not imply it can rotate users' provider credentials centrally.
If a signing key is compromised, distribution trust/revocation semantics are materially different from an ordinary secret leak — coordinate with #574/#529.
8. Hosted-service incident boundary
WorldScript is primarily local-first but currently has hosted surfaces such as deploy hosting and the Claude serverless proxy on supported web hosts.
The runbook should define what to do if a hosted path is suspected compromised:
Cross-surface claim wording belongs to #549.
9. User communication / advisory
Public advisory should state, once disclosure is appropriate:
Avoid certainty beyond evidence.
Do not include exploit-enabling details before users have a reasonable remediation path unless coordinated-disclosure norms require otherwise.
10. Post-incident reconciliation
After containment/release:
Do not respond to every incident by adding another broad CI gate. Prefer the smallest authority/gate that prevents the actual defect class.
Suggested artifact
Prefer one concise maintainer document, e.g.:
linked from
.github/SECURITY.mdand the documentation hub.It should be operational, checklist-oriented and versionable. Avoid copying confidential incident records into the repository.
Relationships
Acceptance criteria
.github/SECURITY.mdlinks to a maintainer incident-response runbook without duplicating the public reporting policy.Non-goals