The Secret to Network Config & Security Compliance at Scale#

Vincent Phelan — Head of Network Architecture & Automation (financial sector)

• Why: The PM's network-security interest gets its strongest entry here: a working, scaled config-compliance system at a bank, with real numbers, built on open components (OPA, TextFSM, GitOps) rather than a compliance product.
• What: A config/security compliance pipeline that runs compliance for 7,000 devices against 70 policies in about one minute, treating architecture (constraints, standardization, cutting the product count) and automation as one discipline rather than two teams. Includes five anti-patterns from 20 years of war stories — premature optimization, snowflake-tolerant design, manual data massaging, imaginary scaling fears, and forcing formats (YAML/Jinja2) on engineers who don't natively speak them.
• How: Collect generic data from any source via device command output, parse with TextFSM ("yet to find something more generic and not AI"), filter junk before processing, and keep everything with a "not yet" adage. Compliance rules are expressed as Open Policy Agent (Rego) policies — and, in the "write programs that write programs" spirit, the OPA policies themselves are auto-generated with expected/actual/allow fields and control-mapping metadata (control ID, description) baked into each evaluation, producing per-device, per-control, per-evaluation overviews. The GitOps repo scales to 3.5M objects / ~20GB. Drift detection and remediation close the loop.
• Where applicable: Technique is org-agnostic and built on open source; the control-mapping metadata pattern is especially transferable to any regulated environment (financial, healthcare) where compliance evidence must tie to specific controls. The architecture-first stance (reduce product count before automating) is a prerequisite, not an option — the speaker is explicit that automation bolted onto a patchwork fails.