Vulnerability Disclosure

This policy explains how to report a security problem in Shog Corporate Training, what we will and will not treat as in scope, and what we promise in return. It is for security researchers, for customers who spot something while using the product, and for anyone who has found a weakness and is deciding what to do with it.

How to report

Email training@shogconsulting.com with "Security" in the subject line.

Please include:

• what the issue is, in one or two sentences;
• the URL, endpoint or screen where it appears;
• clear steps to reproduce it, with any request or payload needed;
• what an attacker could do with it;
• any screenshots, a short video, or logs that help;
• how you would like to be credited, if at all.

Write in English or Arabic. Report privately and give us a chance to fix the issue before you publish anything.

We do not currently operate an encrypted reporting channel. If you need to send something sensitive, say so in your first email and we will agree a method with you.

In scope

The service at training.shogconsulting.com and its supporting APIs, including:

• authentication and session handling for administrator accounts, including TOTP and Google or Microsoft sign-in;
• the learner magic link and one-time code flow;
• anything that lets one organisation reach another organisation's data, files or workspace;
• privilege escalation inside a workspace, including auditor preview access;
• any route to a completion or certificate record that does not involve doing the course, and any way to tamper with progress, scores or issued certificates;
• the public certificate verification endpoint, including anything that exposes more than the certificate number, course title, organisation name, issue date, expiry date and status;
• the storage connection handshake for SharePoint, OneDrive and Google Drive, and anything that leads to a token, scope or folder that should not be reachable;
• exposure of learner personal data, and especially identity photographs and signed declarations;
• server-side request forgery, injection, remote code execution, insecure direct object references, and stored or reflected cross-site scripting;
• exposed secrets, keys or credentials belonging to us.

Reports about a real weakness that does not fit the list are still welcome. Send them.

Out of scope

Please do not report these, and please do not test them:

• denial of service, load testing, or any volumetric attack;
• automated scanner output sent without a working proof of concept, and best-practice findings with no demonstrated impact, such as a missing header, a cookie flag with no exploit path, or a TLS configuration preference;
• issues in a third-party service we depend on, including Oracle Cloud Infrastructure, Stripe, Microsoft and Google. Report those to that provider, and tell us if it affects our customers;
• social engineering, phishing or physical attacks against our staff, our customers, their learners, or their offices;
• anything requiring a compromised device, a malicious browser extension, a rooted phone or a person already signed in on a shared machine;
• self cross-site scripting, clickjacking with no sensitive action behind it, missing rate limits with no demonstrated impact, and content spoofing without an injection;
• user enumeration through timing alone, and email deliverability findings such as SPF, DKIM or DMARC configuration, unless you can show a working spoof;
• the deliberate design decisions we have published. The public verification page shows a certificate number, course title, organisation name, issue date, expiry date and status with no account, by design. The storage connector refuses to disconnect while evidence files exist, by design. Tell us if you disagree with a decision, but it is a product discussion rather than a vulnerability;
• vulnerabilities in a customer's own Microsoft or Google tenant, which is theirs.

Rules of testing

Test against your own account and your own data. If you need an account to test with, ask us and we will discuss it.

Do not:

• access, modify, download or retain personal data belonging to anyone else. If you encounter someone's data, stop, do not save it, and tell us what you saw and how you reached it;
• enumerate certificate numbers or run bulk automated queries against the verification endpoint;
• degrade, disrupt or interrupt the service for other users;
• run destructive tests, delete or alter data that is not yours, or leave persistent artefacts behind. If your test creates anything, tell us so we can clean it up;
• pivot further once you have proved an issue. Proof of concept is enough. Do not use access you have gained to reach more;
• use a finding to obtain a certificate, to alter a training record, or to gain any advantage;
• publish anything about the issue before we have agreed timing with you.

Safe harbour

If you follow this policy, act in good faith and stop at proof of concept, we will treat your work as authorised research. We will not pursue legal action against you for it, we will not report you to law enforcement over it, and if a third party brings a claim about research that stayed within this policy, we will make it known that your activity was authorised by us.

This protection covers you, not the accounts or systems of others. It does not extend to accessing, keeping or disclosing another person's data, to disrupting the service, to extortion, or to anything outside this policy. We cannot waive the rights of a third party, including a customer whose tenant you test without their permission, so do not test a customer's tenant.

If you are unsure whether something is permitted, ask first at training@shogconsulting.com. Asking has never cost a researcher anything with us.

What we will do, and when

These are working days in the United Arab Emirates. If you have not heard from us within the acknowledgement window, resend your email, because delivery failures happen.

Where a fix affects customers, we notify affected customers ourselves through the account contacts, and where personal data is involved we follow the breach process in our Data Processing Agreement.

Disclosure

We prefer coordinated disclosure. Tell us before you publish, and we will agree timing with you. We will normally be comfortable with publication once a fix is deployed and customers who need to act have been told.

We are happy to credit you by name or handle in our record of the report, and to say so publicly where we publish anything about the issue. Tell us how you want to be named, or say if you prefer to stay anonymous.

No payment

We do not operate a bug bounty and we do not pay for vulnerability reports. There is no reward, no swag and no payment for a finding, however severe, and reporting one does not create an expectation of payment.

We say this up front so that no researcher spends time on the expectation of a reward. What we offer is a straight answer, a fix, credit if you want it, and the safe harbour above. If that is not what you are looking for, we would rather you knew now.

A report that arrives with a demand for payment, a deadline, or a threat to disclose or to sell the finding is not a good-faith report, and is not covered by the safe harbour.

Contact

training@shogconsulting.com

Shog Corporate Training is operated by Shog Consulting (FZC), licence SC242038101, STRIP Block C VL07-017, Sharjah, United Arab Emirates.