docs: Add SECURITY.md repository security policy and vulnerability reporting guidelines

[ayushsri-dev]

Summary

This issue proposes adding a dedicated SECURITY.md file to the root of the ARVIO repository to establish a clear vulnerability-reporting process and document the project's security support policy.

Current Repository State

A review of the repository's existing documentation and configuration shows:

• No SECURITY.md or .github/SECURITY.md file currently exists.
• The Contact section in PRIVACY.md directs general privacy-related inquiries to GitHub issues.
• Diagnostic/reporting pages in web/app/report/page.tsx and netlify-arvio-tv-site/report/index.html direct bug reports to a public Discord channel.
• No dedicated private process for reporting potential security vulnerabilities is currently documented.

As a result, the repository does not provide contributors or security researchers with clear guidance for privately reporting security-sensitive findings.

Why This Is Needed

ARVIO contains several security-sensitive components and integrations, including:

1. Cloud Authentication & Sync

   • Supabase JWT access and refresh tokens
   • Device authentication sessions
   • Account authentication data

2. Third-Party & Home Server Integrations

   • Jellyfin, Emby, and Plex access credentials
   • Trakt OAuth integration
   • Telegram sessions
   • IPTV provider credentials

3. Backend & Data Access

   • Supabase Edge Functions such as tmdb-proxy and trakt-proxy
   • PostgreSQL Row Level Security (RLS) policies
   • Netlify authentication-related services

Given these security-sensitive areas, a vulnerability involving authentication, credential handling, authorization, proxy behavior, or database access could require private communication with maintainers.

Without documented security-reporting guidance, researchers may reasonably default to public GitHub issues or public Discord channels, which may unintentionally expose sensitive vulnerability details.

Adding SECURITY.md would provide a standard, discoverable location for responsible vulnerability-reporting instructions and allow GitHub to surface the repository's Security Policy through its security interface.

Proposed Policy Scope

The proposed SECURITY.md should remain concise and cover:

Security Policy Overview

Provide a brief description of the purpose of the policy and its role in responsible vulnerability disclosure.

Supported Versions

Document which branch or released versions currently receive security fixes.

The exact support model should be confirmed by maintainers before being documented.

Reporting a Vulnerability

Provide clear instructions for privately reporting suspected security vulnerabilities.

The policy should explicitly advise against disclosing vulnerability details through public GitHub issues or public Discord channels.

The reporting mechanism should use a maintainer-approved private channel, such as GitHub Private Vulnerability Reporting if enabled, or another designated private contact.

Information to Include

Reports should ideally contain:

• Affected component or platform
• Description of the vulnerability
• Potential security impact
• Reproduction steps or proof of concept, where appropriate
• Relevant environment/version information

Potentially affected areas may include Android, iOS, Web, Supabase-backed services, or Netlify-hosted components.

Responsible Disclosure

Request that reporters allow maintainers reasonable time to investigate and address a reported vulnerability before publicly disclosing technical details.

The policy should not promise specific response or remediation timelines unless maintainers explicitly define them.

Maintainer Decisions Required

Before the final Security Policy is merged, maintainers should confirm:

1. Private reporting mechanism

   • GitHub Private Vulnerability Reporting, if enabled; or
   • another maintainer-designated private security contact.

2. Supported-version policy

   • Whether security fixes apply only to the latest code/release associated with main; or
   • whether additional released versions are actively supported.

These details should not be assumed or invented in the implementation.

Scope

This issue is limited to establishing repository-level security reporting and disclosure documentation.

It does not propose:

• auditing or redesigning ARVIO's authentication architecture;
• changing credential or token storage mechanisms;
• modifying Supabase RLS policies;
• changing existing application functionality;
• introducing vulnerability-response SLAs;
• claiming that any currently identified component is vulnerable.

Any security implementation changes discovered separately should be handled through appropriate private reporting or dedicated follow-up work.

Acceptance Criteria

• A root-level SECURITY.md is added following GitHub Security Policy conventions.
• A maintainer-approved private vulnerability-reporting mechanism is documented.
• Public GitHub issues and public Discord channels are explicitly discouraged for reporting security-sensitive findings.
• The supported branch/version policy is documented based on maintainer confirmation.
• The policy explains the information contributors should provide when reporting a vulnerability.
• Responsible disclosure expectations are documented.
• No fabricated email addresses, response SLAs, remediation timelines, or unsupported security guarantees are introduced.
• Existing repository documentation references SECURITY.md where appropriate.

[ayushsri-dev]

/claim