Mule Runtime Security Patching on CloudHub

Here is the latest security release path from MuleSoft.

Starting this month i.e. January, 2020, MuleSoft has implemented a new automated process that will update runtimes in CloudHub that applications are using to the latest service pack version (also known as a date patch) whenever a vulnerable library or component is discovered within the Mule Runtime, JVM or the underlying Operating System. Updates will be performed using a blue/green deployment and date patch versions contain only backward compatible bug fixes and security patches.

The new automation will ensure consistency and that vulnerabilities are always patched within mandated Salesforce security SLAs.

What is a date patch version?
If you deploy an application, it gets deployed to the latest date patch version of the Mule Runtime at the time of deployment. For example, the app below was deployed to 3.9.1 06-07-2019 version in June 2019.

Runtime Autoscaling.JPG

The release notes show several date patch updates to 3.9.1 between June and November, these patches contain backward compatible bug fixes and updated OS, libraries and security patches. However, in the past, the application would remain on this outdated version unless you manually take the latest update as seen in the screenshot above. Not updating the applications regularly leaves applications susceptible to bugs and vulnerabilities that have been discovered and fixed in the latest date patch version.

This January 2020, MuleSoft shall update all runtimes to the latest date patch version to ensure no application on the Mule Cloud Platform is running on vulnerable libraries or components. Going forward, Mule will automatically update the current application runtimes to the newest date patch version whenever a vulnerability is discovered. For example, if the update were to happen in November, an app running on 3.9.1 06-07-2019 version will get updated to the latest patch available for that version available in November: 3.9.1 11-06-2019.

What is a blue/green deployment?
Runtimes will be updated to the latest date patch version using a blue/green deployment.

MuleSoft first will bring up a new version of the application on the latest date patch version. CloudHub will wait for the Mule application to be responsive (see Application Monitoring) and a further 3 minutes before the application domain and related Static IPs (if used) are moved to the new version. Using this process, MuleSoft strives to achieve zero-downtime updates. If the new application is unresponsive after an update is applied, the existing version of the application will continue to run on the older date patch version.

What action do you need to take?
All updates will be automatically applied using a blue/green deployment and contain only backward compatible bug fixes and security patches.

If the apps restart without downtime, no action is required.

However, if that’s not the case and the production Mule application cannot be restarted with zero-downtime, you can open a support ticket with MuleSoft.

There are two known cases under which this may occur:

  1. The CloudHub application is a durable subscriber. In this case, there can only be one unique subscriber at a time. Such applications would require a stop and start to take the latest update.

  2. After the CloudHub application starts up, it will wait until a connection is established to an external dependency that is unavailable, unresponsive or requires warm-up. CloudHub will give the application up to 3 minutes to connect with any post-startup dependencies before the application domain and related Static IPs (if used) are moved to the new version of the application.

Frequency of Updates?
If MuleSoft identifies security vulnerabilities, they will patch your Applications automatically as per the following SLAs:

Severity LevelSeverity DefinitionSLA
P0Critical7 days
P1High30 days
P2Medium90 days
P3Low120 days

MuleSoft will not provide any advance notice for when a security update may occur but an entry by user “Anypoint Staff” will be created in the audit log which will indicate the date and time an update has occurred and whether it was successful.

Leave a Reply

Your email address will not be published. Required fields are marked *