UNCHORUNCHOR OS Security and Vulnerability Disclosure Policy
Version 2026-10-23. Effective 23 October 2026.
This policy explains how SyncPesa Technologies Limited protects UNCHOR OS, how to report a security problem, and what we promise people who report one in good faith. A machine-readable summary is published at https://unchor.co.ke/.well-known/security.txt.
1. How UNCHOR OS is protected
- Accounts: passwords stored only as scrypt hashes; 2-step sign-in with an authenticator app and recovery codes; alerts by email when an account is used from a new device, with a link to lock the account; sessions that end when the password changes; limits on repeated attempts.
- Isolation: every workspace's data is separated by row-level security enforced inside the database, and tests check that one workspace cannot read or change another's data.
- Gateways: every command to a gateway is signed, expires and can be used only once; installers and updates are signed with a release key kept offline; a gateway keeps the last network it was given when the cloud cannot be reached and refuses forged or stale commands.
- Changes: high-impact changes show a preview, need an approval, are recorded in a hash-chained audit log whose checkpoints are signed, and can be undone.
- Automation and AI: agents may use only the tools on their allowlist, within budgets, and their proposals wait for a person's approval. They cannot grant themselves permissions.
- Secrets: payment credentials and other secrets are encrypted at rest with a master key that can be rotated; secrets are never written to logs, exports or support bundles.
- Supply chain: dependencies are locked, each release publishes a software bill of materials (SBOM), and known vulnerabilities are tracked in a register and fixed by severity.
- Staff access: least privilege, named accounts, time-limited elevation with a reason, and an audit record of every use.
We follow the practices of the NIST Secure Software Development Framework and the OWASP Application Security Verification Standard as engineering references. We do not claim certification against them.
2. Reporting a vulnerability
Report it to the contact form at https://unchor.co.ke/contact (topic: Security report). Include what you found, how to reproduce it, and what an attacker could do with it. Do not include customers' personal data; a description of the data affected is enough. You may write in English, Kiswahili, French, Spanish or Portuguese.
| What we do | When |
|---|---|
| Acknowledge your report | within 3 business days |
| Tell you whether we can reproduce it and how serious we think it is | within 10 business days |
| Fix critical and high-severity issues, or put a documented mitigation in place | as fast as possible, with a target of 30 days |
| Tell you when it is fixed and, with your agreement, credit you publicly | when the fix is released |
3. Rules for testing
Testing your own workspace and your own gateway is welcome. Please:
- do not access, change or delete data that is not yours; stop and report as soon as you see someone else's data
- do not degrade the service for others (no denial-of-service or load testing against our cloud)
- do not test against other customers' sites, gateways or Wi-Fi networks
- do not use social engineering against our staff or customers, or physical attacks
- give us a reasonable time to fix an issue before you publish it; 90 days unless we agree otherwise
In scope: the cloud (API, owner app, sign-in pages, public website), the gateway agent, its installer and updates, and the release and command-signing scheme.
Out of scope: third-party providers (payment processors, email or SMS providers, hosting), reports from automated scanners without a demonstrated impact, and missing best-practice headers without a demonstrated impact.
4. Safe harbour
If you follow this policy in good faith, we will not take legal action against you for your research, we will not ask a law-enforcement agency to act against you, and if a third party takes action against you we will make it known that your research was authorised. This applies only to our own systems; it cannot authorise testing of systems that belong to others.
5. Rewards
We do not run a paid bug-bounty programme. We credit researchers who wish to be credited, and we may, at our discretion, thank people for exceptional reports.
6. Incidents
When an incident affects customers we tell them what happened, what was done and what they should do, in plain language. Where personal data is involved we follow the breach duties in the Privacy Notice and the Data Processing Terms.