HireLens

Project

Security policy

Found a vulnerability? Do not open a public issue — here is the private path, and what the project does to earn trust.

Reporting a vulnerability

  1. Use GitHub's private vulnerability reporting on the repository, or contact the maintainer directly through LinkedIn.
  2. Include: affected component, reproduction steps, impact assessment, and any proof-of-concept.
  3. You'll get an acknowledgement and a fix timeline. Coordinated disclosure — credit given.

Security posture

  • Secrets: never in code. Every env var is documented in .env.example files; secret scanning runs in CI.
  • Trust boundaries: Zod schemas validate HTTP bodies, LLM output, env vars, and file uploads. A partial LLM config fails at boot rather than half-working.
  • Auth: Better Auth with HTTP-only signed cookies; a partial OAuth config disables the provider rather than degrading.
  • Demo endpoint: the public no-signup scorer is rate-limited per IP and globally, and caches results. It exposes only synthetic data.
  • Integrity: the audit log is append-only and hash-chained — tampering is detectable by recomputing the chain.

Data handling expectation

HireLens is self-hosted: candidate data lives in your database, under your controls. The project's own surface holds none of it. If your deployment must not send resume text to any third party, use the local Ollama mode — the entire pipeline then runs inside your network.

Supported versions and the response process are detailed in SECURITY.md.