"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:

1. You land on a worker node or a compromised pod.
2. You want to map the attack surface of the container runtime.
3. You reach for your favorite scanner... and realize it's written in Python and needs pip install -r requirements.txt.
4. Or it's a Docker image that you can't pull because the node has no internet access.
5. 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 USER directive?
• 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)
• 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.

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:

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:

1. /monitoring-agent is privileged — full host device access.
2. /ci-runner has the Docker socket — you can spawn a new privileged container and escape.
3. /load-balancer shares the host network — you can sniff traffic and hit localhost services.
4. /api-gateway has NET_ADMIN — you can modify network interfaces and routes.
5. /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

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

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 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'

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.