Do not open a public issue, discussion, or pull request for a suspected unpatched vulnerability, exposed secret, customer-data disclosure, or active security incident.

Use one of these private paths:

• Cubewise Asia personnel: the approved internal security/incident channel and the responsible engineering manager or ISMS owner.
• Customers and partners: the existing contractual Cubewise support channel.
• External reporters: GitHub Private Vulnerability Reporting through the repository's Security tab when enabled; otherwise use the Cubewise contact form and request a private security-reporting channel without including exploit details in the initial message.

If there is immediate risk of active compromise, state that clearly through the private channel so the incident process can begin without waiting for a complete technical report.

Provide only through the approved private channel:

• affected repository, product, version, commit, endpoint, or component;
• a concise description of the weakness and potential impact;
• prerequisites and reproducible steps or a minimal proof of concept;
• whether exploitation or data exposure has been observed;
• suggested mitigation if known;
• your preferred contact method.

Minimize personal and customer data. Redact credentials, tokens, private keys, and unrelated log content. Do not send live secrets when a fingerprint, identifier, or sanitized excerpt is sufficient.

The receiving team will follow the approved incident and vulnerability-management process to:

1. acknowledge and protect the report according to the applicable service level;
2. triage severity, exploitability, affected versions, customers, and data;
3. contain active exposure and preserve evidence;
4. assign remediation, validation, release, and communication owners;
5. coordinate disclosure and customer communication;
6. record lessons learned and corrective actions.

Do not promise a public disclosure date, severity, bounty, or fix timeline unless authorized to do so.

• Restrict issue, branch, CI, artifact, and log access to the response team.
• Use neutral commit and release wording until disclosure is approved.
• Never copy sensitive evidence into a public fork or personal repository.
• Add regression tests that demonstrate the control without publishing a practical exploit prematurely.
• Revoke or rotate exposed secrets; Git history cleanup alone is not containment.
• Coordinate backports across all affected maintained versions.

Public advisories and technical details require approval from the incident/vulnerability owner and relevant legal, customer, and ISMS stakeholders. Credit to a reporter is provided only with their consent and according to the approved disclosure process.