Hey there! Welcome to Platform Weekly. Your weekly swing of the platform engineering axe. How did you like this week's bonus platform weekly? We’ve got so much happening in the community over the next few weeks. New certifications, some awesome new research, but most of all, PlatformCon is back (and ofc bigger than ever).

I’ve got another palette cleanser for us this week. Are your Helm charts putting you at risk?

But first,

• 17% of security teams (so far) are shutting down all usage of AI for platform engineers. Yet, 90% report using AI daily. How is your security responding? Answer the State of AI Platform Engineering!
• Workshops for PlatformCon Live Day NYC & Platform Live Day LDN just launched. Register ASAP as spots are limited!
• Did you know I’ll be teaching two live courses in London?

Is your Helm a risk?

2 weeks ago, I read a post on Reddit detailing Microsoft’s research on risks in public Helm charts. A huge issue considering it’s basically the default package manager for k8s at this point (75% of us are using Helm according to the latest CNCF numbers).

This Tuesday, just a few weeks later, Nigel Douglas from Cloudsmith did an awesome community webinar (and article) explaining how to solve the exact problems identified by Microsoft.

So, let’s talk risks.

• Default configurations are often insecure, exposing services and granting overly permissive access (e.g., wildcard RBAC), leaving security tuning up to the user.
• Sensitive data like credentials may be hardcoded or weakly encoded, risking leaks. I have seen far too many Helm charts storing tokens, API keys, even passwords directly in plaintext within config files…
• Charts often bundle vulnerable dependencies, including containers or libraries, and can create "dependency death loops" that break deployments and widen the attack surface.

There are some hugely popular open source apps whose Helm charts are riddled with these issues…

So what can you do? Simple answer, start by actually customizing the public charts to fit your orgs needs. Make sure you’re storing and managing charts in trusted, version-controlled repos, and if you can only use certified sources. Plus actually validate and test your charts (ideally in an automated way through your CI/CD) to catch issues.

This isn’t something to take only the simple answer, though.

Go read Nigel’s 7-step process to making sure you don’t have insecure Helm charts that blow everything up (and prob get you fired).

What are you waiting for?