A standing team, and a published process

The problem that structure solves

Open-source software has a particular exposure that proprietary software does not: the code is visible. Any researcher, any attacker, and any curious student can read it. That is mostly an advantage — review is wider, and the absence of security-through-obscurity forces rigour — but it also means that a vulnerability disclosed carelessly, or handled by whoever happened to be awake that night, becomes dangerous almost immediately. A project that receives a security report and has no agreed procedure is a project that improvises under pressure, and improvisation is where things go wrong.

Joomla's answer to this was the Security Strike Team, a standing body with a defined mandate and a published disclosure process. The word "strike" is borrowed from incident-response language — a small, bounded group empowered to move without waiting for broader consensus. The structure matters as much as the people in it, because it means that a researcher who finds a flaw in Joomla today knows, before they file anything, what will happen to their report. That predictability is not cosmetic; it is what makes responsible disclosure viable.

What the process looks like on the record

The published process follows a coordinated disclosure model. A researcher submits a private report — historically through a dedicated email address, later through a web form — and the Strike Team acknowledges receipt. The team then verifies the issue, assesses its severity, and works on a patch. The researcher is kept informed, and the public disclosure is timed to coincide with the release of the fix. At publication, a CVE identifier is assigned or requested, giving the vulnerability a permanent, cross-referenced record in the Common Vulnerabilities and Exposures database ↗.

This is coordinated disclosure rather than full immediate disclosure, and the choice reflects a practical calculation. Immediate disclosure protects the research community's right to know but leaves deployed installations exposed while administrators scramble to patch. Coordinated disclosure gives time for the fix — but only if the team actually moves. The Joomla process commits to a response window, which is what turns the model from aspiration into obligation. Projects that adopt coordinated disclosure informally, without a timeline anyone is bound to, tend to let reports sit.

The Strike Team is formally separate from the main development leadership, which gives it a useful operational independence: it can act on a security matter without routing every decision through the project's broader governance structures. Open Source Matters, the nonprofit that holds Joomla's assets and trademark, provides the organisational shell, but the Strike Team's day-to-day work is its own.

Severity, CVEs, and what public disclosure reveals

Severity scoring uses CVSS — the Common Vulnerability Scoring System — which assigns a numerical rating based on factors including how the vulnerability is accessed, whether authentication is required, and what an attacker can do once inside. Joomla's advisories publish the CVSS score alongside the CVE identifier, which lets a site owner, a hosting company, or a downstream packager make an informed decision about urgency without needing to understand the underlying code. That transparency is itself a governance choice: the project is telling its users enough to act rather than asking them to trust that the fix was necessary.

The National Vulnerability Database ↗, maintained by the National Institute of Standards and Technology, catalogs Joomla CVEs alongside those of every other tracked project, which means Joomla's security record is publicly auditable in a way that proprietary CMS vendors' records are not. A researcher or a procurement officer can compare the volume of disclosed vulnerabilities, their severity distribution, and the lag between discovery and patch. That comparison is imperfect — a project that discloses more may simply have better processes, not worse code — but the data exists, and the project cannot hide it.

The 2015 SQL injection vulnerability, which is covered in detail elsewhere on this site, illustrated both the strength and the limits of the model. The patch was produced and the CVE was filed correctly. What the process could not control was the size of the installed base that never applied it — abandoned installs, unmaintained instances, sites whose owners did not know Joomla was the software running them. A good disclosure process reaches administrators who are paying attention. It does not reach installations that have no administrator.

Joomla's answer to this was the Security Strike Team, a standing body with a defined mandate and a published disclosure process.

What the structure binds the project to

The existence of a documented process creates accountability in both directions. A researcher who follows the responsible disclosure path is owed a response within the stated window, a credit if they want one, and a fair hearing if they dispute the severity assessment. The project, in turn, gets the chance to fix the problem before it is weaponised — which is why projects without a credible process sometimes find that researchers skip private disclosure entirely and go straight to publication. Credibility is not just a reputational good; it is an operational one.

For the extension ecosystem, the Strike Team's remit has historically been limited to Joomla core. Extensions — the third-party plugins, modules, and components that expand the CMS — have their own vulnerability histories and their own, less uniform disclosure practices. The Joomla Extensions Directory has listing policies, and extensions with known unpatched vulnerabilities can be removed, but the JED is not a security authority in the way the Strike Team is. This gap matters because many real-world attacks on Joomla installations have gone through extensions rather than core, targeting code that was never under the Strike Team's jurisdiction.

Andrew Eddie, one of the developers who left Mambo in 2005 and a name on the original Joomla announcement, was among those who shaped the early governance structures, including the norms around security handling. Brian Teeman's documented public work included conference talks that addressed security expectations openly — explaining to a wide audience what the project would and would not do, which is itself a form of accountability.

The Joomla Security Strike Team is not a remarkable institution by the standards of large open-source projects. Apache has one; Mozilla has one; the Linux kernel has an equivalent process. What makes it worth studying in the Joomla context is the scale it operates at: a project with a market presence measured in millions of active installations worldwide ↗, governed by volunteers, maintaining a security process that meets the basic expectations of professional disclosure. The structure did not arrive automatically. It was built, documented, and kept running — and that is the part the governance record shows.