Version: 1.1

Last Updated: March 15, 2026

Only the latest minor version receives security patches. Older versions are unsupported. Version 0.1.x is currently the only supported version. Once version 1.0.0 is released, the policy will expand to cover the latest major and minor versions.

This project implements a Zero Trust model with multiple security layers: dual authentication via JWT through Supabase cookies (browser) + API Key via x-api-key header (services), Row Level Security (RLS) enforced on all database tables at the PostgreSQL level through Supabase, RBAC with four role tiers — anon, user, editor_*, admin — with explicit visibility filters (public, private, confidential), automatic Docker image scanning with Trivy for CVEs on every push via GitHub Actions (SARIF results uploaded to GitHub Security), and Zero Client Trust where Server Actions never accept userRole from the client — identity is always resolved server-side via AuthService.

Do not open a public GitHub issue for security vulnerabilities. Report security vulnerabilities using ONE of these methods:

Method 1: GitHub Security Advisories (Preferred) — Go to: Repository Settings → Security → Report a vulnerability. Provides private discussion with maintainers and automatic CVE coordination and tracking. This channel requires reports in English mandatory.

Method 2: Private Email (Only if strict confidentiality is required) — Email: security@natuleadan.com with subject "SECURITY: [brief description]". Include in your report: description of the vulnerability, steps to reproduce, affected versions, potential impact assessment, and any suggested fix (optional). Email reports are accepted in English (default), but all must include an executive summary in English.

Acknowledgement within 7 calendar days. Initial assessment timelines may vary depending on complexity and availability of resources. For vulnerability fix or mitigation, the timeline is at the sole discretion of the code owner or licensee, who will assess feasibility and allocate resources as appropriate. Typically, we aim to develop and release a patch within 30 days when technically feasible and resources are available. Public disclosure is at the discretion of the code owner or licensee after the fix is released. If a vulnerability is accepted, we will credit the reporter in the release notes (unless you prefer to remain anonymous), issue a patch release as soon as possible, and publish a security advisory on GitHub. If a vulnerability is declined, we will explain why with a detailed response.

The following are in scope for security reports: authentication bypass (JWT, API Key validation), authorization escalation (RBAC role bypass, RLS circumvention), SQL injection or database exposure, sensitive data leakage in API responses, Server-Side Request Forgery (SSRF), Remote Code Execution (RCE), and exposed secrets or credentials in source code.

The following are out of scope: vulnerabilities in Supabase infrastructure (report to Supabase), vulnerabilities in Vercel infrastructure (report to Vercel), vulnerabilities in Uptash infrastructure (report to Uptash), vulnerabilities in third-party services (OpenAI, Google Cloud, etc. - report directly to the provider), Denial of Service attacks, social engineering, and issues in third-party dependencies without a working exploit against this project.

This project runs automated security checks on every CI build: Trivy scans Docker images for known CVEs — results are uploaded to the GitHub Security tab (SARIF), Supabase RLS enforcement at the database level is tested as part of the integration test suite, and TypeScript strict mode prevents type coercion vulnerabilities at compile time.

This project uses a dual license model (see License Terms and Conditions): Natuleadan Free License for organizations with less than $100k/year revenue (FREE), and Natuleadan Business License for organizations with $100k/year or more revenue (custom pricing). Both licenses include absolute ethical restrictions with no exceptions — for the complete list of prohibited uses, see License Terms and Conditions Section 4 (Universal Prohibitions).

Violation of ethical restrictions results in immediate license revocation and possible legal action. Security vulnerabilities that enable prohibited uses will be treated as critical priority and may also be referred to relevant authorities.