Security
We take security very seriously and adopt industry best practices to minimize the likelihood of introducing vulnerabilities in the Solidus codebase. For us, security also means having a clear policy in place for reporting and patching vulnerabilities.
Supported Versions
Solidus versions will receive security patches for 18 months (540 days) after their initial release.
The following table represents the latest versions with their release date, EOL date and current support state.
| Version Number | Release Date | End of Life Date | Supported |
|---|---|---|---|
| v4.3 | 2023-12-22 | 2025-06-14 | ✅ |
| v4.2 | 2023-09-29 | 2025-03-29 | ✅ |
| v4.1 | 2023-06-29 | 2024-12-29 | ✅ |
| v4.0 | 2023-05-08 | 2024-11-08 | ⛔️ |
| v3.4 | 2023-04-21 | 2024-10-21 | ⛔️ |
| v3.3 | 2023-01-24 | 2024-07-24 | ⛔️ |
| v3.2 | 2022-08-18 | 2024-02-18 | ⛔️ |
| v3.1 | 2021-09-10 | 2023-03-10 | ⛔️ |
| v3.0 | 2021-04-20 | 2022-10-20 | ⛔️ |
| v2.11 | 2020-10-23 | 2022-04-23 | ⛔️ |
| v2.10 | 2020-01-15 | 2021-07-15 | ⛔️ |
| v2.9 | 2019-07-16 | 2021-01-16 | ⛔️ |
| v2.8 | 2019-01-29 | 2020-07-29 | ⛔️ |
| v2.7 | 2018-09-14 | 2020-03-14 | ⛔️ |
| v2.6 | 2018-06-16 | 2019-12-16 | ⛔️ |
| v2.5 | 2018-03-27 | 2019-09-27 | ⛔️ |
| v2.4 | 2017-11-07 | 2019-05-07 | ⛔️ |
Reporting a vulnerability
We promise to be always responsive and thankful to those who report any security vulnerabilities following the instructions described here.
All security bugs in Solidus should be reported through our vulnerability disclosure program page at HackerOne. This will deliver a message to a subset of the Core Team who handle security issues. Your report will be acknowledged as soon as possible and we'll try to get in touch within 5 days.
We may ask you to access the Security Advisory created in GitHub to help us discover more about the report, fix it, and also to keep you informed on progress.
Alternatively, you’ll just receive a detailed response indicating the next steps in handling your report. After the first reply to your report, the security team will keep you informed of the progress being made towards a fix and full announcement. These updates will be sent at least every 5 days.
If you have not received a reply to your report within 5 days, or have not heard from the security team for the past 5 days, please, either:
- Contact the current security coordinators [email protected] .
- Contact any other Solidus Core Team member on Slack via direct message.
All response target times are tracked and reported in business days. Business days are defined to be:
- Monday - Friday
- 24 hours
- Including holidays (hackers never sleep!)
Disclosure process
1. Security Report Received
- Report is assigned a primary handler. This person will coordinate the fix and release process.
- Problem is confirmed and a list of all affected versions is determined.
- Code is audited to find any potential similar problems.
2. Vulnerability Fixed
- A new Security Advisory is created in GitHub to privately discuss and fix the vulnerability reported. This will also allow publishing a security alert to Solidus users directly on GitHub, only visible to repository users with admin permissions.
- Fixes are prepared for all releases which are still supported. These fixes are not committed to the public repository but rather held privately pending the announcement.
3. Vulnerability Published
These actions should be done within the same business day.
- The GitHub Security Advisory is published.
- A Solidus Security mailing list thread is created.
- Fixed gems versions are released to RubyGems.
- A blog post is published on solidus.io.
Receiving disclosures
The best way to receive all the security announcements is to enable alerts for vulnerable dependencies in GitHub or to subscribe to the Solidus Security mailing list. The mailing list is very low traffic, and it receives the public notifications the moment the vulnerability is published.
If you have any suggestions to improve this policy, please send an email to the security policy team.
Additional Security Initiatives
In addition to the Disclosure Program above we also enforce the security of the codebase and released gems through the following initiatives:
- Two mandatory PR reviews from the Core Team: Before merging any PR we need two mandatory reviews from members of the Core Team, which helps spot security issues.
- Multi-factor authentication enabled on RubyGems: All users who have permissions to release a core gem of Solidus need to have multi-factor authentication enabled on RubyGems to avoid gem hijacking.
- Automated GitHub Security Fixes: When one of the Solidus dependencies receives a security fix, GitHub automatically submits a Pull Request on our repository to require the library at the patched version.