Vulnerability Management Policy
SyncMate — WYHEN Pty Ltd (ABN 57 688 078 999) Version 1.0 · Effective 31 August 2026 · Owner: Founder/Technical Operator · Review: annually
1. Purpose and scope
Defines how vulnerabilities in the SyncMate application, its dependencies, its database access configuration and its hosted infrastructure are identified, scored, remediated and verified. Underlying operating systems, runtimes and database engines are patched by our managed providers (Cloudflare, Supabase/AWS); this policy covers everything within our control and our reliance on those providers.
2. Sources of findings
| Source | Frequency |
|---|---|
| Automated dependency scanning | Every change |
| Automated code/static analysis | Every change |
| Database access-policy and privilege baseline check | Every migration |
| Independent penetration testing | At release to enterprise customers, on material change, and annually |
| Provider security advisories (Cloudflare, Supabase, Stripe, Xero, OpenAI, Google) | Weekly triage |
| CVE feeds for our dependency set and ACSC alerts | Weekly triage |
| External reports (customers, researchers) via contact@wyhen.com.au | On receipt |
3. Severity scoring
Findings are scored using CVSS v3.1, then adjusted for our context:
- Escalate one level where the finding is reachable across tenants (an authenticated user of one workspace could reach another workspace's data), where it exposes Xero OAuth tokens or platform secrets, or where it permits unauthenticated access to customer data.
- De-escalate one level where exploitation requires operator-level access already subject to audit logging, or where a compensating control demonstrably blocks the path.
Any confirmed cross-tenant data exposure is treated as Critical regardless of base score.
4. Remediation SLA
| Severity | Remediate within | Interim requirement |
|---|---|---|
| Critical | 24 hours | Immediate mitigation or feature disablement if a fix is not available within 24 hours; customer notification if data was exposed |
| High | 7 calendar days | Mitigation applied where a full fix takes longer |
| Medium | 30 calendar days | Tracked with an owner and due date |
| Low | Next scheduled release | Reviewed at each quarterly risk review |
The clock starts when the finding is confirmed as applicable to our environment (triage must occur within 1 business day of the finding being raised, or immediately for anything scored Critical or High).
5. Process
- Intake — the finding is logged with source, description, affected component, CVSS base score and context adjustment.
- Triage — confirm applicability and exploitability in our environment; false positives are recorded with the reason.
- Assign — an owner and due date per the SLA above.
- Remediate — fix through the standard change process (A3), including review and automated gates. Emergency Critical fixes may bypass the preview stage only with a documented rationale and a same-day retrospective verification.
- Verify — re-run the detecting scan or test and confirm the finding is closed. A finding is not closed on assertion alone.
- Record — retain the finding, its severity, dates and verification evidence for at least 3 years.
6. Exceptions
Where a finding cannot be remediated within its SLA, a written exception is recorded stating the reason, the compensating controls in place, the residual risk score, the approver (Founder) and an expiry date not exceeding 90 days for High or 12 months for Medium and Low. Critical findings are not eligible for exception.
7. Responsible disclosure
Security researchers and customers may report vulnerabilities to contact@wyhen.com.au. We acknowledge within 2 business days, provide a triage outcome within 5 business days, and do not pursue legal action against good-faith researchers who avoid privacy violations, data destruction and service disruption.
8. Reporting
Open findings by severity, SLA compliance and any active exceptions are reported at each quarterly risk review and are available to enterprise customers on request.