Vulnerability Disclosure Policy

This policy operates in coordination with the Cybersecurity Incident Disclosure Policy at trust-and-security/cybersecurity-incident-disclosure-policy.md. Reports that meet the materiality threshold under that policy are escalated through the Cybersecurity Incident Disclosure process in addition to the vulnerability disclosure workflow described here.

This Vulnerability Disclosure Policy (VDP) sets out how external researchers, customers, partners, and users (“Reporters”) may report suspected security vulnerabilities in Tanqory products, services, and infrastructure. It establishes safe, responsible, and coordinated reporting and disclosure aligned to ISO/IEC 29147 (Vulnerability Disclosure) and ISO/IEC 30111 (Vulnerability Handling), SOC 2, and industry best practices. The English version governs. If translations differ, the stricter rule or latest version prevails. Tanqory may update this policy when laws, standards, or threat conditions change. We prioritize transparency, speed, and collaboration: we commit to acknowledge quickly, triage consistently, remediate according to risk, and keep reporters informed; we expect reporters to minimize impact, protect user data, and coordinate disclosure.

1) Purpose and Scope

This policy exists to enable good-faith reporting, accelerate triage and remediation, protect customers and merchants, and reduce exploit risk. It covers Tanqory-owned domains, applications, APIs, cloud infrastructure, and mobile apps listed in Appendix A (In-Scope), with explicit exclusions in Appendix B. Activities that degrade, disrupt, or deny service (such as volumetric DDoS), social engineering of staff or customers, physical intrusion, or anything that violates applicable law are outside scope. This is a vulnerability disclosure policy, not a bounty program; where a bounty applies, its additional terms govern rewards. Recognition may still be granted at Tanqory’s discretion (Appendix D). For clarity, sandbox/staging environments are acceptable for logic flaws but not for availability tests; third-party platforms not operated by Tanqory are excluded, and any testing on customer data you do not own is prohibited. If an issue is discovered on a third-party component that materially affects Tanqory, we may coordinate with that vendor under our Third-Party Risk Management Policy.

2) Safe Harbor and Good-Faith Expectations

Tanqory will not initiate legal action against researchers who act in good faith and follow this policy. Good faith means avoiding privacy violations and service degradation, not accessing unnecessary data, and stopping testing immediately to report if personal data, payment data, or confidential information is encountered. Reporters must not weaponize, publicly disclose, sell, or share exploits before coordinated disclosure timelines. Anti-circumvention applies: do not exploit beyond the minimum necessary to demonstrate impact, and do not maintain persistence or pivot laterally. Reporters must comply with export controls and sanctions; Tanqory cannot engage where prohibited by law. Safe harbor is conditioned on abiding by the rules of engagement, promptly reporting, and cooperating during triage. If you believe your testing may have breached a boundary, disclose it immediately so we can assess and mitigate any unintended impact.

3) Rules of Engagement

Testing must remain non-destructive. Acceptable techniques include reflected or stored XSS proof, limited SQLi payloads to confirm injection, SSRF with non-destructive callbacks, and authenticated testing using only your own accounts. Prohibited techniques include brute-force or credential stuffing at scale, resource exhaustion, spam, phishing or vishing, physical access attempts, and any use of leaked or stolen credentials. Reporters should honor published API rate limits and avoid excessive traffic; load/performance concerns should use minimal proof-of-concept and be coordinated first. If personal or confidential data is unintentionally accessed, testing must cease, data must not be saved or transferred, any copies must be securely deleted, and only minimal evidence (e.g., hashes, redacted screenshots) should be provided in the report. When demonstrating IDOR or access-control issues, use synthetic data and the smallest possible dataset. For SSRF, target a controlled endpoint you own; do not attempt cloud metadata recursion or internal lateral movement. Do not modify or destroy data, create backdoors, or escalate privileges beyond what is necessary to show impact.

4) Reporting Channels and Required Content

• Email: security@tanqory.com
• Secure form: https://security.tanqory.com/report (preferred for encryption and tracking)
• PGP: Our public key and fingerprint are published at https://security.tanqory.com/pgp
• Required report details (see template in Appendix C):
  • Target (domain/app/API), environment (prod/sandbox), and time observed (UTC).
  • Vulnerability type, impact, and severity rationale (CVSS 3.1 vector if possible).
  • Proof-of-concept steps with reproduction details, accounts used, and any payloads.
  • Expected vs actual behavior, and suggested fix if known.
  • Screenshots/log snippets (redacted) and request/response samples (with secrets removed).
  • Contact for follow-up (email/handle). If you want recognition, state your preferred name/URL.

5) Triage and Service Levels

We acknowledge complete reports within 1 business day (24 hours). Within 5 business days we confirm severity and scope, and we provide status updates at least every 14 days until closure. Remediation targets are risk-based: Critical issues (e.g., RCE, unauthenticated data exfiltration, auth bypass) are mitigated or fixed within 14 days; High issues (e.g., cross-tenant data exposure via IDOR/SSRF, privilege escalation) within 30 days; Medium within 60 days; Low and informational are queued into planned releases. If we detect exploitation in the wild or material risk, we will accelerate timelines, deploy interim mitigations (WAF rules, feature flags, key rotations), and keep the reporter informed.

6) Severity and Prioritization

Severity uses CVSS 3.1/4.0 plus business impact: data sensitivity, blast radius, exploitability, authentication required, lateral-movement potential, and regulatory exposure. Multi-tenant impact, PII/PCI/credentials exposure, or trivial unauthenticated exploitation raise priority. Items that are low impact or out-of-scope are enumerated in Appendix B and Appendix E to set expectations and reduce noise.

7) In-Scope vs Out-of-Scope

Production assets in Appendix A are in scope, including core domains, primary APIs, merchant/admin consoles, and official mobile apps. Staging/sandbox may be used for logic flaws but not for availability or load testing. Out of scope are third-party services not operated by Tanqory, marketing microsites, community forums, and assets listed in Appendix B. Findings without security impact (for example, missing headers with no exploit path) and common low-impact issues in Appendix E are also out of scope.

8) Disclosure and Publication

Reporters must not disclose vulnerabilities publicly until Tanqory confirms remediation or gives written approval. We aim to remediate within the targets above; if timelines must extend, we will communicate and agree on a revised plan. Please allow at least 30 days from acknowledgment before considering publication; for critical issues, coordinate explicitly for a mutually agreed disclosure date. Attribution may be provided (Appendix D) if requested and policy-compliant. This VDP does not provide bounties unless separately agreed.

9) Legal and Compliance

Governing law and dispute resolution follow the header (Singapore law; SIAC arbitration), subject to non-waivable rights where applicable. Reporters must comply with laws that apply to their testing; this policy does not authorize access beyond what is necessary to validate the issue or to systems explicitly excluded. If you encounter evidence of criminal activity (e.g., child sexual abuse material), stop immediately and notify legal@tanqory.com; do not retain or transmit the data.

10) Data Protection and Privacy

Collect only what is necessary to evidence the issue. Redact or hash sensitive fields and never transmit live secrets (tokens/keys/passwords) in plaintext. Tanqory processes reporter contact and technical artifacts solely for triage, remediation, legal compliance, and recognition (if requested). Retention follows our Records of Processing and Data Retention policies with strict access controls. Cross-border transfers of reporter data use the applicable DPA/SCC/Addendum; by submitting, you consent to this processing for security response.

11) Coordination with Incident Response

If a report indicates active exploitation, Tanqory invokes Incident Response procedures (containment, eradication, recovery, notification) in line with breach laws (e.g., GDPR, PDPA, U.S. state breach rules). We may request relevant metadata (timestamps, source IPs, payload hashes); provide only what is necessary. We will share status through the SLA cadence and notify affected customers or regulators as required.

12) Recognition

Non-monetary recognition (e.g., Hall of Thanks) may be offered at Tanqory’s discretion after validation and remediation, provided this policy was followed. Recognition is separate from and not guaranteed by this VDP; any rewards are governed by specific bounty terms if applicable.

13) Changes to this Policy

We may update this policy for new laws, standards, infrastructure changes, or threat conditions. Updates are posted to https://legal.tanqory.com and may be noted on https://status.tanqory.com when relevant. Material changes—such as scope expansions or safe harbor adjustments—will be reflected in the “last_updated” date in the header.

14) Contact

• Primary: security@tanqory.com
• Secure form: https://security.tanqory.com/report
• PGP key: published at https://security.tanqory.com/pgp
• Legal: legal@tanqory.com
• Status/maintenance notices: https://status.tanqory.com

15) Operational Workflow Overview (for clarity)

• Intake: submissions arrive via the secure form or email and are auto-tracked with ticket IDs. PGP is available for sensitive payloads.
• Validation: security engineering reproduces and validates impact, consulting service owners for business context (data classification, tenant isolation, affected regions).
• Risk rating: CVSS plus business modifiers (data sensitivity, regulatory exposure, exploitability, lateral movement potential).
• Mitigation and fix: interim mitigations may include feature flags, WAF rules, rate limits, key rotations, or configuration changes; permanent fixes follow our secure SDLC with peer review and testing.
• Verification and closure: fixes are validated in staging where possible, then production; logs are checked for exploitation; closure is communicated to the reporter with a summary (where appropriate).
• Post-incident learning: material issues feed root-cause analysis, playbook updates, detections, and training; patterns may trigger broader code scans or threat hunts.

16) Alignment with Other Policies and Standards

• Secure SDLC: Findings integrate into backlog tracking, with severities mapped to SLAs in the Secure Development Lifecycle and Change Management Policy.
• Incident Response: If exploitation is suspected, this VDP hands off to the Incident Response Plan (containment/eradication/notification) while maintaining reporter communications.
• Data Protection: Handling of evidence and reporter data follows the Data Protection, Data Classification, and Data Retention Policies; cross-border transfers follow the DPA/SCC/Addendum.
• Third Parties: If a vulnerability affects a vendor/subprocessor, Tanqory will coordinate under the Third-Party Risk Management Policy and require timely remediation.
• Transparency: Where legally required or in the public interest, Tanqory may include aggregated vulnerability metrics in its Annual Transparency Report without exposing exploit paths.

17) Additional Guidance for Reporters

• Preferred evidence: minimal but sufficient. Redact secrets; if token leakage is demonstrated, truncate or hash. For SSRF, use callback to a non-sensitive endpoint you control; avoid hitting internal metadata recursively.
• Multi-tenant impact: highlight whether cross-tenant data or actions are possible; such cases receive higher priority.
• Authentication/authorization: state the exact role used (e.g., merchant admin, staff, partner API token) and whether lesser privileges suffice.
• Race conditions/performance: include timing windows, endpoints, and observed impact; avoid prolonged load.
• Chain of bugs: if impact requires chaining (e.g., open redirect + JWT theft), describe each link and the final harm.
• Exploit controls: if mitigations exist (e.g., CSP, rate limiting, mTLS), note whether they block or merely reduce impact.

18) Additional Guidance for Tanqory Internal Teams

• Logging: ensure VDP submissions are logged with immutable audit trails, timestamps, and handlers for accountability.
• Secrets: rotate any exposed secrets immediately; check blast radius (config, CI/CD, infra).
• Detection: add or tune detections (WAF, IDS/IPS, anomaly) to prevent recurrence and catch active exploitation.
• Communications: keep updates concise and factual; avoid sharing sensitive internal details externally; offer coordinated timelines for public disclosure.
• Regulatory: if personal data is implicated in regulated regions (e.g., GDPR/PDPA/US state laws), consult Privacy/Legal for potential notifications.
• Metrics: track mean time to acknowledge (MTTA), mean time to remediate (MTTR) by severity, and recurring patterns to drive prevention.

19) Glossary (selected)

• CVSS: Common Vulnerability Scoring System, used for severity and prioritization.
• Coordinated Disclosure: Process where reporter and vendor align on timing for public disclosure after remediation/mitigation.
• IDOR: Insecure Direct Object Reference; access-control flaw allowing unauthorized data access.
• mTLS: Mutual TLS authentication between client and server.
• PGP: Public-key encryption for secure communication of sensitive details.
• SSRF: Server-Side Request Forgery; attacker induces server to make unintended requests.
• VDP: Vulnerability Disclosure Policy; this document governing responsible reporting.

---

Appendix A: In-Scope Assets (examples; updated at https://security.tanqory.com/scope)

• *.tanqory.com (production), excluding domains in Appendix B.
• Core web apps: merchant/admin console, billing, checkout flows, developer portal.
• APIs: public REST/GraphQL APIs and webhooks for merchants/partners.
• Mobile apps: official iOS/Android apps published by Tanqory.
• Infrastructure: production endpoints used for payments, pricing, subscriptions, and account management.

Appendix B: Out-of-Scope Assets and Activities

• Non-Tanqory third-party services, marketing microsites, community/forums, and vendors’ own platforms.
• Denial-of-service, spam, phishing, social engineering, physical security testing.
• Automated vulnerability scans without coordination that generate excessive traffic.
• TLS best-practice findings without exploit (e.g., lack of latest cipher if strong alternative exists), missing SPF/DMARC records without an abuse vector, clickjacking on non-sensitive pages, CSRF on logout-only actions, or rate-limit observations without demonstrated exploitability.
• Any testing on accounts or data you do not own or have permission to use.

Appendix C: Report Template (minimum fields)

• Summary and impact
• Target (domain/app/API), environment, time observed (UTC)
• Steps to reproduce (numbered), payloads, and required account roles
• Expected vs actual behavior
• CVSS vector (if available) and severity rationale
• Evidence: redacted screenshots/log snippets, request/response samples (with secrets removed)
• Suggested remediation (optional)
• Contact for follow-up; recognition preference (optional)

Appendix D: Hall of Thanks (illustrative)

• We may publish researcher names/handles upon request after validation and remediation. This appendix is updated periodically on https://security.tanqory.com/thanks.

Appendix E: Example In-Scope vs Out-of-Scope Issues

• In-scope examples: auth bypass; IDOR exposing cross-tenant data; RCE; SQLi; stored/reflected XSS with session/token theft; SSRF leading to metadata/credential access; open redirect with token leakage; misconfig allowing unauthenticated access to sensitive objects; privilege escalation; improper access control on webhooks.
• Out-of-scope examples: missing security headers without exploit chain; version disclosure without impact; self-XSS requiring user to paste script; CSRF on non-sensitive actions; clickjacking on static or marketing pages; lack of rate limiting without demonstrated abuse; bugs in outdated browsers no longer supported.