Ever accidentally leaked sensitive credentials in your code?
Maybe just released a public shell script, baked in a container, an image, or any other public method?
You're not alone.
Nine years ago, I made a devastating mistake mistake.
During what should have been a routine container demo for a startup as their new cloud consultant, I accidentally pushed their AWS master key to a public repository (I know).
Within minutes, phones throughout the room buzzed with AWS security alerts.
The company went into emergency mode, rotating keys and locking down their entire platform.
Two days later, I was fired.
This traumatic experience taught me the dangers of hardcoded credentials.
For years afterward, I relied on a pile of tools and solutions – local git hooks, leak scanning tools – but the fear remained.
Every public push came with anxiety.
The problem is bigger than you might think
A simple GitHub search for "AWS_ACCESS_KEY_ID" returns over 967,000 results.
Security tools like GitLeaks can easily scan repositories and containers to extract these plain text secrets.
Once exposed, these credentials are compromised almost instantly.
Most developers address this by implementing:
Git hooks to prevent pushing sensitive data
Scanning tools to catch leaks
Secret management services
Or, they simply don't.
And then, curious about their inflated cloud bill, they find a bitcoin miner running on their account in a south eastern region. (True story).
Or, better yet: exploit a public key on Github
But these approaches are reactive, not preventive. They catch problems after they've occurred or add complexity to your workflow.
How about adding a compiler to your process?
WHAT? Compiling bash scripts..?
What if we could make our scripts unreadable to most scanners and users?
That's where Bunster comes in – an open-source tool that compiles shell scripts into binary executables.
Bunster doesn't just compile your scripts; it transforms them into full-fledged Go programs with support for modules, pipes, CLI arguments, and environment files. The resulting binary contains your code (including any secrets) in a form that's not easily readable by standard scanners or users.
WARNING: I'm absolutely NOT suggesting you start leaking keys everywhere because they're being compiled later. I'm merely suggesting adding another layer of security that helps even when leaks don't occur, making it harder to reverse engineer or find other bits of information.
Here's how to use it:
Install Bunster (it places itself in /local/bin on Linux or /home/bin on macOS)
Run bunster build -s your_script.sh -o your_binary
Use the binary instead of your script
For containers, this means you can:
Copy the binary instead of readable scripts
Create smaller, more secure containers
Reduce the attack surface for credential theft
Important Caveats
While Bunster offers significant security benefits, it's not a silver bullet:
The compiled binaries are much larger (depending on the amount of code)
Cross-compilation requires setting the correct Go environment variables
Binaries can still be reverse-engineered with enough effort
Remember: The goal isn't to encourage credential leaking but to add an extra layer of protection when you need to embed sensitive information in your code.
My New Protocol
After my costly mistake years ago, I developed a protocol that now includes Bunster as its final step in the chain, I try to add it as an automated CI step, especially for publicly released containers and scripts:
Store secrets in environment variables wherever possible
Use secret management services for team projects
Implement pre-commit hooks to catch accidental leaks
This approach has transformed my confidence when pushing code. While I still practice good security hygiene, Bunster provides that extra peace of mind I've been seeking for nearly a decade.
I wish I'd had it nine years ago 😅
Thank you for reading. Feel free to reply directly with any question or feedback. Have a great weekend!
SQLite Is the ULTIMATE Choice For 99% of Projects When you need to crack a nut, you grab a nutcracker, not a sledgehammer. So why, when it comes to databases, do so many of us immediately reach for a heavy, complex solution, just because we “feel” it’s right? too much? This simple question changes how you look at building software.The default solution for most developers is to spin up a dedicated database server like MySQL, Postgres, or a NoSQL option. This means dealing with separate running...
I've Been Using AWS Wrong for YEARS... For years, my approach to AWS felt like a battle. As a DevOps engineer and later and architect, building infra always involved a tedious process of carefully building templates and structure, reviewing, deploying, testing and iterating over and over. I’d either spend hours clicking through the console or writing endless infrastructure code, always feeling like I was one misconfiguration away from a headache. It turns out, I was making it much harder than...
You've been lied to about self hosting... This issue is brought to you by: Auth0, my auth provider for the last 6 years. Join their free virtual dev_day on June 18th to learn how to secure AI agents and applications. Save your free spot That title might sound a bit aggressive, but this isn't about hating on hosting platforms. It's about loving the freedom, control, and cost-savings that come from owning your deployment process, without giving up the slick, easy experience we all love. And...