Report a vulnerability
If you have found a security issue in CalHire, we want to hear about it — and we will not take legal action against you for telling us.
Email our security team
A human replies within 3 business days. Encrypted mail is welcome — ask and we will exchange keys.
How disclosure works
Coordinated disclosure. We ask for time to fix before you publish; you get honest updates while we do.
- 1
Report it
Email security@calhire.com with the affected URL or endpoint, the steps to reproduce, and what you were able to access. Encrypted mail is welcome — ask and we will exchange keys.
- 2
We acknowledge
A human replies within 3 business days to confirm we have it and to tell you who is handling it. If you do not hear back, resend — we would rather have a duplicate than miss a report.
- 3
We triage and fix
We reproduce the issue, assign a severity, and tell you what we intend to do and roughly when. You get an update when the fix ships, not only when the ticket closes.
- 4
We credit you
With your permission we credit you when we write up the fix. We do not operate a paid bug bounty, and we will not imply one.
Safe harbour
If you make a good-faith effort to follow this policy, we will not pursue or support legal action against you for your research, and we will treat your report as authorised access. Stay within the scope below, only ever use accounts you own or have permission to test, stop as soon as you have confirmed an issue, and do not access, change or keep anyone else’s data. If you are unsure whether something is allowed, ask us first — we would rather answer a question than read an apology.
In scope
- calhire.com and its subdomains, including the application at app.calhire.com
- The public API endpoints those sites call
- Authentication, tenant isolation, and the anonymity boundary between candidates and employers
Out of scope
- Denial of service, load testing, or anything that degrades the service for other people
- Social engineering of our team, customers, or candidates, and physical attacks
- Automated scanner output with no demonstrated impact
- Findings that require a compromised device, a modified client, or a person to act against their own interest
- Third-party services we use but do not control — report those to the vendor
Where your data is processed
Residency is a configuration, not a promise we make once. The anonymity boundary holds in every region.
See every sub-processor- Candidate and employer data can be pinned to a region — the EU, India, or the UAE — to meet GDPR, the DPDP Act, and the PDPL.
- Residency is a configuration of where data is processed and stored; it never changes what is collected or who may see it.
- No AI model ever receives personal identifying information, in any region. Anonymisation happens at an architectural boundary before a model is called.
- Our sub-processors and the region each one handles are listed in full, and we keep that list current.
How the platform is built
Practices we can evidence today. For certification status and to request our security questionnaire, see the Trust Center.
TLS 1.2 or better in transit; encryption at rest for candidate and employer data.
Tenant isolation enforced twice — in the database with row-level security, and again in application code.
Least-privilege access with audited authentication, and an immutable audit trail on every permission and billing event.
Secrets live only in environment configuration — never in code, config files, or the database.
Every dependency is screened for known advisories before it ships, and the build fails on a high or critical finding.