Security and responsible disclosure

If you have found a security problem in GradeLens or on this website, we want to hear about it. This page tells you how to report it and what we will do.

What to include

• What the issue is and roughly how severe you think it is
• Steps to reproduce it, with enough detail that we can see it ourselves
• The affected app version, endpoint or page
• What an attacker could actually achieve with it
• How you would like to be credited, if you want to be

Our commitments to you

• We acknowledge your report within 5 business days.
• We give you an assessment and a rough remediation timeline within 10 business days.
• We keep you updated while we fix it, and tell you when it is done.
• We credit you publicly if you would like us to.
• We will not pursue legal action against you for research conducted in good faith under the rules below, and we will not report you to law enforcement for it.

We do not currently run a paid bug bounty. We are a young company and would rather promise a careful response than a payment we cannot guarantee.

Rules for good-faith research

Please:

• Use only your own test account and your own test data
• Stop as soon as you have confirmed a vulnerability exists
• Give us reasonable time to fix it before telling anyone else — 90 days is our default
• Report it to us privately first

Please do not:

• Access, modify or delete anyone else's data — and if you accidentally encounter another person's data, especially a child's, stop, do not save it, and tell us at once
• Run denial-of-service or load tests against our systems
• Use social engineering, phishing or physical attacks against our people or suppliers
• Publish details before we have fixed the issue
• Demand payment in exchange for withholding disclosure

In scope

• The GradeLens mobile app on iOS and Android
• The GradeLens API
• This website, ellermon.com

Out of scope

• Vulnerabilities in Amazon Web Services (AWS), Apple or Google infrastructure — report those to them
• Findings from automated scanners with no demonstrated impact
• Missing security headers or best-practice recommendations with no exploitable consequence
• Social engineering of our staff or users
• Denial of service through sheer volume
• Issues requiring a physically compromised, rooted or jailbroken device already under attacker control
• Reports about email configuration with no demonstrated exploitability

How we protect GradeLens

• Encryption in transit — TLS on every connection between the app and our API
• Encryption at rest — in the database and in backups
• Modern authentication — OAuth 2.0 authorisation code flow with PKCE, handled by Amazon Cognito. We never see your password.
• Secure token storage — access and refresh tokens live in iOS Keychain or Android Keystore, not in ordinary app storage
• Authorisation on every request — the gateway validates the token, and the service independently confirms the caller owns the data being requested
• Least privilege — access to production is limited and logged
• Dependency auditing — automated on every change, with published vulnerabilities patched promptly
• Regional isolation — data stays in AWS Africa (Cape Town)

If something goes wrong

If personal information is ever accessed without authorisation, section 22 of POPIA obliges us to notify the Information Regulator (South Africa) and every affected person as soon as reasonably possible. We will tell you what happened, what was involved, what we have done and what you should do. See our breach commitment.