Do not publish sensitive vulnerability details, raw SMS, credentials, tokens, private keys, usable enrollment artifacts, personal payment data, exploit payloads, or operational topology details in public issues, pull requests, logs, screenshots, CI output, or release notes.

GitHub private vulnerability reporting is currently disabled for this repository. It must be enabled by a repository administrator before any supported release can claim a private reporting channel. Once it is enabled, use the repository's Security tab and Report a vulnerability form.

Until then, do not publish a sensitive report here and do not open a public issue or advisory as a substitute. Share only the minimum contact information through an already verified private maintainer channel. A maintainer who receives a report must move it into the GitHub private-report workflow as soon as that workflow is available. This policy does not create a mailbox, request real findings in fixtures, or authorize a public disclosure.

GitHub public issues are permitted only for a sanitized report: affected released version, high-level impact, and a synthetic reproduction without exploit payloads or sensitive details. Use the bug-report template and do not include anything prohibited above. A maintainer must move a report that needs private details to the verified private maintainer channel instead.

No production-supported release currently exists. The checked-in Laravel and Flutter code, main branch, pull-request artifacts, and debug APKs are prototype or test evidence, not a supported security-release channel.

Before declaring a supported version, maintainers must publish its immutable release identity, support window, private reporting route, release authority, and user upgrade path. Until then, this policy does not promise a security fix or patch timeline for prototype artifacts.

The security triage owner classifies a confirmed report using impact, exploitability, affected supported artifacts, and known exploitation:

“Not reproducible” is not a severity. It is an investigation state. A scanner, advisory-feed, registry, or Docker failure is also not a clean result; it blocks the security evidence that depends on it.

On receipt, a credible report that could be Critical or High receives a provisional severe classification. The release owner pauses promotion of an affected candidate until triage confirms the severity, rules it out, or records evidence that the candidate is not affected. The seven-calendar-day assessment target never authorizes promotion while that provisional pause remains active.

The current maintainer rotation must assign these roles before accepting a private report: a security triage owner, a backup triage owner, a release owner, and an incident coordinator. The roster stays in the maintainers' private operating record; public documentation names responsibilities rather than personal contact details.

These are sustainable response targets, not a 24/7 availability promise:

• acknowledge a private report within two business days;
• record an initial severity and reproduction decision within seven calendar days of acknowledgement;
• for Critical reports, convene the triage and release owners within one calendar day of confirmation and record the containment/release decision;
• for High reports, record the remediation or containment plan within seven calendar days of confirmation; and
• send the reporter a material-status update at least every seven calendar days until coordinated disclosure or closure.

If a target cannot be met, the incident coordinator records the reason, current risk, next update date, and escalation to the backup owner in the private report. No target permits publication of sensitive details.

Keep the report, reproducer, affected versions, and advisory draft private until the triage owner and reporter agree on a disclosure plan, or maintainers document why immediate disclosure is necessary to protect users. Obtain credit preferences before naming a reporter. The advisory must identify affected and patched versions, user action, mitigations, and the release evidence without reproducing a harmful payload. Do not publish customer data, credentials, tokens, raw SMS, keys, or internal topology.

For a confirmed issue, maintainers create a private advisory draft, link the fix and minimal regression evidence, decide the patched-release date with the release owner, notify affected users through approved channels, then publish only the reviewed advisory. A synthetic tabletop is documented in docs/security-report-tabletop.fixture.md; it is not an advisory and must never be submitted to GitHub.

For a confirmed Critical or High issue affecting a release candidate or supported artifact:

These steps do not create release, rollback, or emergency authority. Until a repository administrator documents approval of an emergency-release authority for the incident under the release-protection decision, release owners may prepare evidence only.

1. The incident coordinator opens a private record, assigns the triage and release owners, and freezes promotion of affected candidate artifacts.
2. The triage owner confirms scope with the minimum safe reproduction and records containment. Do not paste sensitive material into the record.
3. If a repository credential, signing key, protected release identity, or other release authority may be compromised, contain that authority before preparing a patch: revoke or rotate the credential, recover protected keys, restore a trusted release identity, and rebuild from a restored trust root. Do not publish through a possibly compromised path.
4. For immediate containment, the release owner may execute a rollback before a patch exists only under that documented administrator approval, after identifying the rollback artifact, recording why it predates the affected artifact and contains the incident, and verifying ordinary release authority—or restored authority if step 3 invoked the compromise response. The coordinator records the rollback decision and user communication in the private record.
5. The release owner prepares the smallest remediation, with a regression test where safe, and reviews affected trust boundaries and dependencies.
6. Build, test, scan, and identify the patched artifacts using the normal Docker-backed release evidence; unavailable scanners or evidence fail the release decision visibly.
7. After the artifact evidence is available, the incident coordinator prepares a private advisory draft, links the fix and minimal regression evidence, and the release owner records the patched-release date.
8. A patched release may proceed only under documented administrator release authority and after verifying ordinary release authority—or, if step 3 invoked the compromise response, after the restored authority is verified under the repository's approved release authority. The coordinator then records user communication and the advisory decision.
9. After containment, conduct a blameless review and update this policy, the threat model, tests, or release controls when evidence shows a gap.

This procedure does not bypass branch protection, create real advisories, modify repository settings, or turn a prototype into a production claim.

Every confirmed issue receives a minimal regression test before closure when safe. If a regression test would itself create unsafe exploit material, the triage owner records a safer repeatable substitute, its evidence, and why the test is unsafe in the private record. Closure requires evidence that the fix, mitigation, or accepted product decision addresses the reported behavior.

Review docs/threat-model.md after any significant architecture, identity, authorization, cryptographic, privacy, dependency, deployment, telemetry, recovery, or other trust-boundary change. The review must state the affected asset or boundary, abuse case, control, residual risk, and whether a regression test or release gate changed.