Article

From back office to boardroom: packaging's new cadence

Editorial title card on a dark navy background reading "From back office to boardroom — packaging's new cadence" in white-and-green serif, with a faint clock motif at right and the stat "29 to 169 Chrome stable releases, 2018–2025"; branded Application Readiness Perspectives

In 2018, Google Chrome shipped 29 stable Windows releases. In 2025 it shipped 169. Mozilla Firefox went from 127 to 193. Citrix Workspace doubled. Across the enterprise applications most IT teams deploy, the pattern repeats: more releases, faster, driven by security disclosures rather than by features. Application packaging, the quiet back-office discipline that kept the lights on for three decades, has become one of the fastest-moving operational risks on a CIO’s desk — and on the boardroom risk register.

Packaging has not always moved this fast. In the Windows NT era, packaging meant sysdiff: you ran a snapshot tool before installing an application by hand, ran it again afterwards, and diffed the registry and file system to produce a deployable script. Brittle, but it worked. Through the late 1990s, hand-authored scripted installers from Wise and InstallShield held the field. Then Windows Installer arrived, and for roughly twenty years the MSI defined what an enterprise package was: transactional, repairable, transformable via MST, and natively supported by Group Policy, SMS, and SCCM. PSADT wrappers and Intune Win32 are the current generation, but the MSI sits underneath most of them. The point is the trajectory. Every step in this arc, from sysdiff onward, asked the same question: how do we package this application? The new question, the one that has rewritten the discipline, is different. It is no longer how. It is how fast.

Packaging used to be a quarterly chore. It is now a daily exposure decision. The change is not, on its own, a workflow problem; it is a sizing problem. The architecture of the back-office era — quarterly release calendars, change windows scheduled for the third Tuesday, six-week regression cycles — was built around a yearly or quarterly cadence. The real cadence is now weekly. Sometimes daily. The architecture cannot stretch that far without breaking.

Every unpatched application is a measurable risk window. The CISA Known Exploited Vulnerabilities Catalog gave that window a shape boards can see. When CISA names an application and sets a federal patch deadline, a board can ask two questions in plain English: are we exposed, and when will we be patched. Both are packaging questions. Both have measurable answers. Neither is a question packaging teams used to be asked.

The cadence shift is not, fundamentally, a workflow story. It is a governance story. Packaging is the function that determines whether the answer to “are we patched yet” is days, weeks, or months. That answer now lands in front of audiences who never asked for it before.

The security signal

CVE volume has grown for fifteen consecutive years. In 2015, the National Vulnerability Database published 6,595 CVEs. In 2025 it published 49,972. The share rated critical or high has not softened with volume; it has risen alongside it. The CISA KEV Catalog, which lists vulnerabilities under active exploitation, grew from 311 entries at its November 2021 launch to nearly 1,500 by the end of 2025 — a fivefold expansion in under five years.

CVE volume per year (NVD) and cumulative CISA KEV entries, 2010-2025.

Each one of those vulnerabilities is a candidate for a packaging change. The volume itself dictates the cadence.

The operational signal

The volume signal lands on the desks of packaging teams as release cadence. Look at a representative enterprise portfolio. In 2018, Chrome shipped 29 stable Windows releases. In 2025 it shipped 169 — nearly six times as many. Mozilla Firefox went from 127 to 193. Citrix Workspace doubled. Notepad++ nearly doubled. Zoom climbed by more than half. Even Adobe Acrobat DC, whose published release notes only stretch back to 2020, shipped 24 distinct versions in 2025. A few applications consolidated rather than expanded — Node.js merged maintained LTS lines and posted fewer releases — but the centre of gravity moved in one direction.

Releases per year per application, 2018 vs 2025.

The test infrastructure, sign-off chains, vendor coordination, and licensing assumptions inside most enterprises were built for an annual cadence. Operating them at a monthly cadence requires a different organisational model.

Why this belongs in the boardroom

The external pressures have arrived in parallel. KEV deadlines carry contractual weight for federal contractors and, increasingly, audit weight for everyone else. Cyber insurers underwrite policies against demonstrable patch latency; renewal questionnaires now ask, in detail, how quickly an organisation can ship a tested package for a named application. Regulators in finance, healthcare, and critical infrastructure repeatedly name delayed patching in major breach post-mortems. Audit committees read them.

The internal consequence follows. The cadence at which an organisation ships a tested package is no longer an IT metric. It is a board metric. It belongs in the same dashboard as financial close timelines and incident response time-to-contain. Few organisations treat it that way today. The ones that do tend to be the ones that already had to explain a breach to a board.

What changes next

Application packaging spent thirty years being good at standing still. It delivered MSIs. It kept the estate consistent. It answered to the change advisory board on the third Tuesday of the month, and on no other day. That discipline did its job. The next thirty years ask packaging to do something different: to move at the speed of disclosure, to produce evidence of every change, and to make exposure windows legible to the people who carry the risk. That work no longer belongs in the back office. It is one of the operational levers a board now has when it asks how exposed we are, and for how long.


Data sources: CVE counts from the National Vulnerability Database (NVD) API 2.0, queried 19 May 2026 for publication years 2010-2025. KEV entries from the CISA Known Exploited Vulnerabilities Catalog feed, sampled 19 May 2026. Per-application release counts compiled from Chromiumdash (Chrome), nodejs.org/dist (Node.js), Mozilla product-details (Firefox), Adobe ETK release notes (Acrobat DC), 7-zip.org history (7-Zip), the Notepad++ GitHub releases API, and the Zoom and Citrix release notes archives.