Security and responsible disclosure

Who we are

Djembely is owned and run by Melian Dialogue Limited (the "Company"). It is a private limited company set up in the Republic of Kenya.

Registered Office: P.O. Box B1003, Urban Oasis Apartments, Kingara Road, Lavington, Nairobi.

Company Registration No.: PVT-27ULY98K.

KRA PIN: P052416974R.

How to report a vulnerability

A vulnerability is a weak spot that someone could misuse. If you find one, email security@djembely.com. Please tell us clearly what you found, the web address (URL) or part of the system affected, and the steps we need to follow to see the problem ourselves.

PGP (a way to encrypt your email so only we can read it) is available if you ask.

Please do not tell the public about the problem until we have had a fair chance to fix it.

Our official, machine-readable policy is at https://djembely.com/.well-known/security.txt, following RFC 9116.

Safe harbour for good-faith research

"Safe harbour" means we will not treat honest researchers as wrongdoers. "Good faith" means you are trying to help, not to cause harm.

• ·If you make an honest effort to follow this policy during your research, we will treat your research as authorised. We will not take legal action against you, and we will not support anyone else doing so. We will work with you to understand and fix the issue quickly.
• ·Good faith means three things. First, you avoid breaking anyone's privacy, destroying data, or making the service worse for others. Second, you only use test accounts that you own or have clear permission to use. Third, you give us a fair amount of time to reply before you share anything publicly.
• ·Djembely is practice trading only. It uses virtual money, so no customer's real money is at risk. But the personal data of users (email, date of birth and journalling notes) is real. You must never look at it, copy it out or destroy it during your research.

What happens after you report: intake and triage

"Triage" means sorting reports by how serious and urgent they are.

• ·Acknowledgement: we aim to confirm we have received every report within 2 business days.
• ·Triage: our security owner checks how serious the problem is (guided by CVSS, a common scoring system for how bad a weakness is) and whether it can be repeated. We aim to give a first assessment within 5 business days.
• ·Fix targets: Critical within 7 days, High within 30 days, Medium within 90 days, and Low as scheduled. We keep you updated at each stage. Once a fix is released, we will credit you by name if you would like that.
• ·This is a clear process, not a paid bug-bounty programme (a scheme that pays rewards for finding bugs). We may start a bounty later.

Incident response (the live plan)

The admin console keeps a log of incidents after they happen (Menu 10). This is different. It is the plan we follow in the moment, when a problem is found or used by an attacker:

• ·1 · Declare and assign: we name an incident commander (the person in charge) and decide how serious it is.
• ·2 · Contain: we cut off the affected parts and change any secrets that were exposed (secrets are things like passwords and keys). If needed, we go back to the last release that we know worked well (a rollback).
• ·3 · Remove and recover: we fix the root cause. Where we are unsure the data is correct, we restore it from a backup taken at a chosen point in time. We test the fix in a staging area (a safe copy of the system) before using it on the live site.
• ·4 · Tell the right people: we check what we must tell the authorities and our users (see the GDPR section below).
• ·5 · Review: we hold a review that does not blame individuals. It produces dated findings and actions to stop the same thing happening again.

Scanning for weak spots in our software and platform

• ·The building blocks our app uses (in Python and JavaScript) are scanned automatically for known security problems (called CVEs). We do this every time we build the app and again every week.
• ·The PostgreSQL, Redis and Celery images (the packaged software that stores our data and runs background jobs) are scanned every week as well. If a Critical problem is found, we do an extra fix straight away instead of waiting.

Penetration testing

A penetration test is when an expert tries to break into a system, with permission, to find weak spots. Djembely commits to an independent penetration test at least once a year. We will also run one before any major change to how people sign in, how payments work, or the admin console. Anything the testers find goes through the same intake and triage process described above.

GDPR breach-notification process (internal)

GDPR is a data protection law. A personal-data breach is when people's personal information is lost, stolen or seen by someone who should not see it.

The Privacy Policy explains the rights users have. This section is different. It is our own inside process for meeting the 72-hour rule:

• ·When we confirm a personal-data breach, the incident commander writes down the time we became aware. This starts the 72-hour clock.
• ·The data protection lead then checks how much risk there is to people. If the breach is likely to put people's rights and freedoms at risk, we tell the relevant supervisory authority (the official body that oversees data protection, which is the ICO in the UK). We do this within 72 hours of becoming aware.
• ·If the risk is high, we tell the affected users without undue delay (as soon as we reasonably can). We use plain language. We explain what could happen to them and what we have done about it.
• ·We record every breach, whether or not we have to report it. The record includes the facts, the effects and the action we took. This keeps our records complete for audit (an official check).

Recent updates

Learner sessions are signed out automatically after 15 minutes of no activity. Super Admin access is limited to one administrator account.