Product security at Ibexa
At Ibexa, we do not make spacecraft, we write digital experience software. A bug in one of our products is not likely to end in loss of life or limb. However, the 21st century has taught us all that information security matters and cannot be taken lightly. It's not something you can do in between other tasks, or as an afterthought. It must be a central concern in any information technology business - and what businesses do not deal with information technology these days? With enterprise customers in sectors like commerce, finance, retail and defense, we know the requirement for security as well as anybody.
Security runs through the company
Across Ibexa we work hard to maintain high standards of security in our products. The Support team receives issue reported from partners/customers, and works with them on identifying the cause. The Customer Success team interacts with customers to identify pain points, and promotes the customer’s high level interests internally in the organization. Engineering fixes the issues that are found, and is responsible for best practices to minimize the risk of issues existing in the first place. The Quality Assurance team verifies that fixed issues are well and truly fixed, and through thorough testing is central in discovery of new issues. Maintenance distributes fixes, informs about severity and possible consequences, and recommends actions to take to resolve issues. Security develops best practices with Engineering, researches new ways of detecting issues, and shares information internally and externally about secure development and usage practices.
The best security issues are the nonexistent ones. Ibexa DXP is based on leading tools like Symfony, which has its own rigorous security routines. Where it has "invented the wheel" security wise, we don't need to reinvent it. We also benefit from the proven security of the LAMP stack, including Linux/Unix, Apache/Nginx, MySQL/MariaDB, and PHP. Our development best practice includes a rigorous, mandatory peer review within the Engineering team. Wherever possible, the review process is fully open, so we also benefit from reviews by peers in our large and diverse community and partner ecosystem. Additionally, we make extensive use of automated testing, to catch issues before they are committed to our code base as well as testing by our Quality Assurance team.
Issue discovery can have various sources. It can be internal, by our own teams. It can come from partners, both upstream and downstream (for instance, we are included in Symfony's security process, meaning that it shares information with us enabling us to release fixes at the same time as it does).
We also encourage the community, researchers and other interested parties to share their discoveries with us in a responsible manner, see https://doc.ezplatform.com/en/latest/guide/reporting_issues/
NB: We value the work and consideration that goes into security research and reporting, and we will not punish it with lawsuits or otherwise. We believe fixed vulnerabilities in public code should be public knowledge, so we do not ask reporters to sign non-disclosure agreements. We ask only that vulnerabilities are reported through our secure channels, and that we are given reasonable time to resolve the issue before disclosure. See https://doc.ezplatform.com/en/latest/guide/reporting_issues/
Our process for resolving issues goes like this:
- When the issue was discovered by an external party, we keep the reporter informed during the development and testing phases, and we let the reporter review it before disclosure.
- We collaborate with upstream/downstream projects when relevant e.g. with Symfony.
- Security issues have top priority within Engineering, unless they are deemed very low risk/severity.
- Knowledge about the issue is kept internally (except when keeping external reporters informed) until the fix is available.
- Once approved, we apply the fix to all maintained versions of our commercial products and distribute this privately to customers.
- After some weeks, once we are sure customers have had time to patch their setups, we publish a security advisory and release the security fix to Open Source version of our software if applicable.
Ibexa DXP distributes new releases via Composer. When issues are urgent, as security issues very often are, they are distributed as enterprise micro releases outside of our regular release cycle. Subscribing enterprise customers are notified about security fixes first, via the Service Portal and email notification (also in some cases by reaching out more directly), giving them time to apply the micro release to their sites before the issue becomes fully public.
Public disclosure follows, via these channels: ezplatform.com, FriendsOfPHP / security-advisories, and GitHub. In some cases, enterprise customers and community users will be notified at the same time. This happens if the issue is already publicly known (“zero-day issue”) or if the distribution channel is public in nature (certain git repositories).
When the reporter is an external party, we will credit them in the release notes, if they so wish. We avoid security releases during or just before weekends and major holidays, to maximize the opportunity for site administrators to quickly patch/ update their sites. Zero-day issues may be released at any time.