Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

 

A better security classification for supported modules

At SilverStripe, we have a well defined security release process that helps keep SilverStripe projects secure. We’re taking the opportunity to align our process with the open source community, as well as re-defining how we handle security fixes in for “Limited Support” release lines. 

Read post

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.

 

About the author
Ingo Schommer

Ingo joined SilverStripe with its 2.0 release, and has since become an integral member of the development team. He's from Germany, but admits that New Zealand beer is often quite tasty as well.

At SilverStripe, Ingo enjoys coming up with robust solutions for real business needs. He builds modern web applications, making sure they work well in browsers and mobile devices, not just on paper. As a core developer on SilverStripe's open source framework, he facilitates community involvement, and helps architect and implement core functionality. Ingo authored the first book about SilverStripe, and is still keen on keeping the documentation fresh.

Ingo graduated as Bachelor of Arts (Hons) in Media Production and has several years experience as a freelance PHP and Flash developer.

Away from the keyboard, Ingo is an avid gardener, debugging water flow and performance optimizing root growth instead of PHP.

Post your comment

Comments

No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments

Like what you have read?

Sign up for our weekly blog digest sent to your inbox.

Subscribe