arkyn
ChangelogGuides
arkyn
docs / secure / security

Security Policy

Last Updated: July 10, 2026

1. Overview

This Security Policy explains how to report a suspected security vulnerability in Arkyn's packages, website, or Documentation, what to expect after reporting, and the safe-harbor protections available to good-faith security researchers.

2. Definitions

See Arkyn Legal Documentation for the shared glossary. In this Policy, "Vulnerability" means a flaw or weakness in Arkyn's Software, website, or infrastructure that could be exploited to compromise confidentiality, integrity, or availability.

3. Scope

This Policy covers:
  • The source code of @arkyn/components, @arkyn/server, @arkyn/shared, @arkyn/templates, and any other package published under the @arkyn npm scope.
  • The Arkyn website and Documentation (docs.arkyn.dev) and its official infrastructure.
  • Any optional logging, monitoring, or future proprietary services offered under the Arkyn name.
This Policy does not cover vulnerabilities in your own application built with Arkyn's packages, in your own configuration or deployment, or in unrelated third-party services the Site links to.

4. Supported Versions

Arkyn is actively developed by a small maintainer team, without long-term-support branches. As a practical matter:
  • Only the most recently published version of each @arkyn/* package receives security fixes.
  • We strongly recommend always running the latest published version of any Arkyn package you depend on, and reviewing the changelog and breaking changes pages before upgrading.
  • If a Vulnerability is found, a patched version will be published as soon as reasonably possible, and, where the issue is significant, called out in the changelog and, if appropriate, in a dedicated advisory on the relevant GitHub repository.

5. Reporting a Vulnerability

If you believe you have found a security Vulnerability in Arkyn, please report it privately rather than through a public GitHub issue, so it can be addressed before public disclosure.
How to report:
  • Email lucasgoncalves@arkyn.dev with a subject line starting with "SECURITY:", or
  • Use GitHub's private vulnerability reporting feature on the relevant repository at github.com/Lucas-Eduardo-Goncalves/arkyn, if enabled for that repository.
Please include, where possible:
  • A description of the Vulnerability and its potential impact.
  • Steps to reproduce it, including affected package name(s) and version(s).
  • Any proof-of-concept code or screenshots that help illustrate the issue.
  • Your suggested severity assessment, if you have one (see Section 8).
Do not include real users' personal data, credentials, or other sensitive information in your report; describe the issue using synthetic or redacted examples wherever possible.

6. Responsible Disclosure Guidelines

We ask security researchers to:
  • Give the Maintainer a reasonable opportunity to investigate and address a reported Vulnerability before making it public.
  • Avoid accessing, modifying, or deleting data that does not belong to you while investigating a Vulnerability.
  • Avoid actions that could degrade the availability of the Site or any Arkyn service for other users (for example, no denial-of-service testing against production infrastructure).
  • Report the Vulnerability through the private channels in Section 5, not through public issues, pull requests, or social media, until a fix has been released.
In return, we commit to acknowledging your report, working with you to understand and address the issue, and crediting you (if you wish) once it is resolved and safe to disclose.

7. Response Timelines

As a small, actively maintained open-source project, we aim to:
  • Acknowledge a new vulnerability report within 5 business days.
  • Provide an initial assessment of severity and validity within 10 business days of acknowledgment.
  • Release a fix or mitigation for confirmed Critical or High severity issues (see Section 8) as quickly as reasonably practicable, prioritized ahead of other work.
  • Keep the reporter reasonably informed of progress until the issue is resolved.
These are good-faith targets rather than a guaranteed service-level agreement, given the project's current maintenance model.

8. Severity Classification

Reported issues are informally classified as:
  • Critical — remote code execution, authentication bypass, or exposure of sensitive data at scale, with no meaningful mitigation available to users.
  • High — significant security impact requiring specific conditions to exploit (for example, a stored cross-site scripting issue, or a flaw in a validation utility that could be leveraged for injection attacks).
  • Medium — limited-impact issues, such as a Vulnerability requiring unusual configuration or local access to exploit.
  • Low — minor issues with negligible practical impact, including most defense-in-depth suggestions.
Final severity classification is at the Maintainer's discretion, informed by the reporter's assessment and any relevant industry standard (such as CVSS) where helpful.

9. Safe Harbor

Security research conducted consistent with this Policy — reported privately, without accessing others' data, without degrading service availability, and given reasonable time to remediate before public disclosure — is considered authorized under applicable computer-misuse and anti-hacking laws, and the Maintainer will not pursue legal action or refer such research to law enforcement for good-faith violations of the Acceptable Use Policy in Terms of Use that were strictly necessary to demonstrate the Vulnerability.
This safe harbor does not extend to actions that access or exfiltrate real user data beyond what is strictly necessary to prove the Vulnerability's existence, or to any activity that violates applicable law independent of these Terms (for example, accessing systems outside Arkyn's scope).

10. Security Recommendations for Developers

If you build on Arkyn's packages, we recommend you:
  • Keep all @arkyn/* dependencies updated to their latest published version.
  • Review breaking changes before upgrading across versions with security-relevant changes.
  • Avoid logging sensitive data (credentials, financial information, health data) through any optional logging integration described in Privacy Policy.
  • Validate and sanitize all user input server-side, even when using Arkyn's client-side validation components (@arkyn/server's validators are provided as a convenience, not a substitute for your own defense-in-depth).
  • Follow standard secure-development practices for any secrets, API keys, or credentials used alongside Arkyn's services (such as PlacesProvider's Google Maps API key or analytics measurement IDs).

11. Contact

Security reports: lucasgoncalves@arkyn.dev (subject line starting with "SECURITY:"). For all other inquiries, see Arkyn Legal Documentation.

12. Related Documents

  • Arkyn Legal Documentation — index and shared definitions.
  • Privacy Policy — how personal data, including data from optional logging features, is handled.
  • Terms of Use — the Acceptable Use Policy referenced in Section 9 above.
  • License — software license; note that the "AS IS" warranty disclaimer there applies independently of this Policy's response commitments.
On this page