Flibustier: Why We Built a Container Security Auditor in Pure Bash
Source: Dev.to
“A lightweight, zero-dependency container runtime audit toolkit designed for redteam operations. No Python, no Docker image, no compilation — just scp and run.”
⚓ Flibustier: Why We Built a Container Security Auditor in Pure Bash
“When you’re inside a target network, you don’t have time to build a Python virtualenv or pull a 500MB scanner image. You need answers in seconds, with whatever tools are already there.”
TL;DR
We built Flibustier — a container runtime security auditor written entirely in Bash. It requires nothing but docker, jq, and standard UNIX utilities. No compilation, no package managers, no bloated dependencies. Just scp it to a compromised node and run it. It outputs findings in terminal, JSON, CSV, Markdown, or SARIF for your GitHub Security tab.
GitHub: github.com/toxy4ny/flibustier
The Problem: Redteam Reality
If you’ve ever done a redteam engagement against a containerized environment, you know the drill:
-
You land on a worker node or a compromised pod.
-
You want to map the attack surface of the container runtime.
-
You reach for your favorite scanner… and realize it’s written in Python and needs
pip install -r requirements.txt. -
Or it’s a Docker image that you can’t pull because the node has no internet access.
-
Or it needs root and a dozen kernel headers to compile a kernel module.
The target cluster doesn’t care about your development workflow. It has bash, it (probably) has jq, and it definitely has docker. That’s it.
Existing tools are great for CI/CD pipelines:
Trivy scans images for CVEs.
Falco monitors runtime behavior.
Docker Bench checks host configuration.
But they all assume you’re running them from a comfortable bastion host with internet access, package managers, and time to spare. In a redteam scenario, you’re often operating from a minimal container, a sidecar, or a compromised node where apt-get is a distant dream.
The Philosophy: Zero-Friction Runtime Auditing
We asked ourselves: What is the absolute minimum tool that can tell us if a container fleet is misconfigured right now?
Not “what vulnerabilities exist in the image layers” — that’s Trivy’s job.
Not “what syscalls are being made” — that’s Falco’s job.
We wanted to know:
-
Which containers are running
--privileged? -
Who mounted
/var/run/docker.sock? -
Which processes are running as root despite a
USERdirective? -
Who shares the host network or PID namespace?
-
Are there secrets in environment variables?
These are runtime misconfigurations. They don’t require a vulnerability database. They require reading docker inspect output and /proc status files. And docker inspect + jq + bash is all you need.
Why Bash?
I can already hear the objections: “Bash? For security tooling? In 2026?”
Yes. Here’s why:
- Universal Availability
Every Linux system has Bash. Every container host has Bash. You don’t need to install a runtime. You don’t need to worry about glibc versions. You don’t need python3.11 when the target only has python3.6.
- Zero Dependencies (Almost)
Flibustier needs:
bash (4.0+)
jq (available in every modern distro, often pre-installed)
docker CLI (you’re auditing Docker; it’s already there)
capsh (optional, for capability decoding)
That’s it. No pip. No npm install. No cargo build. No 200MB base image.
- Easy Exfiltration & Deployment
# From your attack box
scp -r flibustier/ user@target-node:/tmp/
ssh user@target-node "cd /tmp/flibustier && ./flibustier.sh --format json"
Enter fullscreen mode
Exit fullscreen mode
Done. The entire toolkit is under 20KB of shell scripts.
- Readable & Hackable
Redteamers modify tools on the fly. Bash is transparent. You can open any check file, understand it in 30 seconds, and adapt it to the specific quirks of your target environment. Try doing that with a compiled Go binary.
- Fast Startup
No interpreter warmup. No dependency resolution. Just fork and exec.
What Flibustier Checks
We focused on runtime misconfigurations that directly enable container escape or privilege escalation:
Check What it finds Severity
Privileged
--privileged containers
🐙 Kraken
Capabilities
CapAdd and effective vs. bounding set mismatches
🌀 Hurricane
Mounts
docker.sock, /proc, /sys, /dev, host root
🐙 Kraken
Namespaces
Host pid, net, ipc, uts, userns
🌀 Hurricane
Processes Root processes inside containers ⛈️ Storm
Secrets Env vars matching secret patterns ⛈️ Storm
Resources
Missing limits, mutable rootfs, no no-new-privs
🌊 Choppy–⛈️ Storm
Security Profiles Disabled seccomp/AppArmor/SELinux 🌀 Hurricane
The severity scale is nautical because we like our themes consistent:
-
🌊 Calm — Informational
-
🌊 Choppy — Low risk
-
⛈️ Storm — Medium risk
-
🌀 Hurricane — High risk
-
🐙 Kraken — Critical (immediate container escape likely)
In Action: A Redteam Scenario
Imagine you’ve gained access to a Kubernetes worker node via a compromised pod. You want to escalate to the host or move laterally. Instead of blindly poking around, you run Flibustier:
$ ./flibustier.sh --severity storm
⚓ FLIBUSTIER v0.1.0 — Container Runtime Security Audit
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[🐙 KRAKEN] /monitoring-agent Container runs with --privileged flag
[🐙 KRAKEN] /ci-runner Dangerous host mount detected
Mount: /var/run/docker.sock → /var/run/docker.sock (rw)
[🌀 HURRICANE] /load-balancer Host network namespace shared
[⛈️ STORM] /api-gateway Capability added: NET_ADMIN
[⛈️ STORM] /worker-7 Container processes running as root
Processes: nginx,python. No explicit non-root user configured.
Risk Score: 75/100 (HIGH) | 5 findings require attention
Enter fullscreen mode
Exit fullscreen mode
In 3 seconds, you know:
/monitoring-agent is privileged — full host device access.
/ci-runner has the Docker socket — you can spawn a new privileged container and escape.
/load-balancer shares the host network — you can sniff traffic and hit localhost services.
/api-gateway has NET_ADMIN — you can modify network interfaces and routes.
/worker-7 runs everything as root — a simple container escape gives you host root.
That’s your attack path, prioritized by severity. No noise from CVE databases. Just actionable runtime intelligence.
Output Formats for Every Workflow
Terminal (default)
Human-readable, color-coded, instant situational awareness.
JSON
./flibustier.sh --format json --output audit.json
Enter fullscreen mode
Exit fullscreen mode
Perfect for piping into jq, storing in your engagement notes, or feeding into automation.
SARIF
./flibustier.sh --format sarif --output results.sarif
Enter fullscreen mode
Exit fullscreen mode
Upload directly to GitHub Security tab or any SARIF-compatible platform. Because even redteamers need to write reports.
Markdown
./flibustier.sh --format md --output report.md
Enter fullscreen mode
Exit fullscreen mode
Drop it straight into your engagement report or wiki.
Comparison: Where Flibustier Fits
Tool Scope Runtime Dependencies Best For
Trivy Image CVEs No Binary CI/CD image scanning
Falco Syscall monitoring Yes Kernel module/eBPF Continuous runtime detection
Docker Bench Host config Partial Shell script Docker daemon hardening
Flibustier Runtime misconfigs Yes Bash + jq Rapid redteam assessment
Flibustier doesn’t replace these tools. It complements them by filling the gap between “I need a full vulnerability scan” and “I need to know what’s misconfigured right now on this specific node.”
For Defenders Too
While we built this with redteamers in mind, it’s equally valuable for blue teams:
# Run in CI pipeline
./flibustier.sh --format sarif --severity storm --output results.sarif
# Fail the build on Hurricane/Kraken findings
# Exit codes: 0 = clean, 1 = storm, 2 = hurricane/kraken
Enter fullscreen mode
Exit fullscreen mode
The GitHub Actions workflow in the repo automatically uploads SARIF to your Security tab and fails the pipeline on critical findings.
Under the Hood: A Modular Bash Architecture
We didn’t just dump everything into one script. Flibustier is structured like a proper toolkit:
flibustier.sh # Entry point, argument parsing
lib/
boarding.sh # Environment validation
hold.sh # Severity engine, finding registry
logbook.sh # Output formatting
chart.sh # Report generators (JSON/CSV/MD/SARIF)
checks/
privileged.sh # Check logic
capabilities.sh
mounts.sh
namespaces.sh
processes.sh
secrets.sh
resources.sh
security_profiles.sh
Enter fullscreen mode
Exit fullscreen mode
Each check is a standalone module. Want to add a new check? Create checks/your_check.sh, implement check_your_check(), and it automatically integrates with the severity engine and all output formats.
Limitations & Honesty
We’re not claiming Bash is the perfect language for security tools. It has limitations:
No type safety. We validate inputs carefully, but Bash is Bash.
Performance. On fleets with 1000+ containers, a compiled tool would be faster. For typical engagements (<100 containers), it’s instant.
Error handling. We use set -euo pipefail and trap errors, but edge cases exist.
However, for the specific use case of rapid runtime assessment during an engagement, these trade-offs are worth it. The alternative is often no assessment at all because you can’t deploy your primary toolkit.
Try It
git clone https://github.com/toxy4ny/flibustier.git
cd flibustier
chmod +x flibustier.sh
# Run it
./flibustier.sh --format json | jq '.summary'
Enter fullscreen mode
Exit fullscreen mode
Or run it from Docker:
docker run --rm -it \
-v /var/run/docker.sock:/var/run/docker.sock:ro \
flibustier --format json
Enter fullscreen mode
Exit fullscreen mode
Contributing
Found a new container escape vector? Want to add a check for Kubernetes-specific misconfigurations? PRs welcome. The modular architecture makes contributions straightforward.
Final Thoughts
Security tooling often follows the “shiny object” syndrome — complex, feature-rich, and dependent on ever-growing stacks. But when you’re deep inside a target environment, simplicity wins. Bash is boring. Bash is everywhere. Bash just works.
Flibustier embraces that philosophy. It’s not fancy. It’s effective. And when you need to know if that container fleet is one misconfiguration away from total compromise, it gives you the answer in seconds.
Happy hunting. 🏴☠️
Have you built security tools in “unconventional” languages for operational reasons? Share your stories in the comments.