Stop Releasing Bash Scripts. Do This Instead.

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).

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.

Here's how to use it:

1. Install Bunster (it places itself in /local/bin on Linux or /home/bin on macOS)
2. Run bunster build -s your_script.sh -o your_binary
3. 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:

1. The compiled binaries are much larger (depending on the amount of code)
2. Cross-compilation requires setting the correct Go environment variables
3. 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:

1. Store secrets in environment variables wherever possible
2. Use secret management services for team projects
3. 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!