# EnclaveLens ## Know your software risk. Keep the gap closed. EnclaveLens is a vulnerability assessment application for air-gapped and controlled networks. It identifies known weaknesses in supported software passively, from records your team supplies, without scanning, probing, or connecting to the systems themselves. Vulnerability updates cross the gap only as signed files your team approves and the application verifies. *For mission networks, secure labs, and the integrators who deliver software into them.* **Version 0.2.0 · Isolated technical evaluation · Reviewed October 13, 2026** **How this brief reads:** it starts with the big picture and goes one level deeper in each part. 1. **The overview** — for program leaders and security managers: what the application is, why isolated networks need it, and what the team gains. 2. **In practice** — for security teams and system administrators: how updates cross the gap, how passive assessment works, and what a report records. 3. **Technical evaluation** — for security architects, assessors, and evaluators: architecture, what crosses the gap, update verification, supported inputs, sources, and readiness. --- # Part 1 — The overview ## What is this application? EnclaveLens is an application your security team runs inside an isolated or controlled network. It compares the software installed there with published information about known weaknesses, then keeps the findings, review history, and reports inside that same network. - **An air gap** is a deliberate separation between a network and the Internet. Nothing crosses unless people carry it across, under rules the organization sets. - **A known weakness** is a flaw in a specific version of a piece of software that has been publicly reported, so others can check whether they are affected. Security teams usually call these vulnerabilities. - **Passive reconnaissance** means learning what may be exposed from records of what is installed, rather than by scanning, probing, or logging in to the systems themselves. EnclaveLens evaluates known vulnerabilities in supported software. Results depend on the records supplied and the vulnerability information imported. ## Why would our organization use it? Because isolated networks still run vulnerable software. An air gap limits who can reach a network, but the software inside still has weaknesses that are reported after it was installed. Finding them usually means connecting to an online service or running an active scanner, both hard to justify on a protected network. EnclaveLens brings vulnerability information in under your control and assesses without touching the systems themselves. Example situations (illustrative, not customer stories): - **A secure lab or program enclave.** A team reviews software on a network with no Internet connection. It imports approved vulnerability updates on its own schedule and keeps every result inside the enclave. - **An integrator delivering into a restricted environment.** An integrator provides a list of the components in the software it delivers. The receiving team checks it inside the controlled network, without sending the list anywhere. - **Systems where scanning is not allowed.** Some systems are too sensitive or too fragile for active scanning. The team reviews them from exported software lists instead. - **An assessor asks about an earlier result.** The team shows what was checked, which vulnerability information was installed at the time, and where information was missing. No certification, accreditation, or authorization to operate is claimed. ## What would our team gain? - **See known weaknesses on isolated networks.** Identify known vulnerabilities in supported software, alongside gaps in the available information, without connecting the network to anything. - **Leave the systems untouched.** Assess from software lists and package exports your administrators already produce. No scanning traffic, probes, logins, or resident agents on the systems being assessed. - **Decide what crosses the gap.** Vulnerability updates arrive only as signed files your team carries across through its approved process. The application checks each one before use and rejects anything altered. - **Keep a record an assessor can follow.** Each report preserves what was checked, which vulnerability information was installed, and how current it was, so a result can be explained long after the review. ## In short > EnclaveLens is an application we run inside our isolated network. It checks the software we use against published information about known weaknesses, from records we supply and without scanning our systems, and keeps a record of each review. Updates come in only as signed files we choose to carry across. **It helps the team** find known weaknesses on networks it cannot connect, review sensitive systems without scanning them, and show an assessor what was checked and with what information. **It does not** discover devices or software on the network by itself, fix or patch software automatically, or come with a certification, accreditation, or authorization to operate. **Status:** version 0.2.0 is for isolated technical evaluation. Production sign-in and separation between users are not yet enabled. --- # Part 2 — In practice ## Working across the gap 1. **Prepare the update outside** *(connected side)*. On a connected system your team runs, the latest public vulnerability information is gathered into a signed update file. 2. **Carry it across** *(the air gap)*. Move the file through your approved removable-media process. The isolated side checks it before using it. 3. **Supply the software list** *(isolated network)*. Administrators export what is installed, using tools they already have. A list of software names and versions is called a software inventory. 4. **Review and keep the findings** *(isolated network)*. Examine known issues and information gaps. Reports stay inside the network. After the first import: - **Repeat checks after each import.** When a new update is imported, monitored software can be checked again automatically or on request. The history shows what is newly found, still present, resolved, or still unclear. - **Ask only for what is missing.** The isolated side can produce a small request file describing the update it already has. Carried out, it lets the connected side prepare only the changes since then. It contains no software lists or findings. - **Keep each review comparable.** Every change to a saved software list is kept as a separate version, so the team can tell a change in its software apart from a change in what is known about it. Results are only as current as the latest import. Disconnected assessment does not provide real-time vulnerability information, so set a transfer schedule that matches your risk. ## Passive by design EnclaveLens takes a passive-reconnaissance approach to your own systems. It learns what may be vulnerable from records of what is installed, not from the systems themselves, so assessment adds no scanning traffic, logins, or agents to a sensitive network. **What it works from:** software lists and package exports your administrators already produce; software bills of materials (SBOMs) supplied with delivered software; Windows version and update details from a short script your administrator runs; and vulnerability information installed from signed, verified updates. **What it never does:** scan networks, ports, or hosts; probe, log in to, or run anything on the systems it assesses; install resident agents; or send your software lists outside the network. **The trade-off:** passive means the application only knows what you supply. It does not discover systems, and results are only as complete as the records provided. ## What a report records Each report records which software was reviewed, which vulnerability update was installed, and where the assessment needs better information. The record stays inside the network, so an earlier result can be explained during a later review or assessment. **Illustrative example — generic labels, not actual findings:** - **Software reviewed:** the saved version of the software list; the report retains its inventory revision. - **Information used:** the imported vulnerability update; the report records the exact release used. - **How current it was:** source freshness at assessment time, based on the latest import. - **Known issues:** findings and available fix information for the team's review; patches are not deployed. - **Gaps in the assessment:** more information needed; for example, a software version has not been supplied. Review both findings and gaps. No finding does not establish that software is risk-free. --- # Part 3 — Technical evaluation ## Architecture and the air-gap path Two separately deployed applications sit on either side of the gap. **Admin** (connected side) synchronizes configured vulnerability sources, retains their evidence, publishes signed data releases, and exports them for air-gap transfer. **Client** (isolated side) imports and verifies updates, assesses supplied inventories locally, and retains projects, findings, and reports; it contains no ingestion or publishing capability. Each is a Docker application with its own PostgreSQL database and persistent release storage. - **Air-gap (primary):** an operator exports a signed full baseline, or only the changes since the Client's cursor, and carries the `.vulndb` file across under the organization's media-handling procedure. Client resumes large uploads in 8 MiB chunks, verifies the signature and checksums, checks compatibility, and activates updates in predecessor order regardless of the order files were selected. The air-gapped Client's application network is internal by default; a fixed ingress gateway exposes localhost without giving the application or worker outbound access. There is no upstream or Admin fallback, and disconnected assessment does not provide real-time upstream intelligence. - **Connected (where permitted):** Client pulls releases from one configured trusted Admin origin. Assessments still use the installed local release, even when the connection is unavailable. ## What crosses the gap - **In — `*.vulndb` update:** a bounded ZIP containing `manifest.json`, a detached `manifest.sig` (Ed25519), source-native NDJSON chunks, and an offline matching dataset. Data only: no executable SQL or scripts. Admin also publishes a whole-bundle SHA-256 for transfer verification. - **In, once — verification key:** Admin's public verification key, installed on each Client through a separate, trusted channel. A key contained in a downloaded update is never trusted. - **Out, optional — `client-cursor.json`:** the bundle format version, installed release ID and cursor, and its source coverage, so Admin can export only what is missing. It contains no inventories, findings, or reports. - **Never:** software inventories, findings, and reports stay on the Client unless your team chooses to export them. The Client never holds Admin's private signing key. Wrong-base, truncated, corrupt, untrusted, or unsupported bundles leave the installed release unchanged, and retained releases support rollback. Signatures establish origin and integrity within the configured trust model; they do not certify advisory accuracy. Container base images are pinned by digest, and the CI pipeline builds each product image with its own SBOM attestation. ## From benefit to mechanism - **See known weaknesses on isolated networks → offline matching.** Client matching and reports use installed or stored data, never live public lookups. A scan without verified local data reports incomplete coverage rather than a clean result. - **Leave the systems untouched → evidence-only intake.** Inventories arrive as uploaded or pasted files and are normalized into evidence; original uploaded bytes are not retained as inventory evidence. No network scanning, host discovery, or remote login is part of the workflow. - **Decide what crosses the gap → verified activation.** Signature, member checksums, schema/client compatibility, and the exact predecessor cursor are checked before activation. - **Keep a record an assessor can follow → offline reports.** HTML/print, Markdown, CSV, and JSON exports use stored scan-time evidence, including source freshness and the exact data release, without live upstream lookups. - **Repeat checks after each import → checks after activation.** A newly activated release can queue checks for active monitored targets. History distinguishes newly detected, persistent, resolved, and inconclusive results. - **Keep each review comparable → revisioned inventories.** Named projects and lists retain immutable revisions of normalized inventory evidence. ## Passive inputs and sources Passive assessment depends on the records you supply. Five input families are supported: - **Application files:** lockfiles and manifests such as package-lock.json, requirements.txt, Cargo.lock, and gradle.lockfile. - **JSON SBOMs:** CycloneDX 1.2–1.9 JSON and SPDX 2.2/2.3 JSON software bills of materials. - **Linux packages:** files such as dpkg-status, apk-installed, and rpm-packages.tsv. - **Explicit entries:** inventory JSON, or package/version and purl CSV entries. - **Windows OS:** windows-os-inventory/v1 JSON from the included `collect-windows-inventory.ps1`, which reads local OS identity, registry build details, and Get-HotFix output, then writes JSON; it makes no network connections. Input parsing, advisory availability, and verified matching are separate stages. Exact versions and supported identities matter. Constraints can remain unresolved; Git-commit ranges and unknown version semantics remain inconclusive in the current offline path. Current sources are OSV.dev for ecosystem-aware vulnerability records, GitHub Advisory Database for advisories and available metadata, and native Microsoft CVRF for Windows product and update evidence, gathered on the connected side and carried across in signed releases. These sources overlap; imported ecosystems are not a count of verified local matchers. Native Windows OS assessment requires reviewed product/build and installed-update evidence. Edition, architecture, and servicing channel affect fit. Office, Exchange, SQL Server, and native .NET Framework/runtime servicing are outside scope; NuGet package matching is separate. The product assesses supplied inventories, with no endpoint discovery or direct container-registry scanning. ## Readiness and proposed additions Version 0.2.0 is intended for isolated technical evaluation. Client production identity and tenancy are not enabled. Testing mode permits shared anonymous access; use an isolated lab with non-confidential sample inventories and no public exposure. Resolve production access and deployment requirements before production use. No certification, accreditation, or authorization is claimed, such as FedRAMP, Common Criteria, or an authority to operate. Whether EnclaveLens may run on a particular network is a decision for that network's authorizing official. Air-gap security also depends on your network configuration, host controls, operator practice, and approved transfer process. The product reports findings and available remediation evidence. It does not deploy patches or automatically change supplied projects. **Proposed additions — no committed dates:** CISA KEV, a direct daily EPSS feed, native complete CVE/NVD, general CSAF/VEX, and additional native distro feeds. Existing Exploit Prediction Scoring System (EPSS) context is available where stored GitHub metadata supplies it. --- ## Continue the review Explore the [overview](./#product), [air-gap workflow](./#how-it-works), [passive assessment](./#passive), [technical details](./#technical-details), [input qualifications](./#coverage), and [FAQ](./#faq) on the local marketing site. A [print-friendly version of this brief](./product-brief.html) is included. Product facts were reviewed against the product repository's marketing packet, README, and implementation. This brief does not establish independent security certification, performance results, or production acceptance.