Legal
Security Vulnerability Disclosure Policy
This policy applies to all digital assets operated by Purehire. Read Section 5 before beginning any security research. Operated by Febin and Dale Ventures Private Limited.
Effective Date: May 1, 2026·Last Updated: April 28, 2026·Governing Law: Republic of India·Jurisdiction: Kozhikode, Kerala
§1
Purpose and Scope of This Policy
Purehire, operated by Febin and Dale Ventures Private Limited, welcomes responsible security research and coordinated disclosure. This policy establishes the terms under which external researchers may report security vulnerabilities affecting Purehire's digital infrastructure.
This policy applies to all digital assets operated by Febin and Dale Ventures Private Limited under the Purehire brand: the web platform at purehire.in, all APIs, and any associated subdomains.
This policy does not grant permission to conduct security testing without prior written authorisation beyond what is explicitly described herein. Discovering a vulnerability does not retroactively authorise the method used to find it.
Purehire operates under Indian law. Both the company and the researcher are subject to the Information Technology Act 2000, the Digital Personal Data Protection Act 2023, and related rules. Any conduct that violates these statutes is outside the scope of this policy, regardless of stated intent.
§2
Definitions
The following terms are used throughout this policy. Each term has a precise meaning; do not substitute informal equivalents.
| Term | Definition |
|---|---|
| Vulnerability | A weakness in Purehire's systems, code, or configuration that could be exploited to compromise the confidentiality, integrity, or availability of data or services. |
| Responsible Disclosure | Reporting a discovered vulnerability directly and privately to Purehire, allowing reasonable time for remediation before any public disclosure. |
| Researcher / Reporter | Any individual or entity who discovers and reports a vulnerability under this policy. |
| Good-Faith Research | Testing conducted without accessing data beyond what is necessary to confirm the existence of the vulnerability, without disrupting service, and without exploiting the vulnerability for any purpose other than demonstration. |
| Proof of Concept (PoC) | Technical evidence demonstrating the existence and potential impact of a vulnerability, without executing the exploit to its full harmful extent. |
| Coordinated Disclosure | A mutually agreed process where the researcher allows Purehire to remediate before any public disclosure. |
| Business Days | Monday through Friday, excluding Indian public holidays. |
§3
How to Report a Vulnerability
Step 1 — Contact
Send a report to: security@febinanddale.com
Use the subject line: [SECURITY REPORT] <brief description>
Step 2 — What to Include (All Fields Required for Processing)
| Field | Detail |
|---|---|
| Vulnerability description | What the issue is, where it exists (URL, endpoint, or component) |
| Steps to reproduce | Numbered, reproducible steps from a clean state |
| Impact assessment | What data or functionality is at risk; severity estimate (Low / Medium / High / Critical) |
| Evidence | Screenshots, HTTP request/response captures, or PoC code — sufficient to confirm the issue without full exploitation |
| Your contact details | Name (or handle) and email address for follow-up |
| Disclosure preference | Whether you consent to public credit; whether you request anonymity |
Step 3 — Encryption (Optional)
If the vulnerability is Critical or High severity, consider encrypting your report. Contact security@febinanddale.com first to request a PGP key if required.
Step 4 — Do Not
Do not post the report publicly, share it with third parties, or submit it through any channel other than the email above while awaiting Purehire's response. Reports submitted through social media, GitHub issues, or other public channels will not receive the protections of this policy.
Note on the security email address: The correct address is security@febinanddale.com. Any variation (e.g. "securityg@") is a typo. If you are uncertain, verify before sending.
§4
Response Timeline and Commitments
| Milestone | Commitment | Clock Starts |
|---|---|---|
| Acknowledgment | Within 2 business days | Date report received |
| Triage / Confirmation | Within 7 calendar days | Date of acknowledgment |
| Remediation Target | Within 30 calendar days of confirmed vulnerability | Date of confirmation |
| Public Disclosure | 30 calendar days after fix is live | Date fix is deployed |
| Status Updates | Every 7 days if fix is delayed beyond initial target | Date confirmation sent |
Extensions
- If a fix cannot be completed within 30 days due to complexity, Purehire will notify the researcher with a revised timeline, an explanation, and interim mitigation steps taken.
- Maximum extension without researcher consent: 30 additional days (total 60 days from confirmation).
- Beyond 60 days, the researcher may disclose publicly with a minimum of 7 days' advance notice to Purehire.
What Purehire commits to
- Treat each report as legitimate until investigation proves otherwise
- Keep the researcher informed at each milestone
- Credit the researcher in the public changelog and acknowledgements (consent required)
- Not pursue legal action against researchers who comply with this policy in good faith
What Purehire does not commit to:
- Fixing every reported issue within 30 days — some systemic issues may require longer and will be communicated.
- Monetary compensation (see Section 7).
- Treating reports submitted outside the defined process (e.g. via social media) under the same protections.
§5
Scope
5.1 In Scope — Reports Are Accepted and Acted Upon
All of the following on Purehire-operated systems:
| Category | Examples |
|---|---|
| Authentication and authorisation flaws | Session fixation, privilege escalation, broken access control, insecure direct object references (IDOR) |
| Injection vulnerabilities | SQL injection, command injection, LDAP injection, template injection |
| Cross-site scripting (XSS) | Stored XSS, reflected XSS (excludes Self-XSS — see Out of Scope) |
| API security vulnerabilities | Unauthenticated endpoints, excessive data exposure, missing rate limiting on sensitive endpoints (login, password reset) |
| Data exposure | Unintended exposure of personal data — resume content, contact details, payment metadata |
| Cryptographic weaknesses | Weak algorithms, improper certificate validation, insecure key storage |
| Insecure file upload | Unrestricted file type, path traversal via upload |
| Server-side request forgery (SSRF) | Requests routed through Purehire servers to internal infrastructure |
| Infrastructure / configuration issues | Open cloud storage buckets, exposed admin panels, publicly accessible debug endpoints |
| Broken access to AI pipeline | Ability to extract or poison resume scoring inputs/outputs |
5.2 Out of Scope — Reports Will Not Be Acted Upon
The following will not be accepted as actionable reports. Conducting these activities is also a violation of this policy:
| Category | Reason |
|---|---|
| Social engineering of employees or users | Not a technical vulnerability; covered separately |
| Physical security of offices or hardware | Outside the scope of this digital policy |
| Brute force attacks on user accounts | Constitutes unauthorised access; policy does not protect this activity |
| Volumetric denial-of-service (DoS/DDoS) | Causes harm; not a research activity |
| Self-XSS | Requires victim to execute their own payload; not exploitable by an attacker |
| Content spoofing (UI text only, no data risk) | No security impact |
| Missing non-critical security headers (e.g. X-Frame-Options on non-sensitive pages) | Low impact; addressed in routine hardening |
| Rate limiting on non-sensitive, non-authenticated endpoints | Not a vulnerability in development-stage platforms |
| Vulnerabilities in third-party services (Razorpay, Google, Groq) | Report directly to those vendors |
| Theoretical vulnerabilities without a working PoC | Cannot be triaged without evidence |
| Vulnerabilities on systems not operated by Febin and Dale Ventures Private Limited | Out of scope by definition |
Accessing any user data — even to demonstrate a vulnerability — beyond what is minimally necessary to confirm the flaw exists is a violation of this policy and of the IT Act 2000. Use test accounts only.
5.3 Use of Test Accounts
- Researchers must create their own test accounts for all testing activity.
- Accessing, downloading, or viewing any real user's data (resumes, contact details, payment records) during research is prohibited, regardless of intent.
- Any incidental exposure of real user data during research must be immediately reported alongside the vulnerability report.
If you are uncertain whether a target or technique falls within scope, send a preliminary inquiry to security@febinanddale.com before proceeding.
§6
Rules of Engagement (What NOT to Do)
The following are absolute prohibitions. Violation of any of these removes all legal protections extended by this policy.
| Prohibited Action | Consequence of Violation |
|---|---|
| Publicly disclose the vulnerability before Purehire releases a fix | Removal of all policy protections; potential legal action under IT Act 2000 |
| Exploit the vulnerability beyond the minimum PoC necessary to confirm it | Constitutes an offence under IT Act 2000 Section 43 and Section 66 |
| Access, copy, modify, or exfiltrate real user data | Constitutes an offence under IT Act 2000 Section 43 and DPDPA 2023; policy provides no protection |
| Disrupt platform availability (DoS, flooding, resource exhaustion) | Constitutes an offence under IT Act 2000 Section 43(f) |
| Conduct social engineering of Purehire employees or users | Policy provides no protection; potential criminal liability under IPC |
| Demand payment or preferential treatment in exchange for the report | Constitutes extortion under IPC Section 383; will be reported to law enforcement |
| Share the vulnerability with third parties before a fix is released | Removal of all policy protections |
| Conduct testing that affects other users' experience or data | Prohibited regardless of intent |
| Automate scanning at volumes that degrade platform performance | Prohibited regardless of intent |
Violation of any rule in this section removes all protections granted by this policy, including the commitment not to pursue legal action. Purehire will report conduct that constitutes a criminal offence to the appropriate Indian law enforcement authorities.
§7
Recognition and Incentives
Current programme status (as of April 3, 2026): Purehire does not offer a monetary bug bounty programme.
What is offered to qualifying reporters (in-scope, good-faith, confirmed vulnerability):
| Incentive | Detail |
|---|---|
| Public acknowledgement | Named credit in Purehire's security acknowledgements page (consent required) |
| Changelog credit | Named in the release notes for the fix (consent required) |
| Complimentary job posting | One job post credit (₹199 value) issued upon fix confirmation |
| Anonymity | Full anonymity honoured if requested; no details disclosed without consent |
What is not offered:
- Monetary compensation of any kind at this time.
- Equity, discounts beyond the above, or contractual commitments for future programmes.
Future programme: Purehire may introduce a formal monetary bounty programme as the platform scales. Researchers who have contributed confirmed vulnerabilities under this policy will be notified when such a programme launches. This is a statement of intent only, not a contractual commitment.
§8
Confidentiality Obligations
Purehire's Obligations to the Researcher
- Purehire will not disclose the reporter's identity, contact details, or the content of their report to any third party without the reporter's explicit written consent.
- Purehire will not disclose the existence of a reported vulnerability publicly until a fix has been released, except as required by law (e.g. CERT-In mandatory reporting obligations).
- If disclosure is legally required before a fix is ready, Purehire will notify the reporter simultaneously.
Researcher's Obligations to Purehire
- The researcher must keep all vulnerability details, Purehire's response communications, and any data incidentally accessed during research strictly confidential until public disclosure is mutually agreed.
- The researcher must not discuss the vulnerability in any public or semi-public forum — including security communities, mailing lists, or social media — until the coordinated disclosure date.
- If the researcher wishes to publish research after the fix is released, they must share a draft with Purehire at least 5 business days before publication. Purehire may request removal of sensitive technical details but may not unreasonably block publication.
§9
Legal Protections and Limitations
9.1 Protected Activity
Purehire will not initiate civil or criminal legal action against a researcher who:
- Discovers and reports a vulnerability in good faith
- Complies fully with all rules in Section 6 of this policy
- Does not access real user data beyond incidental minimum
- Does not disrupt service availability
- Does not demand compensation beyond what is offered in Section 7
This protection is extended under this policy as a statement of intent and does not constitute a legal waiver of any statutory right. It is contingent on strict compliance with this policy.
9.2 Activities NOT Protected
The following activities are not protected by this policy, regardless of claimed research intent: any action that violates Section 6; accessing, downloading, or retaining real user data; extortion or demands for payment in exchange for disclosure; disclosure of the vulnerability to any party other than Purehire prior to fix release; any activity that constitutes an offence under the IT Act 2000, IPC 1860, or DPDPA 2023.
9.3 Applicable Law
All activity related to this policy, and any disputes arising from it, are governed by the laws of the Republic of India. The courts of Kozhikode, Kerala shall have exclusive jurisdiction.
9.4 Relevant Indian Legal Provisions (Informational)
The following laws may apply to unauthorised computer access or data exposure in India:
| Provision | Applies To |
|---|---|
| IT Act 2000 — Section 43 | Penalty for unauthorised access, damage, or extraction of data from a computer system |
| IT Act 2000 — Section 66 | Criminal penalty (imprisonment up to 3 years) for dishonest or fraudulent computer-related offences |
| IT Act 2000 — Section 66C / 66D | Identity theft and impersonation |
| IPC Section 383 | Extortion (applicable if payment is demanded in exchange for disclosure) |
| DPDPA 2023 | Obligations around personal data accessed during research |
This section is informational, not a threat. Researchers acting in good faith within the scope of this policy have nothing to fear. It exists to ensure all parties understand the legal environment.
9.5 CERT-In Reporting Obligation
Purehire is subject to CERT-In (Indian Computer Emergency Response Team) reporting obligations under the IT (Amendment) Act and CERT-In directions. In the event of a breach or significant vulnerability, Purehire may be required to report to CERT-In within mandated timelines independently of this disclosure policy.
§10
Policy Versioning and Changes
- This policy is effective from April 3, 2026.
- Material changes — affecting scope, timelines, legal protections, or incentives — will be announced via the Purehire website and take effect 15 days after publication.
- Non-material changes (formatting, contact details, clarifications) take effect immediately upon publication.
- The version number and effective date are displayed at the top of this document.
Researchers who submitted reports under a prior version of this policy retain the protections offered by that version for their specific report, regardless of subsequent changes.
§11
Contact
| Channel | Detail |
|---|---|
| Security reports | security@febinanddale.com |
| Subject line format | [SECURITY REPORT] <brief description> |
| Acknowledgment SLA | 2 business days (Mon–Fri, Indian business hours) |
| General policy enquiries | security@febinanddale.com |
| Postal address | Febin and Dale Ventures Private Limited, Kunnamangalam, Kozhikode, Kerala — 673571, India |
Do not report vulnerabilities via social media, GitHub issues, or any channel other than the email above. Reports submitted through other channels will not receive the protections of this policy.