Security Policy & Vulnerability Disclosure

Introduction & Commitment

Frogeye exists to make security analysis fast and accessible for every developer. We hold ourselves to the same standard we help others achieve: security is not an afterthought, it is an engineering discipline embedded in every layer of how we build and operate our platform.

This policy defines Frogeye's security posture, technical controls, and obligations to users. It applies to all Frogeye systems and personnel.

Scope

Infrastructure Security

Cloud Run — MCP Server (mcp.frogeye.ai)

The Frogeye MCP server runs as a managed containerized workload on Google Cloud Run in us-central1:

• Non-root execution: Containers run as user node (UID 1000). Root access is never granted inside the container.
• Immutable containers: Each deploy produces a new, immutable container image. No in-place mutation of running containers.
• Automatic TLS: All traffic to mcp.frogeye.ai is TLS-terminated by GCP's managed load balancer. Certificates are provisioned and rotated automatically.
• Health monitoring: A /health endpoint is polled continuously by Cloud Run. Unhealthy instances are replaced automatically without manual intervention.
• No direct internet exposure: Containers are in a VPC-native network. Only Cloud Run's managed ingress routes traffic to the service. No ports are directly internet-accessible.
• Stateless per request: The MCP server holds no session state between requests. Compromise of a single request cannot expose state from other users.

Vercel — Frontend (frogeye.ai)

• Edge network: Vercel's global edge network absorbs DDoS traffic before it reaches application logic.
• Automatic HTTPS: All connections are TLS-encrypted. HTTP requests are permanently redirected to HTTPS.
• Preview isolation: Preview deployments are isolated from the production environment. They share no database connection, secrets, or allowlist.
• Runtime: Node.js 20 (LTS). Vercel's build pipeline validates the Node version on every deploy.
• Zero-downtime deploys: Traffic is cut over only after a successful build and health check.

Neon PostgreSQL

• Encrypted connections: All connections require sslmode=require. Cleartext connections are rejected.
• pgvector extension: Semantic similarity search for vulnerability patterns uses the pgvector extension (embedding <=> $1 with LIMIT enforced on every query).
• Connection pooling: Database connections are pooled to prevent connection exhaustion under load.
• Automatic backups: Neon provides continuous WAL-based backups with point-in-time recovery.

Upstash Redis

• TLS-encrypted: All connections to Redis are TLS-encrypted.
• Exclusive rate-limiting use: Redis is used solely to enforce per-IP and per-API-key rate limits. No sensitive user data, session tokens, or personal information is stored in Redis.
• No persistence of user data: Redis data is ephemeral. No user content survives a Redis flush.

GCP Secret Manager

• Centralized secret storage: All 21 production secrets are stored in GCP Secret Manager under the frogeye-prod- prefix.
• Zero hardcoded credentials: No credentials, API keys, or secrets exist in source code, container images, Dockerfiles, or environment variable defaults.
• Runtime injection: Secrets are injected at container startup via Cloud Run's native Secret Manager integration.
• Audit logging: Every secret access is recorded in GCP Cloud Audit Logs. Unauthorized access attempts trigger alerts.
• Cloud KMS encryption: Secrets are encrypted using Google Cloud Key Management Service before storage.

Data Security

Data Classification

Encryption at Rest

• Neon PostgreSQL: AES-256 encryption at rest for all database volumes, including the patterns, users, api_keys, and hitl_queue tables.
• GCP Secret Manager: Encryption managed by Cloud KMS. Frogeye does not manage encryption keys directly — Google's hardware security modules protect the master keys.

Encryption in Transit

TLS 1.2 or higher is enforced on every connection in the Frogeye stack:

• Vercel edge (frogeye.ai) — TLS 1.3 preferred
• Cloud Run (mcp.frogeye.ai) — TLS 1.3 preferred
• Neon PostgreSQL — TLS 1.2+, sslmode=require
• Upstash Redis — TLS 1.2+
• Stripe — TLS 1.2+, PCI-mandated

Data Minimization

• Free/Anonymous tier: No account creation required. Frogeye stores only the requesting IP address and scan result metadata. No name, email, or personal identifier is collected.
• Authenticated tiers: Email address and OAuth provider identifier only. No passwords are ever stored by Frogeye.
• Scan input: Source code submitted for analysis is processed in-memory and is not persisted. Only the resulting vulnerability classification and metadata are stored, not raw source.

Apex Tier — Embedding Clarification

Vulnerability Pattern Anonymization

The Frogeye knowledge graph contains 1,809 vulnerability patterns derived from real codebases. Before a pattern enters the knowledge graph:

• Repository names, file paths, author names, and commit hashes are stripped.
• Patterns are normalized to remove project-specific identifiers.
• Only the structural vulnerability signature and its classification are retained.

No raw repository content or identifying information is present in the patterns table.

Access Controls

Authentication

• Supported providers: GitHub OAuth and Google OAuth only.
• No passwords: Frogeye never stores, hashes, or handles user passwords. Credential management is fully delegated to GitHub and Google.
• Minimal OAuth scopes: GitHub OAuth requests read:user and user:email only — no access to private repositories unless explicitly granted. Google OAuth requests email and profile only.

API Key Management

Allowlist & Admin Access

• All authenticated logins pass an allowlist check. The user's email must exist in the allowlist table before a session is issued.
• Admin functionality is gated by database-level role checks, not client-side flags.
• No standing production database access for any team member. Production access requires deliberate action and leaves an audit trail.
• Access permissions are reviewed quarterly. Departed team members are revoked within 24 hours of offboarding.

Rate Limiting

• Per-IP rate limits apply to all unauthenticated endpoints.
• Per-API-key rate limits apply to authenticated MCP endpoints.
• Quota limits are tier-dependent and enforced at the API layer before database operations.

Vulnerability Management & Patching SLAs

Severity Classification & Response Times

SLAs are measured from the time of confirmed internal acknowledgment, not from initial report receipt.

Dependency Scanning

• Automated dependency scanning runs on every commit and pull request via GitHub Dependabot.
• Dependabot alerts are reviewed weekly. Critical and High alerts block merge until resolved.
• @frogeye/sdk and @frogeye/connect are included in the scanning scope.

Container Security

• Container images are scanned for known CVEs on every Cloud Run deploy.
• Base images are pinned to specific digests, not floating tags, to prevent supply chain injection.
• Outdated base images are rotated on a regular cadence independent of application changes.

Incident Response

Process Overview

All security incidents follow a five-phase response:

1. Detection — Identify the incident via monitoring, alert, or external report
2. Contain — Isolate affected systems to prevent spread (revoke API keys, block IPs, disable endpoints)
3. Eradicate — Remove the root cause (patch vulnerability, rotate compromised credentials, redeploy clean containers)
4. Recover — Restore normal operations with verification that the threat is eliminated
5. Post-mortem — Document timeline, root cause, impact, and control improvements within 5 business days

Severity Levels & Response SLAs

Data Breach Notification

If a security incident results in unauthorized access to user personal data:

• Affected users are notified within 72 hours of confirmed breach (GDPR Article 33 compliance).
• Notification includes: what data was accessed, when the breach occurred, what Frogeye has done to contain it, and what users should do.
• Where required by applicable law, supervisory authorities are notified within the same 72-hour window.

Third-Party Security

Frogeye relies on the following third-party vendors for core infrastructure. Each is evaluated for security posture before use and reviewed annually.

GitHub OAuth Scope Policy

Frogeye's GitHub OAuth integration requests only read:user and user:email. It does not request access to repositories. Users who later grant repository access for extended features can revoke it at any time from their GitHub security settings.

Security Assessments & SOC 2 Roadmap

Current Security Posture

• Internal security reviews conducted before every major feature release
• Automated dependency vulnerability scanning (Dependabot) on all repositories
• Secret scanning enabled on all Frogeye GitHub repositories — committed secrets trigger immediate alerts
• GCP Security Command Center monitoring enabled for the polygon-1296 project
• All secret access audited via GCP Cloud Audit Logs

SOC 2 Roadmap

SOC 2 reports will be made available to enterprise customers under NDA upon request.

Penetration Testing

An independent third-party penetration test is planned for Q4 2026. The scope will include the frogeye.ai frontend, mcp.frogeye.ai API surface, and the @frogeye/sdk and @frogeye/connect npm packages.

Bug Bounty

Frogeye operates a coordinated responsible disclosure program. At this stage, rewards are recognition-based: accepted reports receive public credit in the Frogeye Hall of Fame and direct acknowledgment from the security team. A monetary bug bounty program will be evaluated following the SOC 2 Type I audit. See frogeye.ai/security for current scope and safe harbor terms.

Employee & Contractor Security

Access Provisioning

• All personnel with access to production systems complete a background check prior to being granted access.
• Access follows the principle of least privilege. No team member receives standing access to production databases or GCP Secret Manager.
• Production access requires explicit request, is time-limited, and is logged.

Security Training

• All team members and contractors complete security awareness training within 30 days of joining.
• Refresher training is conducted quarterly, covering phishing, social engineering, incident reporting, and secure development practices.

Offboarding

• All system access is revoked within 24 hours of a team member's departure.
• Offboarding checklist includes: GCP IAM revocation, GitHub organization removal, Vercel team removal, and rotation of any secrets the individual had access to.
• Unmanaged or personal devices are never permitted to access production systems without explicit security review and MDM enrollment.

Data Retention & Deletion

Right to Erasure

Users may request deletion of all personal data associated with their account by emailing security@frogeye.ai with subject line "Data Deletion Request." Frogeye will confirm receipt within 48 hours and complete deletion within 30 days. A confirmation email is sent upon completion.

Anonymized vulnerability patterns derived from a user's scans are not subject to deletion requests, as they contain no personally identifiable information and cannot be attributed to an individual.

Contact