Security Development Documention
Leshan contributors but mainly committers are encouraged to learn basic about design secure software. They should at least read that basic principals :
- economy of mechanism (keep the design as simple and small as practical, e.g., by adopting sweeping simplifications)
- fail-safe defaults (access decisions should deny by default, and projects' installation should be secure by default)
- complete mediation (every access that might be limited must be checked for authority and be non-bypassable)
- open design (security mechanisms should not depend on attacker ignorance of its design, but instead on more easily protected and changed information like keys and passwords)
- separation of privilege (ideally, access to important objects should depend on more than one condition, so that defeating one protection system won't enable complete access. E.G., multi-factor authentication, such as requiring both a password and a hardware token, is stronger than single-factor authentication)
- least privilege (processes should operate with the least privilege necessary)
- least common mechanism (the design should minimize the mechanisms common to more than one user and depended on by all users, e.g., directories for temporary files)
- psychological acceptability (the human interface must be designed for ease of use - designing for "least astonishment" can help)
- limited attack surface (the attack surface - the set of the different points where an attacker can try to enter or extract data - should be limited)
- input validation with allowlists (inputs should typically be checked to determine if they are valid before they are accepted; this validation should use allowlists (which only accept known-good values), not denylists (which attempt to list known-bad values)).
Ideally committer should follow the Secure Software Development Fundamentals course which is a free set of three courses that explain how to develop more secure software.
The sandbox run over Debian stable and unattended-upgrades is used to keep the OS up to date allowing reboot if needed at 2:00.
We also have Jenkins jobs which check for dependency vulnerabilities 🕵️ .
For Security concerning Leshan Library, see our Security Policy 📜 .
Eclipse foundation provides upguard tooling to enforce sandbox security. (login at https://cyber-risk.upguard.com/)
The sandbox does not handle any sensitive data or doesn't have any specific right or privilege to access to eclipse foundation resource.
Here some tools used to check configuration of Leshan sandbox hosted at https://leshan.eclipseprojects.io to try to follow security standard.
| Tools | Score | Links | Comments |
|---|---|---|---|
| Mozilla Observatory | ✔️ A+ (07 Jan 2025 ) Score : 120/100 
|
https://observatory.mozilla.org/analyze/leshan.eclipseprojects.io | |
| SSL Labs | ✔️ A+ (07 Jan 2025) | https://www.ssllabs.com/ssltest/analyze?d=leshan.eclipseprojects.io | |
| Security Headers | ✔️ A+ (07 Jan 2025) | https://securityheaders.com/?q=https%3A%2F%2Fleshan.eclipseprojects.io%2F | There is a shields.io badge for it but there is currently an issue with it securityheaders-bugs#110. |
| Immuniweb SSL Tests | ✔️ A+ (07 Jan 2025) | https://www.immuniweb.com/ssl/leshan.eclipseprojects.io/EnXfNTsb/ | |
| Immuniweb Website Tests | ✔️ A (07 Jan 2025) | https://www.immuniweb.com/websec/leshan.eclipseprojects.io/dJuBr5PI/ |
This can also be used : https://www.hardenize.com/report/leshan.eclipseprojects.io
We should also use same kind of tools for enhance SSH Security. (We don't know if there is good safe one)
Here is a list of possible improvements :
| Criticity | Improvement | Component | Comments |
|---|---|---|---|
| Use DNS CAA | DNS configuration | Up to eclipse foundation to fix it | |
| Activate OCSP STAPLING | Sandbox Apache Config | If possible we should activate it | |
| ℹ️ | CSP remove 'unsafe-inline' | Leshan Servers Demo | See : https://github.com/eclipse-leshan/leshan/issues/1682 |
| ℹ️ | Server does not have cipher preference | Sandbox Apache Config | Current SSL config is generated from moz://a SSL Configuration Generator:intermediate and SSLHonorCipherOrder is off, so we don't know if we should follow that advice and set it to on? |
| ℹ️ | HSTS Preload | Sanbox Apache Config | We should probably activate it. |
| ℹ️ | X-XSS-Protection | Sandbox Apache Config | This is deprecated should we remove it ? |
| ℹ️ | No Web application firewall | Sandbox Apache Config | We don't know if we need to configure that kind of tool ? Overkill for our usecase ? |
| ℹ️ | Privacy Policy (GPDR) | ? | We don't know really how to fix, is there a standard way to expose this kind of policy ? |
| ℹ️ | TLS 1.3 EARLY DATA (0-RTT) | Sandbox | We need to investigate. |
| ℹ️ | Extended Validation (EV) certificate | Sandbox | We think we don't need that... |
