Legal document · v1.0
Vulnerability Disclosure Policy
How to report a security vulnerability, what we commit to in return, and what is out of scope.
In plain language
This summary is provided to help you understand the document. It is not a substitute for the formal text below, which governs.
- Report to security@khepee.com. We acknowledge within two business days.
- Good-faith research following this policy will not be met with legal action.
- Do not access other people’s data, and do not test in production against real borrowers.
- We will credit you if you want it.
1Reporting
1.1
Where
security@khepee.com. If the issue is sensitive, say so and we will arrange an encrypted channel.
1.2
What to include
The affected component, reproduction steps, the impact you believe it has, and any proof of concept. Clear reports get fixed faster.
1.3
Acknowledgement
Within two business days of receipt.
1.4
Progress updates
At least every ten business days until resolution or a decision not to act, with reasons.
1.5
Disclosure timing
We ask for ninety days before public disclosure, or sooner if we have fixed and deployed. If we need longer we will explain why rather than go quiet.
2Safe harbour
2.1
No legal action
We will not pursue legal action against anyone who acts in good faith and follows this policy.
2.2
Good faith means
Avoiding privacy violations and service degradation, not accessing or modifying data belonging to others, and stopping as soon as you have demonstrated the issue.
2.3
If you go too far
Accessing another person’s data beyond what is needed to demonstrate a flaw, or exfiltrating data, falls outside this policy.
2.4
Third parties
This safe harbour covers systems we operate. It cannot bind our partner institutions or service providers.
3Scope
3.1
In scope
The khepee.com website, the Khepee borrower application, the operations console and the platform API.
3.2
Out of scope
Systems operated by partner institutions, third-party services, and anything hosted on a domain we do not control.
3.3
Do not test in production against real data
Do not attempt to access real borrower records. Ask us for a test environment; we would rather provide one than have you probe live data.
3.4
Prohibited techniques
Denial of service, social engineering of our staff or partners, physical attacks, and spam.
3.5
Low-severity findings
Missing best-practice headers with no demonstrable impact, self-XSS, and issues requiring a fully compromised device are generally accepted risks rather than vulnerabilities. Report them anyway if you disagree — we will explain our reasoning.
4What we do with a report
4.1
Triage
We assess severity and impact, and tell you our assessment.
4.2
Fix
Critical issues are addressed as a priority. We will tell you when a fix is deployed.
4.3
Partner notification
Where a vulnerability could have affected partner data, we notify the affected institutions.
4.4
Credit
We are glad to credit reporters publicly. Tell us how you would like to be named, or that you would prefer not to be.
4.5
Rewards
We do not currently run a paid bounty programme, and we will not imply otherwise. If that changes it will be published here.
4.6
Honest position
Khepee is pre-launch and has not yet had an independent penetration test. Reports from researchers are genuinely valuable to us at this stage, and will be treated that way.