Security

Covers the Geduk LMS, Geduk AI Scorm, the geduk.fr website and their hosting infrastructure. Last updated: October 2026.

Security lead

Vincent Lemaitre, founder and managing director of CVBSP Conseil et solution, is the person accountable for information security at Geduk. He is responsible for the security of the platform's code, of the servers that host it, of backups, and for handling vulnerability reports. Geduk is designed, built and operated by a deliberately small team: the person who writes the code is also the one who administers the servers and receives the reports, with no intermediary.

Security contact

vlemaitre@cvbsp.fr

security.txt

geduk.fr/.well-known/security.txt (RFC 9116)

Reporting a vulnerability

If you believe you have found a security flaw in one of our products or on one of our servers, write to the address above. Describe what you observed, the steps to reproduce it and, if possible, the impact you estimate. We do not run a bug-bounty programme, but we commit to:

• acknowledge your report within two working days;
• keep you informed of how the report is qualified and when the fix is scheduled;
• take no legal action against anyone who acted in good faith, did not degrade the service or access data beyond what was needed to demonstrate the flaw, and gave us a reasonable time to fix it before any publication;
• credit you, if you wish, when the fix is published.

Scope

• the Geduk learning platform: app.geduk.fr and the dedicated instances operated by CVBSP;
• the Geduk AI Scorm tool: ai-scorm.geduk.fr;
• the geduk.fr website and its free tools;
• the servers hosting these services.

Out of scope: denial-of-service testing, mass emailing, social engineering aimed at our customers or their learners, and any testing of a dedicated instance hosted by a customer on its own servers without that customer's consent.

How we protect the platform

Hosting

Servers are located in France, at OVH. Each dedicated-instance customer has its own database and its own file storage. Backups are daily, and a copy is kept away from the originating server, at a second French hosting provider. The availability of production platforms and the validity of their certificates are checked automatically every minute, with an alert on any anomaly.

Access and authentication

All traffic goes over HTTPS. Passwords are stored hashed. Two-factor authentication is available and can be made mandatory for a whole platform. Permissions are managed through roles and privileges, and a user can never grant a privilege they do not hold themselves. Administrative access to the servers is by SSH key only.

Development

Every new API endpoint goes through an authorisation and tenant-isolation checklist before it is released. Changes are tested on staging platforms separate from production, then deployed on a schedule. Dependencies are updated regularly and secrets are never committed with the code.

Penetration testing

CVBSP has an internal penetration-testing function, separate from day-to-day development and headed by Vincent Lemaitre, its only authorised member. It tests the server code, the staging platforms (*.dev.cvbsp.fr) and CVBSP's servers, grey-box, with AI-assisted static and dynamic analysis tools. Never on customer data.

Each campaign produces a report: numbered findings, severity, proof of concept, fix and validation of the fix before deployment. Unresolved findings are tracked in a register until closure. The latest campaign covered the LMS API server in September 2026: sixteen findings, the most severe of which were fixed and validated within days. A redacted report can be provided on request to a customer or an auditor.

Rules of engagement

• Every campaign starts with a written engagement brief: targets (host names, IP addresses, repositories), method, exclusions and date window. It is approved by the security lead, who is also the owner of the systems under test, before any testing starts.
• Active testing is limited to the *.dev.cvbsp.fr staging platforms, which hold fictitious data only. On production servers, only read-only configuration review is allowed; no customer data is touched.
• Findings are recorded the same day in the vulnerability register, with severity and remediation path, and reported to the system owner within five working days.
• A fix is deployed only after validation on the staging platform; the brief is closed when every high and critical finding is fixed or accepted in writing.
• Testing that involves customers hosting their own instance is carried out only with their written consent.

Personal data

What the website collects is described on the Personal data and cookies page. Learner data hosted on the platform is governed by the contracts signed with customer organisations and does not leave France.