A better security classification for supported modules

SilverStripe has published security releases for many years, with a well defined security release process. Each security issue we’ve identified was assigned an identifier, and a severity rating. Both of these were custom markers which we’ve applied based on our context. We’re adjusting this to be more in-line with large open source projects, which are depended on by thousands of organisations around the globe. We are also taking this opportunity to redefine how security fixes are handled in “Limited Support” release lines such as SilverStripe 3.x.

Supporting more tooling through CVE Identifiers

Our custom security issue identifiers followed a unique format (e.g. SS-2018-021). The Common Vulnerabilities and Exposures (CVE) project maintains a list of issues across many software projects, and provides a common identifier format (e.g. CVE-2019-5715). Starting now, we’re adopting this format to identify security issues in our supported modules.

We continue to maintain our own security releases list (with an RSS feed), and that’s where you’ll find the canonical description of those issues. By cross-publishing this to the CVE List, we enable other security tools to pick up the new information and expose it to a wider range of users and contexts. Note that CVEs are published with a manual review delay, so it’s still important to stay on top of SilverStripe release announcements (consider subscribing to our pre-announce mailing list).

More objective impact rating through CVSS

Security vulnerabilities are often complex beasts, and hard to break down to a single “impact” rating. Our previous severity rating of critical/high/medium/low split with plain English definitions has served us well over the years. However, it makes it hard for large organisations to determine the impact for their own business, particularly in situations where you’re using dozens or hundreds of software packages. We’ve found that the Common Vulnerability Scoring System (CVSS) can help you with a more objective impact assessment, and we’ll start to publish it with each security release going forward. By adopting CVSS scoring, we’re more confident in the impact rating of the security issues we identify. This also benefits you directly, as you can adjust the base CVSS in a CVSS calculator to fit your own context (e.g. accounting for a Web Application Firewall, or IP whitelists).

New process for security issues on “Limited Support” releases

SilverStripe supports it’s releases for many years, with clearly defined upgrade paths. Release lines have different support definitions: “Active Development”, “Full Support”, and “Limited Support”. SilverStripe 3.x has gone into “Limited Support” mid 2018 (see roadmap). In order to balance the effort required in maintaining multiple release lines, we are introducing a new process: Releases in “Limited Support” will continue to receive fixes for security issues which are marked “critical” (CVSS >=9.0), but for issues with a lower impact rating, those fixes are on a best effort basis. Note that minor release lines with End-Of-Life (EOL) status no longer receive security fixes.

Modules report for more visibility to CMS administrators

There’s a SilverStripe Maintenance module which provides more visibility of what’s installed and outdated through the CMS. It’s a great addition to your default CMS installation in order to give non-technical users more visibility (no more hunting down a composer.json file). The module also checks a PHP security advisory repository for known issues, and highlights those in the UI. This project also comes with a CLI tool which you can build into your Continuous Integration and deployment workflows, for example to block deployments with known security issues. We’re starting to report new security issues in this advisory repository going forward.