Running static analysis in an air gap: how PYD ENTERPRISES ships without phoning home

Start from the strictest constraint

When we designed PYD ENTERPRISES' delivery model we started from the strictest environment we expected to meet: a mainframe source repository in a segregated network zone, no route to the internet, change windows approved by a committee, and a security team that will run packet captures during the first scan. If the product works there, it works in a private VPC with controlled egress, and it certainly works in a lab.

That ruled out several common patterns at once. No SaaS control plane. No license server reachable over the internet. No telemetry, crash reporting or usage analytics. No model inference API calls. No dependency fetched at runtime from a public registry. Each of these is reasonable in most products and unacceptable in this one.

What ships

PYD ENTERPRISES is delivered as a set of OCI container images and a Helm chart, or as Docker Compose for single-node installs. Everything the analyzer needs is inside the images: parsers, dialect packs, the rule extractor, the synthesizers and the web interface for review and sign-off. The images are built from pinned base layers and are scanned before release; the software bill of materials ships with each version.

• Images and chart: transferred as a tarball through whatever media transfer process your security team approves.
• Detached signatures: every image digest and bundle is signed, and the installer verifies signatures against a public key you pin at install time.
• Offline license key: a signed file that encodes entitlements and expiry, verified locally. There is no license check call.
• Update bundles: quarterly parser and dialect updates arrive as signed bundles that you move across the air gap on your schedule.

Prove it with an egress-deny policy

We encourage every customer to verify zero egress rather than trust it. On Kubernetes the simplest test is a namespace-wide policy that denies all egress except in-cluster DNS and the database PYD ENTERPRISES uses for its own state, then running a full scan and watching for denied connections in the CNI logs.

In customer validations we have seen to date, the denied-connection count for the PYD ENTERPRISES namespace stays at zero for the entire run. If it ever is not zero, that is a defect and our security team wants to hear about it at the address on the security page.

1apiVersion: networking.k8s.io/v1
2kind: NetworkPolicy
3metadata:
4  name: pyd-egress-deny
5  namespace: pyd
6spec:
7  podSelector: {}
8  policyTypes: ["Egress"]
9  egress:
10    - to:
11        - namespaceSelector:
12            matchLabels:
13              kubernetes.io/metadata.name: kube-system
14          podSelector:
15            matchLabels:
16              k8s-app: kube-dns
17      ports:
18        - { protocol: UDP, port: 53 }
19    - to:
20        - podSelector:
21            matchLabels:
22              app.kubernetes.io/name: pyd-postgres
23      ports:
24        - { protocol: TCP, port: 5432 }

Data at rest and in transit inside the cluster

Source code, ASTs, symbol graphs and extracted rules are stored on volumes you provision, encrypted with keys you control. Traffic between PYD ENTERPRISES services uses TLS with FIPS 140-2 validated cryptographic modules. The review interface authenticates through your identity provider over SAML, and role-based access control limits who can see which system's source. Every sign-off, rejection and export is written to an audit log that you can forward to your SIEM over your own network.

Nothing in this list is unusual. The point is that every component is under your control, and nothing requires a connection to PYD ENTERPRISES to keep working, including after the license expires: exports already produced remain yours, in open formats.

Where language models fit, if at all

The deterministic engine does all of the analysis. Some customers choose to enable an optional description layer, which uses a language model to suggest human-readable names and summaries for rules the engine has already extracted. If you enable it, the model runs on infrastructure you host, inside the same network boundary, behind the same egress policy. PYD ENTERPRISES never calls an external model API, never trains any model on your code, and the product is fully functional with the layer switched off. Most regulated customers leave it off for the first scan and decide later.

What security teams check in the first week

The order is usually the same, and we have built the documentation around it.

1. Verify image signatures and compare the SBOM against internal vulnerability tooling.
2. Install into an isolated namespace with the egress-deny policy applied.
3. Run a scan on a non-sensitive codebase and confirm zero denied connections.
4. Review the SOC 2 Type II and ISO 27001 reports, available under NDA from the trust center.
5. Approve the production source repository as an input.

Expect two to four weeks from media transfer to first production scan in a bank. That time is well spent: once the security review is complete, every later system scan reuses it.