Coordinated Vulnerability Disclosure Statement

Purpose

This policy sets forth the fundamental principles and handling commitments for the Company to receive, validate, communicate on, remediate, and publicly disclose product-security vulnerabilities. The Company encourages security researchers, customers, partners, suppliers and other relevant parties to report potential vulnerabilities in accordance with this policy, and to jointly mitigate risks to end-users and the ecosystem via coordinated disclosure.

This policy shall be used in conjunction with the Company's Vulnerability Management Procedure and full-lifecycle Vulnerability Handling Operating Manual. Contact information, confirmation timeframes, communication frequency, secure communications, disclosure arrangements and acknowledgement commitments stated in the external policy shall be supported by internal processes, personnel responsibilities and record-keeping mechanisms.

Scope of Application

This policy applies to digital-enabled products and related services manufactured, sold, maintained or supported under the name of AMZFAST, including but not limited to software, firmware, hardware, mobile applications, APIs, update mechanisms, default configurations and associated cloud services. The exact scope of applicable products shall be subject to information published on the Company's official website, customer portal or product-security webpage.

This policy does not apply to general functional defects, spam, social-engineering tests, physical attacks, denial-of-service stress testing, unauthorized data access, testing targeting third-party systems, or any activities violating applicable laws, customer agreements or terms of service. If reporters are uncertain whether an issue falls within the scope of this policy, they may make an initial contact via the channels specified herein.

Reporting Channels

The Company maintains one or more vulnerability-reporting channels. If a reporter submits an initial lead via general customer support or other non-security channels, the Company shall accept the submission and guide the reporter to the formal security channel. Reports shall not be rejected merely because the initial submission channel was incorrect. At least one non-person-bound official entry shall be provided among public reporting channels and remain externally accessible.

1. Security email: security@expressluck.com
2. Official website portal: https://www.amzfast.net/pages/cybersecurity-policy
3. Other contact points, e.g. sales platforms

Information to be Provided by Reporters

To facilitate prompt validation and remediation of vulnerabilities, reporters are encouraged to provide as much of the following information as possible. Missing partial information will not automatically result in rejection of the report; the Company may request supplementary information in subsequent communications.

• Affected products, models, hardware revisions, software/firmware versions, components, configurations, deployment environments or customer scenarios.
• Vulnerability description, attack prerequisites, trigger conditions, reproduction steps, minimal PoC, screenshots, logs or other supporting materials.
• Reporter's assessment of potential impact, e.g. whether the vulnerability is remotely exploitable, whether authentication is required, and impact on confidentiality / integrity / availability.
• Whether the vulnerability has been made public, whether exploitation is suspected or confirmed, and whether suppliers, customers, coordination organisations or other parties have been notified.
• Reporter's contact details, time zone, organisational affiliation, planned public-disclosure date, proposed confidentiality period, and preference for attribution or anonymity.

Reporters shall refrain from submitting customers' trade secrets, credentials, secret keys or other information beyond what is necessary for vulnerability validation. If such information is inadvertently accessed during testing, further access shall cease immediately and the circumstance shall be noted in the report.

Acceptance, Confirmation and Communication Commitments

Upon receipt of a vulnerability report, the Product Security Team shall log and triage the report in accordance with internal procedures. Subject to general circumstances, AMZFAST shall follow the communication cadence below:

1. A confirmation acknowledgement shall be sent within 1 business day upon receipt of a valid report, together with an assigned tracking number (VMR-YYYY-NNNN). This tracking number shall be referenced throughout triage, validation, remediation, communication, disclosure and case closure. Where the same vulnerability is submitted repeatedly via multiple channels, submissions shall be linked to the original report and status updates shall be provided to reachable reporters.
2. Preliminary validation shall be completed within 3 business days, advising whether an investigation will proceed, whether supplementary information is required, or whether the matter falls outside this policy's scope.
3. Status updates shall be provided to the reporter at least every 15 calendar days during validation and remediation; timely communication shall occur for any material changes.
4. Once a vulnerability is confirmed, the Company shall communicate the expected remediation approach, temporary mitigations, coordinated-disclosure arrangements and estimated public-release timeline.
5. Upon completion of remediation, mitigation or case closure, the Company shall inform the reporter of closure conclusions, advisory links, acknowledgement arrangements and follow-up support options.

Secure Communications and Information Protection

Vulnerability reports and coordination workflows may contain exploit details, PoC files, logs, credentials, secret keys, customer data or non-public remediation information. The Company shall restrict access on a need-to-know basis and transmit and store sensitive information via protected channels.

• Initial reports may be submitted via regular email or AMZFAST official-website support channels; sensitive details and attachments shall promptly be migrated to protected channels such as secure forms or encrypted email. Secure-communication methods shall preserve both confidentiality and message integrity, e.g. HTTPS-secured forms, PGP/S-MIME encrypted or signed email, controlled customer portals.
• Non-public vulnerability information shall not be forwarded to unauthorised personnel, uploaded to open-access repositories, or discussed in public chat groups or uncontrolled platforms.
• Appropriate access permissions shall be applied to tickets, code repositories, shared drives, mailing lists and meeting records; key access and communication records shall be retained.
• Where vulnerability information needs to be shared with suppliers, open-source maintainers, CERT/CSIRT bodies, customers or regulators, only the minimum information required for coordination, remediation or user protection shall be disclosed.

Coordinated Disclosure and Confidentiality Period

The Company and reporters may negotiate a reasonable confidentiality period and public-disclosure date. The confidentiality period shall be determined taking into account vulnerability severity, remediation complexity, upstream-downstream coordination complexity, product criticality, active exploitation status, existing public disclosures, time required for users to deploy updates, and applicable legal or contractual requirements.

Prior to availability of remediation or mitigation measures, both reporters and the Company shall refrain from publicly releasing technical details that could raise exploit risk. If vulnerability information is prematurely disclosed, active exploitation occurs, the reporter intends to publish early, or user risks demand earlier notification, the Company shall escalate promptly to the Product-Security Lead as well as Legal / Compliance leads to re-evaluate disclosure arrangements, and assess whether external security-advisory obligations are triggered.

Remediation, Advisories and User Notifications

After vulnerability confirmation, the Company shall drive remediation, temporary mitigations, validation testing and release preparation according to risk rating and product-support policies. Where third-party components, open-source projects, hardware suppliers, cloud services or channel partners are involved, the Product Security Team shall coordinate upstream and downstream stakeholders to complete impact analysis and remediation planning.

Security advisories are generally published after remediated versions, patches, configuration mitigations or other risk-reduction measures become available. Advisories shall contain sufficient information for target users to assess relevance and take action, typically including: vulnerability description, vulnerability identifiers, affected products and versions, potential impact, severity rating, remediation / mitigation measures, publication date, revision date, support contact details, and reporter acknowledgements where consent is granted.

If full public release of technical details would create greater attack risk than security benefit, the Company may first supply risk-reduction information and remediation measures to affected users, alongside a planned full-disclosure date. Delayed full disclosure shall be approved and documented by the Product-Security Lead, relevant product owner and Legal / Compliance lead.

Regarding Statements

The Company values contributions to product security from the security-research community. After vulnerability remediation and disclosure, with the reporter's consent, the Company may recognise the reporter in security advisories, acknowledgement pages or internal records.

To the fullest extent permitted by applicable law, the Company will not initiate adverse legal action against good-faith security research performed in compliance with this policy and reported in a timely manner. This commitment does not apply to activities that violate laws, access third-party systems, disrupt services, exfiltrate data, commit extortion, make threats, or any other conduct beyond the scope of this policy.

Acknowledgement, Safe-Harbour and Limitation Statement

The Company values contributions from the security community to product security. After vulnerability remediation and disclosure, with the reporter's consent, the Company may publicly acknowledge the reporter's contribution in security advisories, acknowledgement pages or internal records. Reporters may choose to remain anonymous or use a designated attribution.

To the fullest extent permitted by applicable law, the Company will not initiate adverse legal action against good-faith security research conducted in compliance with this policy, performed in good faith and reported in a timely manner. This commitment does not apply to conduct that violates laws, accesses third-party systems, disrupts services, exfiltrates data, commits extortion, makes threats, or any other activity beyond the boundaries of this policy.

Record-Keeping, Review and Continuous Improvement

The Company shall retain policy versions, public-page links, channel-validation records, vulnerability reports, communication logs, secure-communication evidence, disclosure decisions, advisory revisions, acknowledgement confirmations, remediation-validation records and case-closure records. Retention periods shall cover product-support lifecycles and satisfy applicable regulatory, contractual and customer requirements (vulnerability registers shall be retained for at least 10 years or the product-support lifecycle, whichever is longer).

The Product-Security Lead shall organise a policy review at least annually / semi-annually to verify reporting-channel operability, public-page accessibility, achievability of communication timeframes, effectiveness of secure communications, completeness of advisories, and handling of user and reporter feedback. Identified gaps shall be converted into improvement actions and tracked until closure.