This project is pre-1.0 and only the latest main is supported.

Please do not open a public issue for security vulnerabilities.

Use GitHub's private vulnerability reporting to report privately. Include:

• vulnerability description
• reproduction steps
• potential impact
• suggested fix (if available)

We will acknowledge receipt as soon as possible and aim to provide a remediation timeline after triage.

• Runtime container runs as non-root user (node) by default.
• API keys are required in non-test environments.
• TOKEN_ENCRYPTION_SECRET is required in non-test environments (fail-closed startup).
• X.com OAuth access/refresh tokens are encrypted at rest using AES-256-GCM-derived key material.
• OAuth callback enforces state validation (anti-CSRF), short-lived pending state TTL, and redirect URI allowlist (OAUTH_REDIRECT_ALLOWLIST).
• OAuth flows use poll-token isolation: the state parameter alone cannot retrieve provisioned API keys.
• Portal authentication uses HttpOnly, SameSite=Lax session cookies (no client-side token storage).
• Portal frontend uses safe DOM construction (no innerHTML); Content-Security-Policy blocks unsafe-inline scripts.
• GET /ops/status requires both bearer auth and x-ops-admin-key matching OPS_ADMIN_KEY.
• If OPS_ADMIN_KEY is not configured, /ops/status is fail-closed (explicitly denied).
• Authentication never bypasses due to NEWSINTEL_DISABLE_REMOTE_FETCH.
• Use strong random keys and rotate secrets regularly.
• Prefer hardened container runtime flags in production (--read-only, --cap-drop ALL, --security-opt no-new-privileges:true).
• Sentry error tracking (when enabled) scrubs authorization, x-ops-admin-key, cookie, and x-api-key headers before transmission.

main is protected with the following repository policy:

• required status checks: test, secret-scan
• require branches to be up to date before merging (strict)
• require at least 1 approving review
• dismiss stale reviews on new pushes
• require code owner review
• require conversation resolution before merge
• enforce protections for admins (enforce_admins = true)
• linear history enabled
• force-pushes disabled
• branch deletion disabled

These settings are part of the public-release hardening baseline and should be kept aligned with the active CI/review workflow set.

• The .env file was never committed to git history. Only .env.example (with placeholder values) exists in the initial commit.
• .gitignore correctly excludes .env and .env.* (except .env.example).
• Source code scan: no hardcoded secrets found — all credentials are loaded from environment variables via config.ts.
• CI now includes automated secret scanning via gitleaks.

If credentials are suspected to be compromised, rotate in this order:

1. API_KEYS / WORKSPACE_API_KEYS — generate new random values, update .env, restart API.
2. OPS_ADMIN_KEY — generate a new 32-byte hex secret: openssl rand -hex 32.
3. TOKEN_ENCRYPTION_SECRET — generate a new 32-byte hex secret. Warning: rotating this invalidates all encrypted OAuth tokens at rest; affected users must re-authorize.
4. X_OAUTH_CLIENT_SECRET — rotate in the X Developer Portal, then update .env.
5. DATABASE_URL / REDIS_URL — rotate database/Redis passwords and update connection strings.
6. SENTRY_DSN — revoke old DSN in Sentry dashboard and create a new one.

After rotation:

• Restart all running containers.
• Verify health: curl http://localhost:8090/healthz.
• Monitor /ops/status for component health.
• Review Sentry for any post-rotation errors.

For broader operational incidents (severity classification, escalation, communication, and post-mortems), see docs/incident-response.md. For escalation windows and on-call handoff expectations, see docs/ON_CALL.md. For backup, restore, and disaster recovery procedures, see docs/backup-recovery.md.