Security Practices — Jobeezy

At rest

All user data is encrypted at rest using AES-256-GCM:

• Firestore: GCP-managed encryption (AES-256). Document-level security with customer-managed encryption keys (CMEK) on the roadmap.
• GCS (résumé files): GCP-managed encryption (AES-256). Bucket IAM is fully private; signed URLs (15-minute TTL) are the primary access path.
• Pub/Sub topics: At-rest encryption enabled on all message buses.
• Cloud Logging: Encrypted by default using Google-managed keys.

In transit

• Cloud Load Balancing: TLS 1.3 enforced. TLS 1.0 and 1.1 explicitly disabled.
• Mobile app → API: Certificate pinning on production builds via Expo's network layer.
• Internal Cloud Run → GCP services: All GCP SDK calls use HTTPS by default.
• AI provider calls: HTTPS only via Vertex AI endpoints. No request bodies are logged beyond operational metadata.

AI zero-retention contracts

Google Vertex AI (Gemini) is used under enterprise-grade zero-data-retention agreements. Résumé text and job descriptions sent for tailoring are not stored on provider infrastructure and are never used to train or fine-tune any foundation model. Confirmed via Google Cloud DPA.

User authentication

• Provider: Firebase Auth (Google Identity Platform).
• Tokens: Firebase ID tokens + refresh tokens. Stored in device Keychain (iOS) / Keystore (Android) via expo-secure-store.
• Passwords: Secure hashing managed by Firebase Auth; passwords never touch Jobeezy application code.
• MFA: Multi-factor authentication is available and supported for all accounts.

IAM and least privilege

• Every Cloud Run service has its own Service Account with the minimum permissions needed. No shared identities across services.
• No wildcard * resource policies. All Firestore and GCS permissions are scoped to specific collections or buckets.
• Secrets are managed via GCP Secret Manager — never stored in code or environment variables.
• CI/CD: GitHub Actions uses Workload Identity Federation for short-lived token exchange.

Rate limiting and abuse protection

• Google Cloud Armor: Managed rule groups active against OWASP Top 10, bot attacks, and DDoS.
• API rate limit: 2,000 requests per 5 minutes per IP for /api/* paths.
• Distributed rate limiting implemented via Firestore atomic counters for authenticated users.

Serverless attack surface reduction

• No always-on servers or persistent containers — Cloud Run services eliminate entire classes of vulnerability (no OS patching, no persistent network exposure).
• Cloud Run runtimes are pinned to Python 3.12 and updated in CI on each deployment.
• No SSH access to any compute. All operational changes go through Terraform or gcloud deployments.

Dependency security

• CI pipeline runs pip-audit on every PR — fails the build on any known CVE in runtime dependencies.
• bandit static analysis on all Python code — catches common security anti-patterns (hardcoded secrets, shell injection, etc.).
• ruff linter enforces no-bare-except rules, preventing silent error swallowing.
• Dependency addition policy: any new package must pass last-commit-date, weekly-download, license (MIT/Apache/BSD), bundle-size, and CVE checks before merging.

GCS security configuration

• All GCS buckets have uniform bucket-level access enabled and public access prevention enforced.
• GCS Object Versioning and Lifecycle Management ensure data durability and rotation.
• Server-side encryption using Google-managed keys on all buckets.

• All Cloud Run services emit structured JSON logs to Cloud Logging. Log format: {"level", "timestamp", "event", "actor_id", "resource", "duration_ms", "status"}.
• No PII (names, emails, résumé content) is written to logs. Log scrubbing rules are enforced by policy and reviewed in code review.
• Firestore mutations include actor_id and updated_at on every write — sufficient to reconstruct an audit trail for any record.
• Cloud Audit Logs are enabled on the GCP project for all management API calls (IAM changes, GCS bucket policy changes, etc.) with 90-day retention.
• Sentry captures all unhandled exceptions with PII scrubbing rules.

Tool	What it monitors	Alert on
Cloud Monitoring	API health, site availability, job search pipeline	HTTP status ≠ 200, latency > 3s, JSON schema mismatch
Cloud Logging	Service error rate, Firestore latency, Pub/Sub depth	Error rate > 1%, throttle events > 10/min
Cloud Armor Metrics	Blocked requests by rule, rate-limit triggers	Block rate spike > 500% baseline
Sentry	Mobile app and backend crash/error rate	New error type or error rate spike

Incident response

• Detection: Automated Cloud Monitoring alerts → Pub/Sub → status_updater updates status.jobeezy.com automatically.
• Response time: Critical issues (data breach, service outage) — on-call response within 30 minutes 24/7.
• Breach notification: Users and affected parties notified within 72 hours of confirmed breach per GDPR Art. 33/34 and applicable state laws.
• Status transparency: All incidents posted to status.jobeezy.com within 15 minutes of confirmation, with hourly updates until resolved.

Scope

• In scope: jobeezy.com, api.jobeezy.com, the Jobeezy iOS and Android apps, any subdomain of jobeezy.com.
• Out of scope: Third-party services (GCP infrastructure, Firebase, Gemini), denial-of-service attacks, social engineering of employees, physical attacks.

What we ask

• Report via email to security@jobeezy.com or via our security.txt.
• Include: affected URL/endpoint, description of the vulnerability, steps to reproduce, and potential impact.
• Allow us reasonable time to fix before public disclosure (we target 90 days for non-critical, 7 days for critical).
• Do not access, modify, or delete user data beyond what is necessary to demonstrate the vulnerability.

What we commit to

• Acknowledge your report within 72 hours.
• Provide regular status updates as we investigate and fix.
• Credit you (by name or handle) in our security disclosure if you wish.
• Not pursue legal action against researchers acting in good faith under this policy.

Our security.txt is published at /.well-known/security.txt per RFC 9116 and is kept up to date with current contact info and expiry date.

Report a vulnerability

We keep personal data only as long as it is needed to operate the service, meet a legal obligation, or resolve disputes. Retention is enforced by automated lifecycle rules and scheduled jobs rather than left to manual cleanup.

• Résumé files & documents (GCS): retained while your account is active; covered by bucket lifecycle policies and removed on account deletion.
• Raw, unprocessed job-ingestion data: short-lived and rotated automatically once postings are normalized.
• Signed download URLs: issued with a 15-minute time-to-live; there is no public read access to any file.
• Operational & audit logs: retained for a bounded window for security and reliability, then expired; logs are PII-scrubbed by policy.
• Account deletion: a verified, multi-step deletion job removes your records from production datastores within 30 days of your request; encrypted backups age out on their normal rotation. See Delete account.

• Managed redundancy. Compute (Cloud Run), database (Firestore), and storage (GCS) run on Google Cloud's regionally redundant managed services, with platform-handled failover.
• Backups. Data is continuously replicated and backed up by managed services; backups inherit AES-256 encryption and bounded retention.
• Stateless compute. Application servers hold no durable state, so instances can be replaced or scaled without data loss.
• Recovery testing. Restore procedures are documented as part of our incident-response and SOC 2 readiness work.
• Transparency. Component health and incidents are published on the status page.

We are working toward SOC 2 Type I certification (target Q3 2026), using Vanta for continuous control monitoring. Trust Service Criteria in scope: Security, Availability, and Confidentiality.

Control	Status
Encryption at rest (AES-256)	Implemented
Encryption in transit (TLS 1.3)	Implemented
Access control + IAM least privilege	Implemented
Vulnerability scanning (pip-audit + bandit)	Implemented in CI
Audit logging (Cloud Audit Logs + structured logs)	Implemented
Incident response plan	Documented
Customer-managed KMS keys (CMK)	In progress
Formal penetration test	Scheduled Q2 2026
SOC 2 Type I audit	Target Q3 2026
Employee security awareness training	In progress