Security updates and patching cadence #

This page is for security officers and contract managers in a public body. It explains how a vulnerability in Exponential is handled from report to fix, what the project promises and what it does not, and how to turn that into a patching obligation for a supplier. The sources are SECURITY.md, Security standards and SLA options for Exponential hosting.

Contents #

1. From report to fix
2. What the project promises
3. How you learn about a fix
4. Agreeing a patching time
5. Your own reporting channel

From report to fix #

1. Someone reports a vulnerability privately by e-mail to the address in SECURITY.md, not in the public tracker.
2. The reporter gets a first answer and is told whether the report is accepted.
3. An accepted issue is fixed on main.
4. The fix is published with the next 6.0.x release. Published tags are never changed.
5. Sites receive it by upgrading to that release (Planning upgrades in the budget).

What the project promises #

Not promised: a time to fix, advance notice to users, a security advisory feed. There is no security.txt file shipped (Security standards). The hosting SLA page advises: promise to apply a released fix within a time, not that a vulnerability will be fixed within a time; "the second depends on the project, the first on you" (SLA options).

How you learn about a fix #

• Watch the releases of the repository on GitHub, and the changelog of the current line (6.0.15 changelog).
• The administration dashboard has a panel "Stay secure: keep Exponential up to date" with links to the Git Manager and Composer updates.
• Setup > Updates and packages lists newer versions of the installed packages (Update with Git).
• Hosts: Security updates and disclosure and Working with the project and 7x.
• Press guidance on how fixes are announced: Covering security fixes.

Make one named role responsible for watching. Without an owner, nobody notices a release.

Agreeing a patching time #

Security updates
1. The Supplier monitors the releases of Exponential and of every extension used on the Site.
2. When a release fixes a security issue that affects the Site, the Supplier applies it to the
   production Site within <time> of the release, after a test on the staging copy.
3. If the release cannot be applied in time, the Supplier informs <role> within <time> and applies a
   documented mitigation (for example a web server rule, maintenance mode, or disabling the affected
   feature) until it can.
4. The Supplier records each security update in the <period> report: release, date applied, site checked.

Choose the times with your security officer, considering your risk and the supplier's capacity. A shorter promise than the supplier can staff is worthless; see the advice for partners in Support levels and response times.

Mitigations that exist in Exponential and are documented: maintenance mode (Maintenance mode), request rules and the request shield in front of the kernel, part of the default installation since 6.0.15, whose rules can refuse a vulnerable address at once (Security hardening).

Your own reporting channel #

Your public site should tell visitors where to report a security problem with it. Exponential ships no security.txt (RFC 9116, rfc-editor.org/rfc/rfc9116); an operator can add one. Route reports about the software itself to the project as SECURITY.md describes, without personal data.

Related pages #

• The product lifecycle
• Supported versions
• Security hardening
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.