Introduction
To be listed on the Ledger Live “My Ledger“ section, Embedded Apps and Plugins must go through our integration process that includes a security audit performed by one of our trusted partners.
Provided your project fulfills the conditions, this is how an external audit unfolds:
- You get in touch with the auditers and sign a contract with them. Read more.
- The auditors review your app based on Ledger specifications. Read more.
- Ledger reviews the security audit report
- Ledger publishes your app
Conditions
To go through an external security audit, ensure your project fulfills the following conditions:
- Your coin is in the top 600 on Coin Market Cap (Except for plugins. Click here to know what is a plugin.)
- Your Embedded App has been released under developer mode
- Your Embedded App works with all our devices (Ledger Nano S, S Plus, X and Stax)
Important
- Do not start a security audit process if your Embedded App is not ready for all Ledger devices (Ledger Nano S, S Plus, X and Stax).
- Your Embedded App must still be functional after the security audit
Your agreement with our partners
If your embedded app is ready to go through the security audit, you can contact one of our partners:
They both follow Ledger specifications and will provide a full report with potential vulnerabilites.
Important aspects of your agreement:
- Time: When the auditors will be able to start the review.
- Cost: The external audit will be entirely at your expense.
- Maintenance: You must include a clause for updates or sign a new contract for any major update. If you don’t, your app will not be updated by Ledger and will be reverted to developer mode if it is breaking.
Note
Ledger is not a stakeholder in the contract between you and our partners.
Content of the security audit
Ledger has established and made public a detailed specification of what needs to be done to perform a security audit following Ledger’s standards.
Step |
Specification |
Application privileges |
- Check application flags (privileges) and allowed derivation paths.
|
Compilation |
- Check for compilation warnings, and if warnings have been silenced. If so, ask for a fix.
|
Tests |
- Run tests and check they succeed.
- Check tests are sound
|
Static Analysis |
- Check for defects using scan-build and our scan options. Add in CI if not present.
- CodeQL: check with the "security and quality" queries. Add in CI if not present.
|
Manual code review |
- List every transaction fields. Look which ones must be displayed to the user.
- Check transaction parser, field formatters.
- Check if sensitive data is properly erased.
- Do not allow blind signing.
|
Fuzzing |
- Implement a transaction fuzzer. Best effort to reach decent coverage.
- Use libFuzzer if possible to integrate with ClusterFuzzLite.
|
Deliverables |
- Report and executive summary detailing findings, and tests that gave no results.
- Security fixes: on a temporary private fork.
- Feedback on the SDK: what could be improved for a better security.
|