FwChange

Enterprise firewall change management, made provable

Built by Rogue AI · Firewall change management with a reviewable audit trail · Self-hosted

Built solo over an extended series of iterations; runs as a self-hosted lab and portfolio demo.

FwChange — Enterprise firewall change management, made provable

The problem

Firewall changes are where outages and audit findings are born. In most teams the actual workflow is a ticket, a Slack thread, and someone editing a device by hand — with the reasoning, the approval, and the before/after state scattered across three systems or lost entirely. When an auditor or an incident review later asks who approved a rule, against which policy, and whether it conflicts with what was already there, the answer usually has to be reconstructed from memory. FwChange exists to make that workflow structured and the trail reconstructable by design.

What I built

A Next.js 16 application backed by PostgreSQL and Redis, with NextAuth 5 for authentication. Every change starts as a structured request rather than free text, routes through a multi-level approval chain, and is recorded as an immutable audit entry. A rule-analysis engine inspects proposed changes for conflicts before they are approved, and device drivers abstract the per-vendor differences behind one interface. Vendor credentials are encrypted at rest with AES-256-GCM, the database runs under a least-privilege application user, and the whole stack ships as hardened, network-isolated Docker containers bound to localhost.

Architecture

Structured change requests

A change is a typed record — target device, rule intent, justification, requested window — not a paragraph in a ticket. This is what makes everything downstream (analysis, approval, audit) machine-readable instead of prose someone has to interpret later.

Multi-level approval chains

Requests route through approval levels keyed to priority, with automatic escalation when a step breaches its SLA. The chain is recorded with the request, so the 'who signed off and when' question has a single answer rather than a search across inboxes.

Scheduled change windows

Approved changes can be bound to a maintenance window rather than executed the moment they clear review — keeping risky work inside agreed downtime and out of business hours, which is usually a hard requirement in the environments this tool models.

Risk & conflict analysis

An analysis engine evaluates a proposed rule against the existing policy for shadowing (a broader rule already swallows it), redundancy, and over-permissive scopes such as 'any' source or destination. It produces flags and a risk indication for the reviewer — a triage layer, deliberately not an auto-approve gate.

Network context: IPAM / NetBox

Rules read better with context, so the system enriches analysis with IPAM / NetBox source-of-truth data — turning a raw subnet into a named segment with a known owner, which is what lets a reviewer judge whether a change actually makes sense rather than just whether it parses.

Multi-vendor driver registry

A registry maps each vendor — Palo Alto, Fortinet, Check Point, Cisco, F5 and 33+ others — to a driver behind a shared interface, so the workflow and analysis layers stay vendor-agnostic. Honest caveat: a small number of drivers are exercised against real configs; the remainder are interface-complete skeletons, and the UI says which is which.

Tech stack

Next.js 16Prisma 7PostgreSQLRedis 7NextAuth 5

What broke first

▸
A change-management tool earns trust through its paper trail, not its automation. The value is being able to answer 'who approved this, when, against which rule set, and why' months later — so the structured request, the approval chain, and the audit log were the parts that had to be airtight before any push-to-device feature mattered.
▸
Multi-vendor support is mostly about admitting how different the devices are. A registry pattern with one driver interface per vendor keeps the analysis and workflow layers vendor-agnostic, but the honest reality is that a handful of drivers are exercised against real configs and the rest are scaffolding — so the UI is explicit about which is which rather than pretending uniform coverage.
▸
Risk and conflict analysis is a triage aid, not a verdict. Heuristics that flag shadowed rules, redundancy, and over-permissive 'any' scopes catch the obvious mistakes a reviewer is tired enough to miss, but they surface candidates for a human to judge — they do not, and should not, replace a firewall engineer signing off on the change.

Outcome

The result is a working reference implementation of provable firewall change management: every change is a structured, approved, audited record, and compliance evidence can be exported against the frameworks these environments actually answer to — NIS2, ISO 27001, PCI-DSS, DORA and KRITIS — instead of being assembled by hand at audit time. It runs self-hosted as a lab and portfolio demo today, and it is honest about its edges: uneven vendor depth, and analysis that informs a human reviewer rather than replacing one. As a demonstration of how to make security change management auditable by construction, it does what it set out to do.

Honest limits

This is a self-hosted firewall change-management system, built solo, running as a local lab and portfolio demo — the earlier VPS deployment has been retired, so it is not operating against a real production fleet today. The risk and conflict heuristics flag candidates for human review; they are decision support, not an automated approver, and they do not replace a firewall engineer's judgement. Vendor coverage is uneven: a few drivers are tested against real device configs and the rest are interface-complete skeletons. Treat it as a working reference implementation of the workflow, not a hardened commercial product.