Broadcom TrueSource Explained: What It Covers and Leaves Out

What was announced

On 31 August 2026 Broadcom announced TrueSource, described as a portfolio of commercially supported, verifiably built open source software for the enterprise. It is not a new product so much as an umbrella that gathers several existing and new offerings under one name and one licensing motion.

It has three parts.

• Spring Enterprise — the existing flagship offering for the Spring ecosystem, now positioned inside TrueSource.
• TrueSource Trusted Artifacts — new. Clean-room SLSA Build Level 3 builds of libraries across the Java ecosystem, Python and Node.js. It also absorbs the Bitnami Secure Images catalogue, adding hardened, verifiably built container images for hundreds of common open source packages.
• TrueSource Data Services — new. Trusted artifacts, support and deployment expertise for four data engines: PostgreSQL, RabbitMQ, MySQL and Valkey.

Broadcom's own framing for the launch leaned on a security statistic: that Spring security advisories surged more than 1,700%. That number is doing a lot of work in the announcement and is worth reading carefully — a surge in advisories is a measure of disclosure activity, which rises with scrutiny and with the maturity of a project's security process. It is not by itself a measure of how exposed you are.

What TrueSource says about end-of-life versions

Very little. Broadcom's release and the coverage in The Register, Techzine and IT Brief give no support window for any Spring, RabbitMQ, PostgreSQL, MySQL or Valkey line. The closest thing to a lifecycle promise is that Spring Enterprise customers get patches across every supported release line before a CVE is published.

The word that matters there is "supported". It points back to Broadcom's existing commercial calendar, and TrueSource did not change that calendar. As of 4 October 2026 the published dates are:

• Spring Boot 3.4.x: open source support ended 31 December 2025, and commercial support ends 31 December 2026.
• Spring Boot 3.0 to 3.3: commercial support has already ended. For 3.3 it ended on 30 June 2026.
• Spring Boot 2.7.x and 3.5.x: commercial support runs to 30 June 2029 and 30 June 2032.
• RabbitMQ 4.0: commercial support ended 30 September 2026. RabbitMQ 3.12 ended on 30 June 2025, and 4.1 ends on 30 April 2027.
• RabbitMQ 4.3: community support ends 31 January 2027.

The Spring dates come from the generations data on api.spring.io. The RabbitMQ dates come from the release information page on rabbitmq.com, which calls its commercial dates indicative and defers to the Broadcom support portal.

In practice, TrueSource does not bring a line back once its commercial date has passed. A team on RabbitMQ 4.0 or Spring Boot 3.3 that signs today is buying an upgrade path, not cover for the version it runs. For PostgreSQL, MySQL and Valkey, the announcement does not say which major versions Data Services covers or for how long, so put that question in writing.

Why this matters more than a typical vendor launch

Two things make TrueSource consequential rather than routine.

First, the supply-chain framing is real. SLSA Build Level 3 is a meaningful standard. It requires that builds run on hardened, managed infrastructure with provenance that is generated by the build service itself and cannot be falsified by the build's own scripts. Clean-room rebuilds of widely used libraries, with attestable provenance, address a genuine problem — one that xz (CVE-2024-3094) made concrete for everyone who had been treating supply-chain risk as hypothetical. This is not marketing dressed as security.

Second, the data-engine expansion changes the competitive picture. TrueSource Data Services covers PostgreSQL, RabbitMQ, MySQL and Valkey. That is Broadcom moving from the application framework layer, where it has been since the VMware acquisition, into the data infrastructure layer. Anyone comparing commercial support options for those four engines now has Broadcom in the evaluation who did not before.

What TrueSource does not answer

This is the part no announcement covers, and it is where most of the buying decision actually sits.

Price is not published

TrueSource is sold through tiered site licensing, and Broadcom has not published a price list. We are not going to put a number on it second-hand: figures circulating in third-party coverage are not sourced from Broadcom, and an unverified price is exactly the kind of claim this site no longer makes. Get a quote for your own estate and compare it against what you are spending today.

What is well established is the shape of Broadcom's post-acquisition licensing: larger bundles, longer terms, higher floors, and less willingness to sell a narrow slice. Organisations that wanted support for one component have consistently reported being quoted for a portfolio.

Coverage is artifact-shaped, not estate-shaped

Trusted Artifacts gives you verifiably built binaries. That is valuable and it is not the same as having your estate supported. A hardened image of RabbitMQ does not tell you whether your cluster's quorum queue configuration will survive an upgrade, why your consumers are timing out under load, or whether the Erlang/OTP release underneath the broker is still receiving patches. The artifact is the input to an operational problem, not a solution to it.

The version you are on may not be covered

Clean-room builds are produced for versions the vendor chooses to build. The estates with the sharpest need are typically several versions behind — that is precisely why they need support — and the question of whether TrueSource builds the specific release you are pinned to, for as long as you need it, is one to establish in writing before signing anything.

It is the vendor most of this market is leaving

This needs saying plainly, with the bias declared: we compete with Broadcom, so weigh this accordingly. The market context for TrueSource is that Broadcom's licensing changes since the VMware acquisition have driven a sustained migration away from its products. TrueSource is, in part, a response to that. For an organisation that moved off VMware licensing on cost grounds, a Broadcom-licensed replacement for its open source supply chain is a strategic question, not just a procurement one.

The Bitnami thread, which is the same story

Bitnami Secure Images is now part of Trusted Artifacts, and the path it took there is instructive about how this portfolio is likely to be operated.

Bitnami's free container catalogue on Docker Hub — the docker.io/bitnami namespace that a very large number of Helm charts and Dockerfiles referenced by default — began a staged shutdown on 28 August 2025, and its versioned tags were deleted on 29 September 2025. Older images were moved to a legacy archive that receives no further security updates. A limited free tier remains: community images published only at the latest tag, which is precisely what you cannot use in a reproducible production deployment.

The practical effect was that a large number of production manifests referencing Bitnami images either broke or silently pinned themselves to unmaintained archives. Teams discovered this during the brownouts. That is the operational reality behind the phrase "moved to a premium catalogue", and it is the most concrete data point available on how this portfolio treats the free tier it inherits.

If you are working through that specific problem, we wrote up the alternatives in what to run instead of Bitnami images.

How to evaluate it, if you are being sold it

Five questions that will produce a more useful conversation than a feature comparison:

1. Which exact versions do you build, and for how long? Get the specific release trains and the end dates in the contract, not the marketing page.
2. What is the smallest thing I can buy? If the answer is a site licence covering products you do not use, that is the real price of the thing you do use.
3. Does this include operational support, or artifacts only? Establish whether a P1 at 3am reaches an engineer who knows your topology, or a support queue that ships binaries.
4. What happens to the free tier I currently depend on? Bitnami is the precedent. Ask directly.
5. What is the exit? Clean-room builds are Broadcom-produced artifacts. Establish what you run if you stop paying, and whether your deployment manifests would need to change.

Where we fit, stated openly

We are not a neutral party — OSSeva sells extended support for several of the same technologies, so read this section as a positioning statement rather than analysis.

The overlap with TrueSource Data Services is real: RabbitMQ, PostgreSQL and the Redis and Valkey line are all in both catalogues. Where we differ is that we patch the version you are actually on rather than the version we chose to build, we cover the operational layer rather than shipping artifacts, and we publish what things cost. We also cover the layers Broadcom's data-engine list does not reach — the Erlang/OTP runtime beneath RabbitMQ, ActiveMQ, ZooKeeper and the in-memory data grids.

If TrueSource fits your estate and your budget, it is a serious offering built on a real standard, and we would rather you bought the right thing than the thing we sell.

Related reading

• Bitnami images are no longer free: what to run instead
• Leaving VMware Tanzu: Spring, RabbitMQ and GemFire
• Broadcom RabbitMQ support compared with OSSeva
• Spring 5 and Spring Boot 2 support options compared
• Valkey vs Redis — Valkey is now in Broadcom's data-engine list too.