The Release Spectrum
WebPulse tracks GitHub release counts for 22 web frameworks. The data reveals a sharp divide. Eight frameworks — Next.js, Angular, FastAPI, Laravel, Remix, SvelteKit, Joomla, and Astro — each published 50 or more GitHub releases in the past year. Three frameworks — WordPress, Django, and Drupal — published zero.
Zero does not mean these frameworks stopped shipping code. WordPress, Django, and Drupal all have active codebases. But they distribute releases through channels outside GitHub's release system — proprietary update mechanisms, mailing lists, or documentation pages. The consequence is that automated dependency management tools, security scanners, and CI/CD pipelines that rely on GitHub's release API receive no signal from these frameworks.
Why Release Transparency Matters for Security
Modern software supply chains depend on machine-readable release metadata. When Next.js publishes a release on GitHub, every Dependabot instance, every Renovate bot, every Snyk scanner on the planet can detect it within minutes and generate a pull request to update the dependency. This is not a convenience feature — it is the primary mechanism by which most organizations learn that a security patch exists.
When WordPress pushes an update through its proprietary auto-update system, that update reaches self-hosted WordPress installations — if auto-update is enabled, if the server can reach wordpress.org, if no plugin conflicts prevent the update. There is no GitHub release for dependency tools to detect. There is no standardized changelog for security teams to parse. The patch exists, but the signal is trapped in a closed ecosystem.
The 50-Release Club
The eight frameworks that ship 50 or more releases per year share characteristics beyond volume. They use semantic versioning. They publish changelogs. They tag releases with security-relevant metadata. Their release history is queryable through a standard API. For a security operations team, this transparency translates directly into reduced time-to-patch.
FastAPI ships 50 releases per year against 40 CVEs. Laravel ships 50 releases against 224 CVEs. Next.js ships 50 releases against 92 CVEs. In each case, the release cadence outpaces the vulnerability discovery rate by an order of magnitude. Patches ship faster than new vulnerabilities emerge. This is the security posture that release transparency enables.
Django: The Outlier That Proves the Rule
Django publishes zero GitHub releases but maintains a rigorous security disclosure process, a dedicated security team, and detailed release notes on its own infrastructure. Django's 294 CVEs are actively managed through a process that, while not GitHub-native, is transparent and well-documented. Django scores 76 on the WebPulse index — among the highest for frameworks in its generation.
Django demonstrates that release transparency can exist outside GitHub. But Django is the exception. WordPress and Drupal — the other two zero-release frameworks — carry 18,335 and 1,376 CVEs respectively, and their update mechanisms are neither as transparent nor as reliable as Django's. For enterprise security teams, the absence of GitHub releases is a warning signal. It is not proof of negligence, but it demands investigation into what alternative transparency mechanisms exist — and whether they are sufficient.
The Question for Every CISO
If your organization's web infrastructure runs on a framework that publishes zero GitHub releases, ask one question: how does your security team learn about patches? If the answer involves manual checks, newsletter subscriptions, or vendor announcements, your patch velocity is limited by human attention. The frameworks shipping 50 releases per year have solved this problem at the tooling level. The frameworks shipping zero have not.
