Circuit Breaker

Map engine readyLocal-first / open source

Search, pin and jump anywhere on the Circuit Breaker site.

Pinned
Use a pin button to keep pages here.
Theme
Mode

← All news

Circuit Breaker Security Transformation — From 304 Vulnerabilities to Zero: A Full Journey

by BlkLeg

Where We Started

The previous mono-latest base image scan was sobering. 304 identified vulnerabilities — including 4 criticals in components you do not want compromised:

Component Severity Risk
libsqlite3-0 CRITICAL Arbitrary code execution via malformed DB queries
nats-server CRITICAL Pre-auth memory exhaustion, message injection
zlib1g CRITICAL Memory corruption in decompression paths
glibc HIGH 35 high-severity library flaws across the stack

These weren’t theoretical. A compromised IPAM tool is a uniquely dangerous foothold — it has broad network scan permissions, knows your topology, and in the case of the NATS and SQLite flaws, was potentially reachable without authentication. That’s the definition of “Subnet Chaos”: take out the IPAM tool, and you take down the operational visibility of the entire network it manages.

That was the starting point. Here’s where we are now.

The Rebuild: Zero Patchable Vulnerabilities

The new build (local-20260313-092120) has achieved a zero-vulnerability baseline for all components with available fixes.

Previous mono-latest:   304 vulnerabilities (4 critical, 35 high, ...)
Current build:            0 patchable vulnerabilities

This was accomplished by moving to a hardened python:3.12-slim-bookworm base image, eliminating the bloated dependency surface of the previous image, and running Trivy with --ignore-unfixed as a hard CI gate — meaning the build literally cannot ship if a patchable critical or high CVE exists in the image. That gate is now permanent.

For context on what this means against the competitive landscape:

SolarWinds IPAM recently disclosed CVE-2025-40551, a critical RCE in their flagship enterprise product. Circuit Breaker’s zero patchable vulnerability posture in the current build makes it a more defensible option than tools orders of magnitude larger in scope and budget.

Application-Level Hardening — What Got Built

Beyond the image rebuild, the past development cycle has added significant application-level defenses. Here is an honest OWASP Top 10 map of where we stand:

A01 — Broken Access Control 🟢 Excellent

4-tier RBAC (admin / editor / viewer + SSO roles) enforced at the FastAPI dependency injection layer. Every route is gated — no route is “auth optional.” A viewer cannot create, update, or delete through any documented or undocumented parameter path. IDOR testing is flagged for the upcoming penetration test.

A02 — Security Misconfiguration 🟡 Improving

All 304 patchable library CVEs resolved. Hardened docker-compose.yml with read_only: true, cap_drop: ALL, no-new-privileges: true, and proper network segmentation across frontend_net, api_net, and backend_net. One open high-priority item remains: the container still runs as root at the process level. This is documented and tracked — see the open items section below.

A03 — Injection 🟢 Excellent

SQLAlchemy ORM with parameterized queries throughout. Raw SQL uses explicit bind parameters. nmap argument validation now uses a strict flag allowlist + shell metacharacter blocklist validated at the API schema boundary — not at execution time. SNMP community strings validated against ^[a-zA-Z0-9_.@-]{1,64}$ before any subprocess call.

A04 — Cryptographic Failures 🟠 Moderate (one active item)

Argon2 for password hashing, salted HMAC for API tokens, Fernet AES-256 credential vault for SNMP community strings, iDRAC/iLO passwords, and OAuth tokens at rest. JWT audience validation now enforced — a password-reset token cannot be used as a session token.

The detractor in this category: A JWT secret was found in the repository’s git history. It is no longer present in HEAD and the active codebase is clean. However, git history is permanent and public. If you have deployed any version of Circuit Breaker prior to this post, you must rotate your CB_JWT_SECRET and CB_VAULT_KEY. Instructions are in the section below. This is not optional.

A07 — Identification & Authentication Failures 🟢 Excellent

TOTP MFA with backup codes. MFA endpoint rate-limited — account locked after 5 consecutive failures with a 15-minute coolout. Session cookies are HttpOnly, Secure, SameSite=Strict. Logout immediately invalidates the session cache entry — not after a 60-second TTL. Constant-time login responses prevent username enumeration via timing oracle.

A09 — Security Logging & Alerting 🟢 High

Comprehensive audit log covering all mutation events with actor ID, IP, timestamp, and action metadata. Sensitive data redacted before log writes — credentials never appear in logs. Audit log hash-chain integrity verification available at /api/v1/logs/verify-chain. Failed auth events logged with source IP for brute-force detection.

How It Compares to Peers

This came up in the assessment and I think it’s worth sharing directly:

Tool Stack Integrated Scanning RBAC MFA Modern Middleware
Circuit Breaker FastAPI + React ✅ nmap/SNMP built-in ✅ 4-tier ✅ TOTP ✅ CSP, HSTS, CSRF
NetBox / Nautobot Django ❌ Intentionally excluded ✅ ❌ CE ⚠️ Partial
phpIPAM PHP/MySQL ✅ ⚠️ Basic ❌ ❌ Dated
Infoblox / BlueCat Appliance ✅ DNS/DHCP/IPAM ✅ Enterprise ✅ ✅ Enterprise
SolarWinds IPAM Windows/.NET ✅ ✅ ✅ ⚠️ CVE-2025-40551

NetBox is the established “source of truth” standard and it is excellent at what it does. Circuit Breaker’s niche is the real-time visual layer — the interactive topology map, the live scan integration, the rack simulator — things NetBox deliberately avoids to maintain data integrity. They solve different problems. You can run both.

phpIPAM is the closest feature-comparable self-hosted tool, and Circuit Breaker is simply a more modern, more securable replacement for that use case.

What Is Still Open (Be Honest With Yourself)

I want to be clear about what this report does not mean. A clean vulnerability scan and a robust architecture are not the same as a verified-secure application. Three things remain:

1. Root Container Execution (High Priority, In Progress)

The application container still executes as root at the process level despite the non-root user being defined. This is the highest priority infrastructure item. Until it is resolved, a container escape — however unlikely given the other controls — provides full host privileges. Do not expose the Circuit Breaker management interface to an untrusted network segment until this is resolved. It belongs on a management VLAN.

2. No Manual Penetration Test Yet

Automated static analysis and architectural review — however thorough — are not a substitute replacement for a human red-teamer. Three specific things only a penetration test can validate:

  • RBAC bypass via IDOR: Can a Viewer role reach a write endpoint through undocumented object reference manipulation? Automated scans do not find this class of bug.
  • Network pivot from compromised container: Given that the container has network scan permissions, can a compromised instance be used as a jump host to reach VLANs it should not touch? This is especially relevant while root execution is unresolved.
  • Pre-bootstrap settings disclosure: During the initial OOBE setup phase, is metadata exposed before authentication is established?

A penetration test is on the roadmap. Until it happens, the recommendation from the assessment stands: keep Circuit Breaker within a trusted network segment.

The Roadmap from Here

For those following development, the security roadmap is sequenced as follows:

v1.1  — SBOM generation (Syft, SPDX + CycloneDX) + Signed images (cosign keyless)
v1.2  — SSO: GitHub/Google OAuth2, Keycloak/Authentik/Authelia OIDC, LDAP/AD
v1.3  — Runtime threat detection (Falco on Proxmox host, Security Alerts UI)
v2.0  — Compliance alignment: SOC 2 TSC + NIST 800-53 control mapping + evidence package

Each track has defined acceptance criteria and CI gates. Nothing ships without passing the security test suite, and the @pytest.mark.security regression tests covering every finding from the audit run on every pull request.

Thank You

This level of scrutiny — a 52-finding multi-domain static analysis followed by a full remediation cycle — is not something most open source projects of this age go through. The fact that Circuit Breaker came out the other side with a zero patchable vulnerability baseline, a tightened application security posture, and a documented roadmap to enterprise-grade controls says something about where this project is headed.

If you find something, please report it through [GitHub Security Advisories](https://github.com/BlkLeg/circuitbreaker/security/advisories/new) — not a public issue. The SECURITY.md at the repo root has the full disclosure policy.

— Shawnji

Screenshot From 2026-03-13 09-18-06

TL;DR

  • Old image: 304 vulnerabilities (4 critical). New image: 0 patchable.
  • App-level hardening is solid. OWASP A01/A03/A07/A09 are in good shape.
  • If you deployed a prior version: rotate CB_JWT_SECRET and CB_VAULT_KEY now.
  • Container still runs as root — keep it on a trusted VLAN until that’s resolved.
  • No manual pen test yet — treat it accordingly.
  • Roadmap: SBOM + signed images → SSO → runtime detection → compliance.