Circuit Breaker Security Transformation — From 304 Vulnerabilities to Zero: A Full Journey #43
BlkLeg
announced in
Announcements
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
🔐 Circuit Breaker Security Transformation — From 304 Vulnerabilities to Zero
Hey everyone,
I want to take some time to walk through the full security journey Circuit Breaker has been on over the past few weeks. This isn't a typical changelog — it's a transparent look at where we started, what we found, what we fixed, and where we still have work to do. I think that kind of honesty matters in open source, especially for a tool that sits on your network and maps your entire infrastructure.
Where We Started
The previous
mono-latestbase image scan was sobering. 304 identified vulnerabilities — including 4 criticals in components you do not want compromised:libsqlite3-0nats-serverzlib1gglibcThese 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.This was accomplished by moving to a hardened
python:3.12-slim-bookwormbase image, eliminating the bloated dependency surface of the previous image, and running Trivy with--ignore-unfixedas 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:
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.ymlwithread_only: true,cap_drop: ALL,no-new-privileges: true, and proper network segmentation acrossfrontend_net,api_net, andbackend_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.
nmapargument 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_SECRETandCB_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:
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:
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:
Each track has defined acceptance criteria and CI gates. Nothing ships without passing the security test suite, and the
@pytest.mark.securityregression 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.mdat the repo root has the full disclosure policy.— Shawnji
All reactions