Security Policy

PROTECTING OUR SYSTEMS AND YOUR DATA THROUGH RESPONSIBLE SECURITY PRACTICES

1. INTRODUCTION AND SCOPE

1.1. Policy Overview

This Security Policy (“Policy”) establishes the procedures and terms under which we handle the reporting and resolution of security vulnerabilities discovered in our applications, systems, and services. By participating in our security reporting process, you acknowledge and agree to comply with all provisions of this Policy.

1.2. Scope of Coverage

This Policy applies to all applications, services, and systems maintained by SpellWare, including but not limited to:

(a) All primary websites and web applications operated under our domain;

(b) Mobile applications distributed through official channels;

(c) Open-source projects hosted in our official repositories;

(d) Application Programming Interfaces (APIs) and backend services;

(e) Infrastructure and hosting environments that support our services;

(f) Associated documentation, support systems, and auxiliary platforms.

1.3. Security Principles

Our security programme is founded on the following principles:

(a) Transparency: We maintain open communication about our security practices whilst protecting sensitive operational details;

(b) Collaboration: We work cooperatively with security researchers and the broader community to identify and address vulnerabilities;

(c) Continuous Improvement: We regularly assess and enhance our security measures based on emerging threats and best practices;

(d) User Protection: Our primary focus is protecting the confidentiality, integrity, and availability of user data and systems.

1.4. Legal Framework

This Policy is designed to operate within the framework of applicable laws and regulations, including but not limited to computer fraud and abuse laws, data protection regulations, and responsible disclosure principles recognised in the security research community.

2. VULNERABILITY REPORTING PROCEDURES

2.1. Reporting Channels

If you discover a security vulnerability within any of our systems or applications, please report it exclusively through our designated secure reporting channel:

Security Vulnerability Report Form (Preferred): https://mktg.spellware.dev/security

Primary Contact: [email protected]

Subject Line Format: [SECURITY] Brief description of vulnerability

Alternative Contact: For urgent matters requiring immediate attention, you may also contact our general support team with clear indication of the security nature of your report.

2.2. Public Disclosure Prohibition

To protect our users and systems, you must not disclose security vulnerabilities publicly or through any public channels until we have had reasonable opportunity to investigate and address the issue. Prohibited disclosure methods include, but are not limited to:

(a) Public GitHub issues or pull requests;

(b) Social media platforms (Twitter, LinkedIn, Facebook, etc.);

(c) Public forums, discussion boards, or community platforms;

(d) Blog posts, articles, or public presentations;

(e) Security mailing lists or vulnerability databases;

(f) Any other medium accessible to the general public.

2.3. Required Information for Vulnerability Reports

To facilitate effective investigation and resolution, please include the following information in your vulnerability report:

(a) Detailed Description: A comprehensive explanation of the vulnerability, including the potential security impact and risk level;

(b) Reproduction Steps: Clear, step-by-step instructions that allow our team to reproduce the vulnerability consistently;

(c) Technical Details: Relevant technical information such as affected URLs, parameters, request/response examples, and system configurations;

(d) Proof of Concept: Where appropriate and safe, include demonstration code or screenshots that illustrate the vulnerability without causing harm;

(e) Suggested Remediation: If known, provide recommendations for addressing the vulnerability or mitigating the risk;

(f) Discovery Context: Information about how the vulnerability was discovered and any tools or techniques used.

2.4. Information Handling and Confidentiality

All vulnerability reports and related communications will be handled with strict confidentiality in accordance with our privacy policy and applicable data protection laws. We commit to:

(a) Limiting access to vulnerability information to authorised personnel only;

(b) Implementing appropriate security measures to protect report details;

(c) Not sharing vulnerability information with third parties without explicit consent, except as required by law;

(d) Maintaining detailed records of all communications and actions taken.

3. RESPONSE PROCEDURES AND TIMELINES

3.1. Initial Acknowledgement

We aim to acknowledge receipt of your vulnerability report within the following timeframes:

(a) Standard Reports: Within seven (7) business days of receipt;

(b) High-Priority Reports: As soon as reasonably possible for reports indicating critical vulnerabilities or active exploitation;

(c) Complex Reports: Within ten (10) business days for reports requiring initial technical assessment before acknowledgement.

3.2. Assessment and Verification Process

Following initial acknowledgement, our security team will:

(a) Conduct a thorough technical assessment of the reported vulnerability;

(b) Attempt to reproduce the issue using the provided steps and information;

(c) Evaluate the potential impact and risk level of the vulnerability;

(d) Determine the scope of affected systems and users;

(e) Develop an appropriate response and remediation plan.

3.3. Communication and Updates

Throughout the investigation and resolution process, we will:

(a) Provide regular status updates on the progress of our investigation;

(b) Communicate any additional information required to complete our assessment;

(c) Notify you of our preliminary findings and proposed resolution timeline;

(d) Keep you informed of any changes to our remediation plans or timelines.

3.4. Resolution Timeline

We are committed to resolving confirmed vulnerabilities within the following timeframes:

(a) Critical Vulnerabilities: Within seven (7) days for issues posing immediate risk to user data or system integrity;

(b) High-Risk Vulnerabilities: Within thirty (30) days for significant security issues requiring comprehensive remediation;

(c) Medium-Risk Vulnerabilities: Within sixty (60) days for moderate security concerns;

(d) Low-Risk Vulnerabilities: Within ninety (90) days for minor security issues;

(e) Complex Vulnerabilities: Extended timelines may be necessary for issues requiring significant architectural changes or third-party coordination, with regular communication about progress.

4. COORDINATED DISCLOSURE POLICY

4.1. Coordinated Disclosure Principles

We practice coordinated disclosure to balance transparency with security. This approach ensures that:

(a) Vulnerabilities are thoroughly investigated and properly addressed before public disclosure;

(b) Users and affected parties have adequate time to apply security updates;

(c) The security research community benefits from shared knowledge whilst minimising potential harm.

4.2. Disclosure Timeline

Our standard coordinated disclosure timeline follows this process:

(a) Initial Report: Vulnerability reported through appropriate channels;

(b) Assessment Period: Investigation and verification (up to 30 days);

(c) Remediation Period: Development and deployment of fixes (30-90 days depending on complexity);

(d) Public Disclosure: Joint announcement of vulnerability and resolution (after fix deployment and reasonable notice period).

4.3. Public Acknowledgement

With your explicit consent, we may publicly acknowledge your contribution in discovering and reporting the vulnerability after it has been resolved. Such acknowledgement may include:

(a) Recognition in our security advisories or public statements;

(b) Listing in our security researchers hall of fame;

(c) Social media recognition and appreciation;

(d) References in relevant security documentation or case studies.

4.4. Researcher Discretion

You retain the right to:

(a) Request anonymity in all public communications and acknowledgements;

(b) Decline participation in joint disclosure activities;

(c) Publish your own disclosure after coordinated resolution, following responsible disclosure principles;

(d) Specify your preferred method and format for public acknowledgement.

5. LEGAL SAFE HARBOUR PROVISIONS

5.1. Authorisation for Security Research

We explicitly authorise security research and vulnerability disclosure activities conducted in accordance with this Policy and applicable laws. This authorisation is intended to encourage responsible security research whilst protecting both researchers and our organisation.

5.2. Scope of Safe Harbour Protection

Our safe harbour provisions apply to security research activities that:

(a) Comply with all requirements and restrictions outlined in this Policy;

(b) Are conducted in good faith for the purpose of improving security;

(c) Do not compromise the privacy, safety, or security of our users, employees, or systems;

(d) Do not violate applicable laws or regulations;

(e) Are conducted without commercial motivation or malicious intent.

5.3. Protected Activities

Under this safe harbour, we will not initiate legal action against researchers for activities including:

(a) Accessing systems or data necessary to identify and document security vulnerabilities;

(b) Circumventing security measures solely for the purpose of vulnerability research;

(c) Creating accounts or using services as reasonably necessary for security testing;

(d) Downloading or accessing data that is the direct result of a security vulnerability, provided such access is limited to demonstrating the issue.

5.4. Limitations and Exclusions

This safe harbour protection does not apply to:

(a) Activities that violate applicable laws, regardless of research intent;

(b) Research conducted on third-party systems or applications that integrate with our services;

(c) Activities that involve social engineering, phishing, or physical security testing;

(d) Accessing, modifying, or deleting data belonging to other users;

(e) Conducting denial-of-service attacks or similar disruptive activities;

(f) Activities conducted after we have requested cessation or identified security policy violations.

5.5. Compliance Requirements

To maintain safe harbour protection, researchers must:

(a) Report vulnerabilities through designated channels within a reasonable timeframe;

(b) Provide sufficient detail to allow us to reproduce and address the vulnerability;

(c) Avoid disclosing vulnerabilities publicly before coordinated resolution;

(d) Cooperate with our investigation and remediation efforts;

(e) Cease testing activities upon request from our security team.

6. BUG BOUNTY PROGRAMME

6.1. Current Programme Status

At present, we do not operate a formal monetary bug bounty programme. Our security efforts rely on the goodwill and community spirit of security researchers who contribute to improving our security posture on a voluntary basis.

6.2. Non-Monetary Recognition

While we do not currently offer financial rewards, we deeply appreciate security researchers’ contributions and provide recognition through:

(a) Hall of Fame Recognition: Public acknowledgement in our security contributors hall of fame;

(b) Community Recognition: Acknowledgement in our community forums and social media channels;

(c) Professional References: With your consent, we may serve as a reference for your security research activities;

(d) Networking Opportunities: Introduction to other security professionals and organisations within our network.

6.3. Future Programme Development

We continuously evaluate the possibility of implementing a formal bug bounty programme. Factors influencing this decision include:

(a) The volume and quality of vulnerability reports received;

(b) Available resources for programme administration and reward distribution;

(c) Legal and regulatory considerations in relevant jurisdictions;

(d) Alignment with our organisational priorities and community values.

6.4. Alternative Contribution Opportunities

Security researchers interested in contributing to our security efforts may also consider:

(a) Contributing to our open-source security tools and documentation;

(b) Participating in community discussions about security best practices;

(c) Helping to educate other community members about security awareness;

(d) Collaborating on security-related content and educational materials.

7. DATA PROTECTION AND PRIVACY

7.1. Handling of Submitted Information

All information provided in vulnerability reports will be processed and protected in accordance with our Privacy Policy and applicable data protection laws. This includes:

(a) Implementing appropriate technical and organisational measures to protect report data;

(b) Limiting access to vulnerability information to authorised personnel only;

(c) Using vulnerability information solely for the purpose of investigation and remediation;

(d) Maintaining confidentiality of researcher information and contact details.

7.2. Data Retention Policies

We retain vulnerability reports and related communications:

(a) Active Cases: For the duration of the investigation and remediation process;

(b) Resolved Cases: For up to three (3) years following resolution for audit and reference purposes;

(c) Legal Requirements: As required by applicable laws and regulations;

(d) Historical Analysis: Anonymised trend data may be retained indefinitely for security improvement purposes.

7.3. Confidentiality Commitments

We commit to treating all vulnerability reports as confidential information and will not:

(a) Share report details with unauthorised third parties;

(b) Use vulnerability information for purposes other than remediation and security improvement;

(c) Disclose researcher identity or contact information without explicit consent;

(d) Publicly discuss specific vulnerability details before coordinated disclosure.

7.4. Researcher Privacy Rights

Security researchers maintain standard privacy rights regarding their personal information, including:

(a) The right to request access to personal data we hold about them;

(b) The right to request correction of inaccurate personal information;

(c) The right to request deletion of personal data in certain circumstances;

(d) The right to object to or restrict processing of personal data where legally applicable.

8. PROACTIVE SECURITY MEASURES

8.1. Security Monitoring and Assessment

To maintain the highest possible security standards and protect user data, we implement comprehensive proactive security measures across all our systems and applications.

8.2. Automated Security Scanning

Our security programme includes regular automated scanning and assessment using industry-standard tools:

(a) Static Code Analysis: Regular scanning of source code for potential security vulnerabilities using SonarQube and similar tools;

(b) Dynamic Application Security Testing: Ongoing testing of running applications to identify runtime vulnerabilities;

(c) Infrastructure Scanning: Regular assessment of our hosting infrastructure and network security;

(d) Dependency Scanning: Continuous monitoring of third-party libraries and components for known vulnerabilities.

8.3. Security Tool Integration

We utilise a comprehensive suite of security tools integrated into our development and deployment processes:

(a) Gitleaks: Automated detection of secrets, credentials, and sensitive information in code repositories;

(b) Grype: Secondary vulnerability scanning for dependencies and container images;

(c) Snyk: In-depth analysis of code and dependencies for security vulnerabilities and license compliance;

(d) Syft: Generation of Software Bills of Materials (SBOMs) for third-party security audits;

(e) Trivy: Comprehensive vulnerability scanning for containers, filesystems, and cloud configurations.

8.4. Public Security Reporting

We do not currently publish a public security dashboard or aggregated vulnerability reports. Where appropriate, we disclose resolved vulnerabilities in coordination with the reporter, as described in Section 4.2.

8.5. Security Development Lifecycle

Our development processes incorporate security at every stage:

(a) Secure Coding Standards: All developers follow established secure coding guidelines and best practices;

(b) Security Code Reviews: Mandatory security-focused code reviews for all changes and new features;

(c) Automated Testing: Security tests integrated into continuous integration and deployment pipelines;

(d) Regular Training: Ongoing security awareness and training for all development team members.

9. COMPLIANCE AND REGULATORY CONSIDERATIONS

9.1. Legal Compliance Requirements

All security research and vulnerability disclosure activities must comply with applicable laws and regulations, including but not limited to:

(a) Computer Fraud and Abuse Act (CFAA) and similar legislation in various jurisdictions;

(b) Data protection and privacy laws (GDPR, CCPA, etc.);

(c) Export control regulations affecting security tools and techniques;

(d) Industry-specific regulations applicable to our services or user base.

9.2. International Considerations

Given the global nature of our services and user base, researchers should be aware that:

(a) Different jurisdictions may have varying legal frameworks for security research;

(b) Cross-border data transfer and access may be subject to additional regulations;

(c) Some security research techniques may be legal in one jurisdiction but prohibited in another;

(d) Researchers are responsible for ensuring their activities comply with laws in their jurisdiction.

9.3. Ethical Guidelines

Beyond legal compliance, we expect all security research to adhere to widely recognised ethical guidelines:

(a) Minimise Harm: Avoid actions that could compromise user privacy, data integrity, or system availability;

(b) Respect Boundaries: Cease testing when requested or when encountering systems outside our scope;

(c) Professional Conduct: Maintain professional standards in all communications and interactions;

(d) Community Benefit: Focus on activities that benefit the broader security community and user protection.

9.4. Reporting Regulatory Concerns

If vulnerability research reveals potential regulatory compliance issues or legal violations:

(a) Include such concerns in your initial vulnerability report;

(b) We will assess the regulatory implications as part of our investigation;

(c) We may need to report certain types of vulnerabilities to relevant regulatory authorities;

(d) Researchers will be kept informed of any regulatory reporting requirements that may affect disclosure timelines.

10. CONTACT INFORMATION AND SUPPORT

10.1. Primary Security Contact

For all security-related matters, including vulnerability reports, questions about this Policy, and general security inquiries:

Security Vulnerability Report Form (Preferred for vulnerability reports): https://mktg.spellware.dev/security

Email: [email protected]

Response Time: We aim to respond to all security inquiries within 7-10 business days

Emergency Contact: For critical security issues requiring immediate attention, mark your email with [URGENT] in the subject line

10.2. Alternative Contact Methods

If you are unable to use our primary email contact:

General Support: [email protected] (clearly mark security-related messages)

Discord Community: https://chat.spellware.dev (for general security discussions only, not vulnerability reports)

Documentation: This Policy and related security documentation is maintained at our official documentation site

10.3. Response Commitments and Service Levels

We aim to maintain the following response standards:

(a) Initial Acknowledgement: We aim to acknowledge security reports within the timeframes set out in Section 3.1;

(b) Status Updates: Regular progress updates provided at least weekly for active investigations;

(c) Technical Clarification: Response to technical questions within 7-10 business days;

(d) Escalation Path: Clear escalation procedures for urgent matters or communication issues.

10.4. Communication Preferences and Requirements

To ensure effective communication:

(a) Language: All communications should be in English to ensure proper understanding and response;

(b) Technical Detail: Provide sufficient technical detail to enable reproduction and assessment;

(c) Contact Information: Include reliable contact information for follow-up questions;

(d) Time Zone Considerations: Our primary response times are based on Pacific Standard Time business hours.

10.5. Support Resources

Additional resources available to security researchers:

(a) Documentation: Comprehensive security policy documentation and guidelines;

(b) Community Support: Access to our community forums for general security discussions;

(c) Educational Resources: Links to security research best practices and legal guidelines;

(d) Feedback Mechanisms: Opportunities to provide feedback on our security policies and procedures.

11. POLICY UPDATES AND MAINTENANCE

11.1. Regular Review and Updates

This Security Policy is reviewed and updated regularly to ensure:

(a) Legal Compliance: Alignment with current laws and regulations;

(b) Best Practices: Incorporation of industry best practices and standards;

(c) Community Feedback: Response to input from security researchers and community members;

(d) Operational Experience: Refinement based on our experience with vulnerability reports and security incidents.

11.2. Change Notification Process

Changes to this Policy will be communicated through:

(a) Direct Notification: Email notification to researchers who have previously submitted reports;

(b) Public Announcement: Updates posted on our website and community forums;

(c) Documentation Updates: Version-controlled updates to our official documentation;

(d) Industry Channels: Notification through relevant security community channels where appropriate.

11.3. Policy Implementation

Policy updates will:

(a) Provide reasonable notice periods for significant changes;

(b) Maintain backward compatibility for ongoing vulnerability reports;

(c) Include transition procedures for any changes affecting active security research.

11.4. Feedback and Continuous Improvement

We welcome feedback on this Policy from:

(a) Security researchers who have participated in our vulnerability disclosure process;

(b) Legal and compliance professionals familiar with relevant regulations;

(c) Industry peers and security community members;

(d) Internal team members involved in security operations and incident response.

12. ACKNOWLEDGEMENTS AND RECOGNITION

12.1. Community Appreciation

We extend our sincere gratitude to the global security research community for their valuable contributions to improving the security of our systems and protecting our users. The collaborative approach to security research benefits everyone and represents the best of community-driven innovation.

12.2. Commitment to Excellence

This Security Policy represents our ongoing commitment to:

(a) Transparency: Maintaining open and honest communication about our security practices;

(b) Collaboration: Working cooperatively with researchers to address security concerns;

(c) Continuous Improvement: Regularly enhancing our security measures and response procedures;

(d) User Protection: Prioritising the security and privacy of our users above all other considerations.

12.3. Future Development

We are committed to the ongoing development and improvement of our security programme, including:

(a) Regular assessment of our security policies and procedures;

(b) Investment in security tools and technologies;

(c) Training and professional development for our security team;

(d) Engagement with the broader security community and industry initiatives.

---

By reporting a security vulnerability to us, you acknowledge that you have read, understood, and agree to comply with this Security Policy. This Policy is designed to promote responsible security research whilst protecting the interests of our users, our organisation, and the broader community. For questions about this Policy or to report security vulnerabilities, please contact us at [email protected].