Security

Product security at Ibexa

The 21st century has taught us all that information security matters, and cannot be taken lightly. It's not something you can do when you have spare time, or as an afterthought. It must be a central concern in any information technology business - and what businesses do not deal with information technology today? With enterprise customers in sectors like commerce, finance, retail and defense, we know the requirement for security as well as anybody.

Security and privacy

There is a strong connection between security and privacy. Sometimes they are at odds: If a service has no logs and no login, user privacy is good, but attacks and abuse are difficult to deal with. Other times they support each other: A secure login system maintains the privacy of its users from attack. Ibexa considers security a necessary requirement for privacy. Privacy by design (PbD) is a good set of general principles that Ibexa support. It is however vague, with few technical details, so it's hard to say whether any given product is compliant or not. The EU's GDPR goes into more detail where it incorporates PbD principles. Ibexa seeks to enable our customers and community to be GDPR and PbD compliant through product features and documentation, as the deciding factor for compliance is how our products are implemented and configured by them.

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.

Here's how we strive to make our products more secure:

Prevention

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.

Discovery

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.ibexa.co/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.ibexa.co/en/latest/guide/reporting_issues/

Resolution

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 disclose it publicly.

Disclosure

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 via the Service Portal and email notification (also in some cases by reaching out more directly). Public disclosure is done via these channels: developers.ibexa.co, and GitHub.

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.