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.
At a glance
What this is: PassBolt explains that Bitnami’s repository changes will force Passbolt Helm users to rethink how they source and govern MariaDB, MySQL, and Redis dependencies.
Why it matters: For IAM and NHI practitioners, this matters because Kubernetes deployments often depend on machine identities, images, and stateful services whose support lifecycle can become a hidden security and availability risk.
Context
Bitnami’s shift changes the support and patching assumptions behind container images that many Helm charts consume. When a chart depends on third-party images for database and cache services, the real governance question is no longer installation convenience but whether those dependencies can still be trusted over time.
For Passbolt users, the issue sits inside deployment lifecycle control for stateful services: MariaDB or MySQL for persistence and Redis for sessions and caching. The article frames the migration as a move away from reliance on legacy images toward components that can be maintained with clearer operational ownership.
This is a configuration and dependency-governance story, not a product feature story. The practical question is how teams preserve secure, supportable runtime behaviour when an upstream image source stops receiving fixes while the Helm chart itself remains open source.
Key questions
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. The chart may still deploy, but teams can inherit stale images, missed security patches, and unclear upgrade accountability. That turns a convenience dependency into a lifecycle risk, especially for stateful components that support production identity services.
Q: Why do legacy images create more risk for database and cache layers?
A: Database and cache services are stateful, so stale images affect persistence, session handling, recovery, and availability at the same time. When the upstream image source stops receiving fixes, the operator inherits security and reliability risk that chart simplicity had previously hidden.
Q: What should teams do before replacing bundled Helm dependencies?
A: They should test the substitute components against the organisation’s availability, backup, restore, and secure configuration requirements. Replacement is only safe when the new stack can be operated with the same or stronger lifecycle discipline than the old one.
Q: How should organisations govern third-party images in Kubernetes?
A: Treat every referenced image as a governed dependency with an owner, a patch path, and a removal plan if upstream support changes. If the image source becomes legacy, the deployment model has already changed and the governance model must change with it.
Technical breakdown
Why legacy container images create hidden lifecycle debt
When a vendor moves images into a legacy repository, the chart may still render and deploy correctly while the underlying runtime quietly stops receiving fixes. That creates lifecycle debt: the deployment works today, but patch cadence, vulnerability remediation, and supportability become the operator’s problem. In Kubernetes, that debt matters more for stateful services because database and cache layers anchor application availability and data handling. The risk is not only version drift. It is the loss of a trusted update path for components that the chart assumes will remain current. Once that assumption breaks, keeping the same chart is no longer a neutral choice.
Practical implication: treat upstream image deprecation as a governance event, not a routine dependency update.
How Helm subcharts shift responsibility for database and cache governance
Helm subcharts simplify deployment by bundling dependencies, but they also hide how much operational responsibility remains outside the chart. If a subchart points to images that are no longer maintained, the organisation still owns upgrade planning, availability design, backup handling, and configuration hardening. For Passbolt-style deployments, the database and cache are not disposable plumbing. They are stateful services that directly affect security posture and recovery. The move from bundled Bitnami components to alternatives such as MariaDB Operator and Valkey changes who owns the runtime lifecycle and how clearly that ownership is expressed in the stack.
Practical implication: map every bundled subchart to a named owner for patching, backups, and recovery before the dependency changes.
Why open-source replacements change more than the image source
Replacing one image source with another is not the same as preserving the same operating model. A community-maintained operator introduces different installation patterns, different failure handling, and different expectations for high availability and upgrades. For teams, that means migration work is partly technical and partly governance-driven: the question is whether the new stack can meet the organisation’s stability and maintenance requirements once the vendor-managed defaults disappear. The article’s emphasis on testing before making the new components default is a reminder that stateful service migrations fail when teams optimise for familiarity instead of supportability.
Practical implication: validate the replacement stack against your availability, backup, and upgrade standards before adopting it in production.
Breaches seen in the wild
- Massive Docker Hub Secrets Leak: 10,000+ Docker Hub container images expose hardcoded secrets and authentication keys.
- Secrets in Docker Hub images (RWTH Aachen study): A 2023 RWTH Aachen study found secrets in 8.5% of container images, and 275,269 internet hosts still using the leaked private keys.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Legacy image retirement is a lifecycle governance problem, not a packaging problem. When a chart still deploys but the referenced images no longer receive fixes, the security decision shifts from build-time convenience to runtime accountability. The issue is not whether the Helm chart is open source. The issue is whether the organisation can still govern patch exposure for the stateful dependencies that chart pulls in. Practitioners should treat upstream image retirement as a loss of assurance over the deployment chain.
Bundled subcharts can obscure ownership of machine-identity dependencies. Database and cache services in Kubernetes are often treated as support components, yet they depend on images, secrets, and update processes that need explicit governance. Once a vendor changes the distribution model, the operator inherits the burden of proving that the MariaDB or Redis layer remains supportable. That is a workload identity and lifecycle issue as much as an application issue. Teams need to see which parts of the stack they actually control versus merely consume.
Open-source substitution does not remove operational risk unless lifecycle discipline moves with it. MariaDB Operator and Valkey may restore freedom from a single vendor catalog, but they also demand stronger internal process around failover, upgrades, backups, and secure configuration. The migration therefore tests whether the organisation has a real stateful-service operating model or only a deployment shortcut. The practitioner conclusion is simple: if the stack is security-sensitive, the lifecycle owner matters more than the chart shorthand.
Passbolt users should read this as a signal about where the Helm ecosystem is heading. More upstream projects are separating free distribution from production-grade maintenance, which means downstream teams will increasingly own dependency viability themselves. That pushes identity and application teams toward explicit inventory, supportability review, and controlled substitution of third-party components. The category lesson is that secure deployment now includes supply decisions, not just configuration decisions.
MariaDB operator governance becomes the durable control surface once Bitnami is no longer the default. The migration shifts attention from chart consumption to service ownership, because the database and cache layers are the parts most likely to create operational and security drift. The practical conclusion is that teams need to govern these dependencies as managed runtime services, not as invisible chart internals.
What this signals
Legacy image retirement exposes supportability debt. Once an upstream image repository stops receiving security fixes, the chart consumer owns the consequences of staleness even if the deployment still works. That shifts the control point from installation to lifecycle governance, which is where many Kubernetes teams are weakest.
Stateful dependencies deserve explicit ownership. Database and cache layers in Helm charts should never be treated as invisible plumbing because they carry patching, recovery, and availability obligations. When those obligations are not named, migration work becomes a security risk instead of a planned change.
MariaDB operator governance is the real migration test. The deciding factor is not whether the replacement stack is open source, but whether the organisation can operate it with disciplined upgrade, failover, and backup processes.
For practitioners
- Inventory chart dependencies and image sources Identify every Helm dependency that still points to Bitnami-managed images, then separate runtime-critical components from convenience defaults so you know what will break if the source becomes legacy.
- Assign owners for stateful service lifecycle Document who owns patching, backup, recovery, and upgrade decisions for MariaDB or MySQL and Redis-like services used by Passbolt, including any mirrored images you maintain yourself.
- Test the replacement stack before the default changes Validate MariaDB Operator and Valkey in a non-production environment against your availability, restore, and secure configuration requirements before treating them as the new baseline.
- Plan for a breaking migration window Prepare a change plan for the new major chart version so production teams can account for removed Bitnami subcharts, configuration overrides, and any support gaps during transition.
Key takeaways
- Bitnami’s repository changes turn a convenience dependency into a lifecycle and patching problem for Helm users.
- The most exposed parts of the stack are the stateful services that carry persistence, sessions, and recovery responsibilities.
- Teams need to identify ownership, test replacements, and plan migrations before default dependencies become legacy-only.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party Bitnami images are the dependency changing under Passbolt's chart. |
| NHI-01 — Improper Offboarding | Legacy image retirement is effectively an upstream offboarding event for dependent deployments. | |
| Recommendation — Inventory third-party images and replace any unsupported dependency before it becomes a security liability. Remove retired image sources from production paths and reassign ownership for the replacement stack. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Image and dependency lifecycle control maps to credential-style management of runtime access inputs. |
| Recommendation — Apply IA-5 discipline to rotate, replace, and retire runtime secrets tied to dependent services. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about controlling what dependencies remain authorised in the deployment stack. |
| Recommendation — Review authorisations for bundled dependencies and remove any image source that no longer meets support criteria. | ||
| MITRE ATT&CK | TA0003;TA0040 — Persistence; Impact | Stale container dependencies increase persistence windows and eventual operational impact if compromised. |
| Recommendation — Map unsupported image exposure to persistence and impact risk in your detection and remediation planning. | ||
Key terms
- Legacy container image repository: A legacy container image repository is an upstream source that still hosts images but no longer provides normal update and patch support. In practice, it becomes a distribution endpoint rather than a maintained security baseline, so downstream teams inherit the risk of staleness and must replace or mirror it deliberately.
- Helm Chart: A Helm Chart is a reusable package of Kubernetes deployment definitions, usually built from YAML templates and configuration values. It lets teams standardise how workloads are deployed, but it also means one insecure default can be copied across many environments if governance is weak.
- Stateful service lifecycle: Stateful service lifecycle is the governance of systems whose data, sessions, or failover behaviour must persist across upgrades and outages. For Kubernetes teams, it requires explicit ownership for patching, backup, recovery, and configuration because runtime changes can affect both availability and security.
- Dependency supportability: Dependency supportability is the ability of a downstream deployment to keep a component maintained, patched, and operational over time. It matters when charts or applications rely on external images, operators, or repositories whose maintenance model may change after deployment.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 8, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org