Notifications
Clear all
Topic starter
08/07/2026 7:09 pm
TL;DR: Bitnami’s move to a legacy image repository leaves Helm dependencies exposed to stale, unpatched container images unless users migrate to new open-source defaults or manage their own mirrored stack, according to PassBolt. The real issue is lifecycle control for dependent machine identities, not just chart maintenance.
NHIMG editorial — based on content published by Passbolt: Bitnami Legacy Changes and Passbolt’s migration plan for open-source Helm deployments
Questions worth separating out
Q: What breaks when a Helm chart depends on images that move to a legacy repository?
A: The immediate break is not installation, it is trust in the maintenance model.
Q: When should organisations replace bundled Helm dependencies with owned infrastructure?
A: They should replace bundled dependencies when the upstream maintenance path no longer matches production risk tolerance.
Q: What do security teams get wrong about open-source replacement stacks?
A: They often assume open source reduces governance work, when it actually shifts responsibility to the operator.
Practitioner guidance
- Review every bundled dependency in the Helm chart Inventory the chart’s image sources, subcharts, and pinned versions, then identify which components depend on upstream maintenance models you do not control.
- Define ownership for database and cache lifecycle Assign an accountable team for MariaDB or MySQL, Redis-compatible cache services, upgrade validation, and rollback readiness before changing defaults.
- Test the replacement stack outside production first Validate MariaDB Operator and Valkey under your own deployment patterns, including failover behaviour, persistence, and configuration overrides.
What's in the full article
Passbolt's full blog post covers the operational detail this post intentionally leaves for the source:
- The exact Helm chart dependency changes Passbolt is planning for MariaDB and Redis-compatible services
- The migration path from Bitnami subcharts to MariaDB Operator and Valkey in an open-source stack
- The early-adoption options for teams that want to test their own database and cache components
- The rollout timeline and breaking-change considerations for existing Passbolt Helm users
👉 Read Passbolt’s migration plan for Bitnami-dependent Helm deployments →
Bitnami legacy images: what Passbolt users need to plan for?
Explore further
08/07/2026 7:33 pm
Bitnami’s shift exposes dependency lifecycle as an identity governance issue, not just a packaging inconvenience. Passbolt users are not simply losing a convenience layer. They are being forced to confront what happens when a stateful workload depends on externally maintained images whose maintenance model changes underneath it. The implication is that machine identity governance must include upstream dependency ownership, not only local deployment configuration.
A few things that frame the scale:
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: Who is accountable when a deprecated dependency remains in production?
A: Accountability belongs to the team that owns the deployment lifecycle, not the upstream maintainer who changed the source model. If a deprecated dependency stays live, the organisation must own the risk, the migration timeline, and the decision to continue relying on a non-maintained image source.
👉 Read our full editorial: Bitnami legacy changes force a Passbolt Helm migration rethink
