"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:
1. 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.
2. Zero Dependencies (Almost)
Flibustier needs:
-
bash(4.0+) -
jq(available in every modern distro, often pre-installed) -
dockerCLI (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.
3. 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"
Done. The entire toolkit is under 20KB of shell scripts.
4. 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.
5. 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
In 3 seconds, you know:
-
/monitoring-agentis privileged — full host device access. -
/ci-runnerhas the Docker socket — you can spawn a new privileged container and escape. -
/load-balancershares the host network — you can sniff traffic and hitlocalhostservices. -
/api-gatewayhasNET_ADMIN— you can modify network interfaces and routes. -
/worker-7runs 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
Perfect for piping into jq, storing in your engagement notes, or feeding into automation.
SARIF
./flibustier.sh --format sarif --output results.sarif
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
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
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
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 pipefailand 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'
Or run it from Docker:
docker run --rm -it \
-v /var/run/docker.sock:/var/run/docker.sock:ro \
flibustier --format json
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.
Top comments (0)