Help us protect ZoikoSuite.
If you believe you have found a security vulnerability affecting an in-scope ZoikoSuite service, report it through the approved channel. This page explains current scope, research boundaries, disclosure handling, and the status of any researcher authorization or reward program.
Everything to know before you start testing
What we want
Reproducible security weaknesses affecting listed ZoikoSuite assets or supported integrations.
Check scope first
Search assets and scope status before testing. If uncertain, ask before high-risk testing.
Protect people and data
Use the minimum access needed to demonstrate impact; stop if unexpected sensitive data appears.
Keep services available
No destructive testing, denial of service, unsafe automation, persistence, or disruptive load unless explicitly authorized.
Report securely
Use the approved form/channel and encrypted attachment path for sensitive artifacts.
Coordinate disclosure
Give Product Security a reasonable opportunity to validate and remediate before public technical disclosure.
Registry-driven and effective-dated — never a static prose list
| Asset | Type | Scope Status | Environment | Bounty Eligibility |
|---|---|---|---|---|
| [ Registry-derived asset name ] | Web / API / Mobile | In scope | Production | [ status ] |
| [ Registry-derived asset name ] | API | Ask first | Production | [ status ] |
Stated before testing begins, not discovered after
Denial of service / resource exhaustion
Do not intentionally degrade availability or generate disruptive load unless explicitly authorized.
Social engineering / phishing
Do not target employees, customers, partners, or suppliers.
Physical security
No physical intrusion, tailgating, or device theft.
Privacy-invasive testing
Do not access, download, alter, or retain more data than needed to demonstrate a vulnerability.
Persistence / lateral movement
Do not establish persistence or expand access beyond minimal proof unless specifically authorized.
Destructive actions
Do not delete, modify, or corrupt customer/system data to prove impact.
A legal commitment, not a UX tone
Security purpose
— research is intended to identify and responsibly report a vulnerability, not extort, disrupt, profit from unauthorized access, or harm users.
Minimal access
— use only the access reasonably necessary to validate impact.
Data care
— do not retain or share personal, confidential, or customer data beyond what the approved process requires.
No persistence
— do not maintain unauthorized access after validation.
Private reporting first
— use the approved channel for technical details and coordinate public disclosure under the policy.
Multiple channels, one authoritative route
Secure web form
Default route for most reports. TLS, anti-abuse, file encryption, case receipt, accessible, no login required.
Security email
Fallback / researcher preference. Only a verified mailbox is published; PGP key supported if operationally maintained.
Emergency security contact
For active exploitation or material incident — separate from the normal queue.
Structured intake without blocking urgent reports
Nine stages — no invented response-time promises
Received
Entered the security queue
Triage
Scope, reproducibility, risk check
Needs info
Reporter input required
Validated
Issue reproduced/confirmed
Remediating
Owner assigned, fix underway
Release coordination
Fix staged/monitored
Resolved
Considered remediated
Disclosure pending
Advisory being coordinated
Close
With stated
Severity is determined after validation — may differ from the reporter's estimate
Duplicate
Same root cause already tracked
Informational
Useful observation, no qualifying vulnerability
Not reproducible
Unable to validate with available evidence
Out of scope
Asset/testing not authorized
Not applicable
Expected behavior, no boundary break
Accepted risk
Validated, consciously accepted
Remediated
Fix deployed and verified
Critical/High/Med/Low
Validated risk classification
Coordination, not unilateral publication
Exact status — never implied by page design alone
Minimize, encrypt, and never over-promise confidentiality
Maintained as operational security content, not generated once and forgotten
# https://zoikosuite.com/.well-known/security.txt
Contact: mailto:[email protected]
Expires: [ ISO 8601 date ]
Canonical: https://zoikosuite.com/.well-known/security.txt
Policy: https://zoikosuite.com/legal/security-disclosure
Encryption: https://zoikosuite.com/.well-known/pgp-key.txt
Preferred-Languages: enA synthetic monitor verifies the 200 response, content type, contacts, expiry, and canonical URL — this is treated as operational security content requiring renewal, not a one-time file.
A suspected vulnerability is not automatically an incident
If you observe active unauthorized access, credential theft, exposed secrets, ongoing customer impact, or imminent material exploitation — use the emergency route below and stop testing if continuing could increase harm.
| Scenario | Route |
|---|---|
| Active exploitation against ZoikoSuite | Emergency security escalation + incident response |
| Compromised user/customer account | Account security/support emergency path |
| Data exposure involving personal information | Security + Privacy incident process |
| Service outage / broad degradation | System Status / incident response route |