Skip to content
Back to Projects

App Exposure Map

On-prem security visibility tool that maps source code to public exposure by chaining Checkpoint NAT rules, F5 iRules, Jenkins deployments, and Bitbucket repos, enabling risk-based prioritization of vulnerability findings.

PYTHON VITE F5_WAF TUFIN JENKINS BITBUCKET_SERVER
App Exposure Map architecture diagram
Click to expand

Overview

In a fully on-prem environment with hundreds of services, the security team had no reliable way to answer a basic question: is this app exposed to the internet? Without that answer, every vulnerability finding had equal urgency, making triage guesswork.

This system was built to close that gap. It traces the full chain from source code to public exposure by linking Bitbucket repositories through Jenkins deployment jobs, through F5 virtual servers and iRules, through Checkpoint NAT rules queried via the Tufin API. The result: every project is classified as publicly exposed or internal, giving vulnerability scanners (SAST, SCA) the context they need to prioritize findings.

Architecture

Data Collection Chain

A scheduled cron job queries four APIs on every run, assembling the exposure chain using server IP as the universal linking key:

  1. Tufin API (reading from Checkpoint): NAT rule destinations map to public-facing servers
  2. F5 API: virtual server configs and attached iRules
  3. Jenkins API: build jobs identify which server each repo was deployed to
  4. Bitbucket Server API: source repositories linked via Jenkins job configuration

The backend writes a fresh JSON file on every run. No persistent database: the JSON is the single source of truth, rebuilt completely each cycle.

iRule TCL Parsing

Standard NAT rules have a static destination. F5 iRules are different: they can route traffic dynamically based on URI patterns, sending requests to different backend servers depending on the path. A static NAT trace would miss these backends entirely.

The system parses iRule TCL code directly, extracting URI-based routing destinations and treating them as additional deployment server IPs. This ensures the exposure chain is complete even for services sitting behind dynamic iRule routing, not just simple static NAT rules.

IP Chain Assembler

The chain across all four data sources is assembled by matching server IP addresses:

  • Checkpoint NAT rule destination IP = deployment server
  • F5 iRule-extracted routing IPs = additional deployment servers
  • Jenkins job deployment targets matched by IP to NAT/iRule destinations
  • Bitbucket repo linked via the Jenkins job that deployed to that server

Frontend Dashboard

A Vite-based single-page app renders the results as interactive cards. Each card shows a NAT rule at a glance. Expanding a card reveals the full chain:

  • Servers behind the rule
  • Attached F5 iRules (with parsed routing logic)
  • Linked Bitbucket source repositories
  • Deployment server details
  • Jenkins build status, job name, and build duration

Impact

The security team used the system directly to classify every project as publicly exposed or internal, enabling proper risk-based prioritization: public-facing projects were fixed first.