Skip to content
← /work
CASE 02

PAN-OS fleet automation platform

Pre/post upgrade behavioral validation, CVE exposure mapping, config drift detection and real-time upgrade telemetry across a large firewall fleet.

FRONTMATTER
---
title: "PAN-OS fleet automation platform"
summary: "Pre/post upgrade behavioral validation, CVE exposure mapping, config dri…"
stack: ["DuckDB", "Python", "Node", "D3"]
relevance: "Upgrade risk made measurable before the change window opens."
featured: true
section: work
---
STACK
DuckDBPythonNodeD3
Upgrade risk made measurable before the change window opens.

The problem with release notes

Release notes describe what changed in the product. They cannot describe what changes for a given fleet, because that depends on which features each box has enabled, which policies it actually evaluates, and whether the release touched any of those paths.

At fleet scale the distance between those two questions is most of the risk in an upgrade window.

Behavioral snapshots

The platform captures a behavioral snapshot of each firewall before the upgrade and again afterwards: routing table, tunnel state, session table characteristics, policy hit counts, and the interface and zone topology that policy resolves against.

Comparison is on behavior, not on configuration text. Two configurations that differ textually can be identical in effect, and two that read almost the same can resolve differently once an upgrade changes evaluation order. Diffing XML answers a question nobody asked.

CVE exposure across the fleet

Advisories are published against affected PAN-OS releases and content versions. Turning that into an answer for a specific fleet means knowing, for every box, which release it runs and which content version it has installed, and keeping that inventory current enough to be worth querying the hour an advisory lands.

The mapping is a version and content-based assessment: it reports which devices fall inside the affected ranges of a given advisory. It does not attempt to prove exploitability on any particular box, and the output is read as a scoping list rather than as a verdict.

Scoping is still most of the work. It is the difference between an upgrade that has to happen tonight and one that can wait for the next window.

Drift

Drift detection compares each box against its intended configuration rather than against its neighbors, because a fleet can be uniformly wrong. What it reports is the delta and when it appeared, which is usually enough to identify the change that introduced it.

Why DuckDB

Fleet snapshots are an analytic workload with no concurrent writers: wide scans across many point-in-time captures, grouped and compared. DuckDB runs embedded, so a snapshot set is a file rather than a service to operate, and a pre/post comparison is a query over two files.

For a tool that has to be trustworthy during a change window, having no database to keep running is a feature.

During the window

Upgrade telemetry is live for the duration of the window — per-device progress, and the behavioral checks re-running as each box comes back. The D3 layer exists so that the person holding the go/no-go decision is reading current state rather than waiting for a report.

Figure 2.1  Placeholder — architecture diagram.