Classe365 makes it a priority to ensure that customers' systems cannot be compromised by exploiting vulnerabilities in Classe365 product suite.
This page describes when and how we release security bug fixes for our products. It does not describe the complete disclosure process that we follow.
Security bug fix Service Level Agreement (SLA)
We attempt to meet the following timeframes for fixing security issues.
Classe365 fix bugs on weekly basis and the fixes are released usually on Fridays two to four times per month. We refer to these releases as internal hotfix builds and they are incremental, meaning that the fixes in the latest internal build include all fixes from such previous builds. Our goal with these weekly hotfixes is to help customers and partners address important issues for specific use cases without having to wait for the next product update.
Critical severity bugs are fixed in product within 1 week of being reported.
High severity bugs should be fixed in product within 2 weeks of being reported.
Medium severity bugs should be fixed in product within 4 weeks of being reported.
When a Critical security vulnerability is discovered by Classe365 or reported by a third party, Classe365 will do all of the following:
Issue a new, fixed release for the current version of the public or private instance of the product as soon as possible.
With the weekly hotfix builds we attempt at fixing all reported issues on top of the latest product version and we highly recommend that customers regularly upgrade in order to benefit from the continuous improvements. As Classe365 platform product is offered as SAAS only, the latest versions are automatically updated to customer's cloud version
However, business conditions sometimes prevent customers from upgrading specifically our private cloud customers and mobile app users, and in such cases will attempt to prepare a patch on top of an older version. We can attempt to produce patches for up to one major version back from the current latest version (e.g. current major version 10.0, versions supported for patching are 9.0-10.0).
The produced patches are based on the latest internal hotfix build for your Classe365 version. They have passed our fully automated test suite - which includes thousands of functional, integration, unit and performance tests. The actual bug fixes for which the patch is produced have also passed strict manual quality assurance and performance tests. These builds have not passed our full manual regression testing cycle that we do before each official release. "Silent" builds (ones that have been produced with the same Classe365 Private Cloud build number as yours) are not supported -patches always come with an incremental build number so we can ensure proper maintenance of your project moving forward. The patch builds not include breaking API changes, database changes and high-regression potential changes or fixes, and upgrading to them should be seamless. Upgrade from these builds to the consecutive official release is fully supported.
Please note that due to code refactoring it’s not always possible to apply a patch to an older version. Nevertheless, we stand committed to meeting your business needs and if it is not possible to produce a patch we will advise you on the best path to address the issue.
Classe365 users JIRA, Bit Bucket and other Atlassian tools to ensure we adhire to stringiest version control and patch management techniques.
When a security issue of a High, Medium or Low severity is discovered, Classe365 will include a fix in the next scheduled bug fix release. The fix may also be backported to private cloud instances, if feasible.
Customers are recommended to upgrade their Classe365 mobile app or Private Cloud instance when a bug fix release becomes available to ensure that the latest security fixes have been applied.
Testing and Validation
Every security bug fix passes rigorous manual quality assurance and performance tests. Then, the internal hotfix build has to pass our fully automated test suite that includes thousands of functional, integration, unit and performance tests. However, these builds do not go through our full manual regression testing cycle that we do before each major product release.
Severity level of vulnerabilities is calculated based on Classe365 Severity Levels for Security Issues.
We will continuously evaluate our policies based on customer feedback and will provide any updates or changes on this page.