We take the security of Social Publish seriously. Below is the support lifecycle matrix for security updates:

If you discover a security vulnerability within Social Publish, please do not report it publicly via GitHub Issues or discussions.

• Email: Send detailed vulnerability reports to security@socialpublish.io (or maintainers directly).
• PGP Key: If transmitting sensitive reproduction payloads or proof-of-concept exploits, request our PGP public key beforehand or encrypt using our security team key.

To help us triage and validate your report swiftly, please include:

1. Vulnerability Type: (e.g., SSRF, Remote Code Execution, Authentication Bypass, Broken Object-Level Authorization / IDOR, Cross-Site Scripting).
2. Component Affected: Specific controller, service, integration adapter, or configuration class.
3. Step-by-step Reproduction Steps: Clear instructions or a minimal reproducible curl / HTTP request.
4. Impact Assessment: What an attacker could achieve (e.g., unauthorized access to third-party OAuth access tokens, arbitrary post injection).
5. Mitigation / Remediation Suggestions: If you have a suggested fix or architectural mitigation.

• Initial Response: Within 48 hours acknowledging receipt of the report.
• Triage & Assessment: Within 5 business days confirming vulnerability reproduction and assigning a CVSS score.
• Fix & Patch Delivery: Priority security patches are typically deployed within 14 calendar days for high/critical severity issues.
• Public Disclosure: Coordinated disclosure after the patch has been released and users have had sufficient time to upgrade.

Social Publish enforces strict security baselines across its tech stack:

• Zero Plaintext Secrets: OAuth2 client secrets, access tokens, refresh tokens, and bot API keys are strictly configured via environment variables and never logged.
• CSRF Protection: Enabled on all mutation endpoints via Spring Security CSRF tokens (_csrf).
• Session Security: Session tokens are HttpOnly, Secure, and SameSite=Lax backed by isolated Redis storage with strict idle timeouts.
• Role-Based Access Control (RBAC): All user actions are isolated by userId to eliminate Insecure Direct Object References (IDOR).
• Rate Limiting: Critical endpoints (login, OAuth callbacks, AI generation) are rate-limited to prevent brute-force and resource exhaustion.
• Webhook Validation: Social platform webhook callbacks enforce signature verification where supported.

For a comprehensive breakdown of our STRIDE threat model, security boundaries, and cryptographic controls, see docs/THREAT_MODEL.md.