Currently supporting:

If you discover a security vulnerability, please report it by:

1. Email: security@diaum.com (or create a private security advisory on GitHub)
2. Do NOT open a public issue
3. Include:
   • Description of the vulnerability
   • Steps to reproduce
   • Potential impact
   • Suggested fix (if any)

We will respond within 48 hours and work with you to resolve the issue.

1. Supabase Keys

   • NEXT_PUBLIC_SUPABASE_ANON_KEY is safe for the browser (protected by RLS)
   • SUPABASE_SERVICE_ROLE_KEY must NEVER be exposed to the browser
   • DIAUM_APP_SUPABASE_SERVICE_KEY must NEVER be exposed to the browser
   • Only use service role keys in Server Components and API routes

2. Secrets

   • Never commit .env.local to git
   • Rotate Supabase service role keys periodically
   • Use different Supabase projects for development and production

3. File Permissions

   • Ensure .env.local is readable only by the app user:

     chmod 600 .env.local

4. Reverse Proxy (if self-hosting)

   • Always use HTTPS in production
   • Configure rate limiting if exposing publicly
   • Whitelist trusted IPs for admin endpoints

5. Supabase Configuration

   • Enable Row Level Security (RLS) on ALL tables
   • Never disable RLS in production
   • Use the is_admin() function for admin-only policies
   • Review RLS policies after schema changes

1. Never commit:

   • .env.local (Supabase keys, API tokens)
   • Any file containing real credentials or tokens
   • GitHub Personal Access Tokens
   • Anthropic API keys
   • Social media API tokens

2. Environment variables:

   • Use .env.local for all secrets
   • Use .env.example as a template (with placeholder values only)
   • Never hardcode personal info, emails, or tokens in source code

3. Dependencies:

   • Run npm audit regularly
   • Update dependencies: npm update
   • Review Dependabot alerts

4. Migrations (Supabase SQL):

   • EVERY new table MUST include alter table <name> enable row level security;
   • EVERY new table MUST have at least a SELECT policy for authenticated users
   • Admin-only tables MUST use the is_admin() function in write policies
   • Never create a table without RLS — a table without RLS is fully public via the anon key
   • Review all existing policies when adding new tables that reference existing ones

5. Code Review:

   • No eval() or Function() with user input
   • Validate and sanitize all input
   • Use Supabase client SDK (parameterized queries by default)
   • Escape user-generated content in UI
   • Never pass user input directly to supabase.rpc() without validation

• Email/password auth via Supabase Auth
• Rate limiting handled natively by Supabase
• Sessions managed via @supabase/ssr (HttpOnly, Secure, SameSite cookies)
• No public registration — admin creates users via service role key
• TODO: Add 2FA support via Supabase Auth MFA

• All data stored in Supabase (PostgreSQL managed, encrypted at rest by Supabase)
• RLS policies enforce access control at the database level
• Cross-project access to Diaum app DB is read-only and server-side only

• GitHub Token: scope limited to repo and org:read
• Anthropic API Key: rate-limited per user in application code
• Social media tokens: stored in .env.local, accessed server-side only

• Dashboard frontend deployed on Vercel (HTTPS by default)
• Supabase connections use SSL
• GitHub webhooks validated via signature verification
• All external API calls made server-side (never from browser)

Before deploying to production:

• Configured Supabase project with production settings
• Verified RLS is enabled on ALL tables
• Tested RLS policies (admin vs dev access)
• Set .env.local with production keys
• Verified SUPABASE_SERVICE_ROLE_KEY is not exposed in client-side code
• Verified DIAUM_APP_SUPABASE_SERVICE_KEY is not exposed in client-side code
• Configured HTTPS (Vercel handles this automatically)
• Updated all npm dependencies
• Ran npm audit fix
• Tested auth flow (login, session expiry, role-based access)
• Verified GitHub webhook signature validation
• Reviewed Supabase Auth settings (disable signup, email confirmation, etc.)
• Documented incident response plan

We follow coordinated vulnerability disclosure:

1. Reporter notifies us privately
2. We confirm and develop a fix
3. We release a patched version
4. Disclosure is made public after patch is available

Thank you for helping keep Diaum Mission Control secure!