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.
Air-gapped vulnerability assessment
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.0Isolated technical evaluation
Outside · connected
Public vulnerability information is gathered and signed.
The air gap
Crossed only by a signed, data-only update file, on media you approve.
Inside · your isolated network
- Software is assessed from records you supply.
- Nothing is scanned, probed, or logged in to.
- Software lists and findings stay inside.
The update is checked before use.
Anything altered is rejected.
The overview
For program leaders and security managers
What the application is, why isolated networks need it, and what the team gains.
Technical reader? Skip to the technical evaluation1.1What is this application?
Vulnerability assessment
that stays on your side of the gap.
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.
- 01An air gap
- A deliberate separation between a network and the Internet. Nothing crosses unless people carry it across, under rules the organization sets.
- 02A known weakness
- 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.
- 03Passive reconnaissance
- Learning what may be exposed from records of what is installed, rather than by scanning, probing, or logging in to the systems themselves.
Evaluates known vulnerabilities in supported software. Results depend on the records supplied and the vulnerability information imported.
1.2Why 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.
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.
Illustrative situations, not customer stories or evidence of adoption. No certification, accreditation, or authorization to operate is claimed.
1.3What would our team gain?
Visibility
without exposure.
Understand what needs attention on networks you cannot connect, and keep a record that explains each result.
Visibility
See known weaknesses on isolated networks.
Identify known vulnerabilities in supported software, alongside gaps in the available information, without connecting the network to anything.
HowAssessment runs entirely on vulnerability information installed locally.
Non-intrusive
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.
HowYour team supplies the records; the application never contacts the systems they describe.
Control
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.
HowA failed or altered update leaves the existing information in place.
Accountability
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.
HowSaved reports remain readable offline, inside the network.
1.4In short
If you read
only this far.
A way to explain EnclaveLens to a colleague.
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 we cannot connect.
- Review sensitive systems without scanning them.
- 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.
- Come with a certification, accreditation, or authorization to operate.
Version 0.2.0 is for isolated technical evaluation. Production sign-in and separation between users are not yet enabled.
That is the overview. Next, how the team works across the gap.
Continue to level 2: In practiceIn practice
For security teams and system administrators
How updates cross the gap, how passive assessment works, and what a report records.
Skip to the technical evaluation2.1Working across the gap
Updates come in.
Your software lists stay put.
The team prepares vulnerability updates on the connected side, carries them across, and assesses software on the isolated side. Nothing about your software has to leave.
Connected side
01Prepare the update outside.
On a connected system your team runs, the latest public vulnerability information is gathered into a signed update file.
The air gap
02Carry it across.
Move the file through your approved removable-media process. The isolated side checks it before using it.
Isolated network
03Supply the software list.
Administrators export what is installed, using tools they already have. A list of software names and versions is called a software inventory.
Isolated network
04Review and keep the findings.
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.
Explore the technical workflow2.2Passive by design
See what’s exposed
without touching it.
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.
Assessed systemsServers, workstations, delivered software
Records your administrators export
× No scanning, probing, or login
EnclaveLensInside the same isolated 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.
- 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.
- Send your software lists outside the network.
The trade-offPassive means the application only knows what you supply. It does not discover systems, and results are only as complete as the records provided.
2.3What a report records
A finding
an assessor can follow.
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.
Keep the record
Review earlier findings and share reports with your team.
Example only
Enclave software review
Generic labels showing what a report can explain.
Technical evaluation
For security architects, assessors, and evaluators
Architecture, what crosses the gap, update verification, supported inputs, sources, and readiness.
3.1Architecture and the air-gap path
How the gap is crossed
behind the scenes.
Two separately deployed applications sit on either side of the gap: one prepares vulnerability information, the other uses it to assess your software. A signed release is a versioned vulnerability-data update whose origin and integrity are verified before use.
Admin
Synchronizes configured vulnerability sources, retains their evidence, publishes signed data releases, and exports them for air-gap transfer.
Client
Imports and verifies updates, assesses supplied inventories locally, and retains projects, findings, and reports. It contains no ingestion or publishing capability.
Independently deployed Docker applications, each with its own PostgreSQL database and persistent release storage.
Deployment and isolation details
- Admin holds the Ed25519 private signing key. To rotate it, distribute the new public key to every Client first, then replace the Admin signing secret.
- The Client image contains no Admin UI or API, source fetchers, source-sync scripts, Git executable or mirror, publisher, or private signing key.
- An air-gapped Client’s application network is internal by default. A fixed ingress gateway exposes localhost without giving the application or worker outbound access. Client startup needs no source tokens or upstream credentials.
- Large imports resume in 8 MiB chunks when the same file is selected again. The worker orders verified updates by predecessor cursor, not by the order files were selected.
- Web and worker database roles separate ordinary operations from source-corpus or distribution writes.
- Container base images are pinned by digest, and the CI pipeline builds each product image with its own SBOM attestation.
Air-gap workflow
A controlled crossing. No outbound path.
An operator carries a signed full baseline, then later updates, into the isolated network through the organization’s approved media process. The air-gapped Client runs on an internal network with no outbound access by default.
- 01Admin
Export a signed full baseline, or only the changes since the Client’s cursor.
- 02Approved media
Carry the .vulndb file across under your media-handling procedure.
- 03Client
Resume large uploads, verify signature and checksums, check compatibility, and activate in predecessor order.
Local trust boundary - 04Local evidence
Assess supplied inventories and report using only installed data.
To request the next update, carry the small client-cursor.json back to Admin; it describes the installed release, not your inventories. Freshness depends on your transfer schedule. Checks follow imports or manual requests; disconnected assessment does not provide real-time upstream intelligence.
Connected workflow
One trusted origin. Local assessment.
Where a controlled connection is permitted, Client pulls releases from one configured trusted Admin origin. Assessments still use the installed local release, even when the connection is unavailable.
- 01Admin
Synchronize configured sources and publish a signed release.
- 02Signed release
Download from the trusted Admin origin; interrupted downloads resume.
- 03Client
Verify signature, integrity, compatibility, and continuity.
Local trust boundary - 04Local evidence
Assess supplied inventories and retain reports.
A newly activated local release can trigger checks for active monitored targets. Operators can also request checks manually. Interrupted transfers preserve last-good data.
Trust is provisioned.
Admin holds the private signing key. Client uses public verification keys provisioned through a trusted, separate channel and never trusts a key contained in a downloaded update. Signatures establish origin and integrity within that trust model; they do not certify advisory accuracy.
What crosses the gap
Every artifact that moves between the two sides, and what never does.
- 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
Inventories & findings - 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.
From benefit to mechanism
Each benefit in the overview, and what delivers it.
SupportsSee 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.
SupportsLeave 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.
SupportsDecide what crosses the gap
Verified activation
Signature, member checksums, schema/client compatibility, and the exact predecessor cursor are checked before activation. Wrong-base, truncated, corrupt, or untrusted bundles leave the installed release unchanged; retained releases support rollback.
SupportsKeep 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.
SupportsRepeat 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.
SupportsKeep each review comparable
Revisioned inventories
Named projects and lists retain immutable revisions of normalized inventory evidence. Changes to software and changes to vulnerability data can be reviewed separately.
3.2Passive inputs and sources
Start with the
records you already have.
Passive assessment depends on the records you supply. Five input families are supported; the detailed reference below lists example files and the qualifications that affect results.
- Application filesLockfiles and manifests that list the open-source components an application uses.
- JSON SBOMsSoftware bills of materials: standard JSON lists of the components in delivered software.
- Linux packagesPackage lists exported from Debian, Ubuntu, Alpine, or RPM-based systems.
- Explicit entriesSoftware names and versions your team supplies directly, as JSON or CSV entries.
- Windows OSWindows product, build, and installed-update details from a short local collection script or compatible JSON.
Detailed input reference
All input groups10 groups
Application files
JavaScript / Node.js
package.jsonpackage-lock.jsonnpm-shrinkwrap.jsonyarn.lockpnpm-lock.yaml
Use exact resolved versions. A manifest's version constraints can remain unresolved.
Application files
Python
requirements.txtpyproject.tomlPipfile.lockpoetry.lockuv.lock
Only exact supported versions become resolved assessment coordinates.
Application files
Go & Rust
go.modgo.sumCargo.tomlCargo.lock
go.sum can include historical modules; prefer a resolved SBOM for an exact build. Unresolved Rust manifests and Git identities have matching limits.
Application files
Java / JVM & .NET packages
gradle.lockfilepackages.lock.jsonpackages.config
Maven coordinates are accepted in supported SBOMs or explicit inventories. No arbitrary pom.xml scanning or build execution. NuGet matching does not assess native .NET runtime or Framework servicing.
Application files
PHP, Ruby, Dart & Elixir
composer.lockGemfile.lockpubspec.lockmix.lock
Assessment requires compatible advisory records and supported local version semantics.
Application files
Additional language inventories
Manifest.tomlrenv.lockPackage.resolvedcabal.project.freezeopam.locked
Julia, R, Swift, Cabal, and opam inputs can be parsed while offline matching remains incomplete for some components.
JSON SBOMs
CycloneDX & SPDX JSON
bom.jsonsbom.jsoncyclonedx.jsonspdx.json
CycloneDX 1.2–1.9 JSON and SPDX 2.2/2.3 JSON. Supply exact component identities and versions. Accepted JSON is not a guarantee of complete matching; XML intake is outside this scope.
Linux packages
Linux package inventories
dpkg-statusdpkg-query.tsvapk-installedrpm-packages.tsv
Supply the exact distribution, release, and package identity. Source/binary distinctions and distribution-specific version semantics matter.
Explicit entries
Supplied packages & inventories
inventory.jsonos-inventory.jsoncontainer-inventory.jsonecosystem,name,versionpurl,version
JSON inventories or CSV entries describe the components you supply. This is not endpoint discovery or direct container-registry scanning.
Windows OS
Windows OS evidence
windows-os-inventory/v1 JSONcollect-windows-inventory.ps1
The collector reads local OS identity, registry build details, and Get-HotFix output, then writes JSON; it makes no network connections. Assessment requires a reviewed product/build mapping and installed-update evidence; catalog inclusion does not cover every edition, architecture, or servicing channel.
Parsing ≠ full coverage
Input parsing, advisory availability, and verified matching are separate stages. Version constraints can stay unresolved. Git-commit ranges and unknown version semantics remain inconclusive in the current offline path; Git identities without a verified matcher return incomplete coverage.
Current source families
Gathered on the connected side, carried across in signed releases.
- OSV.devEcosystem-aware vulnerability records
- GitHub Advisory DatabaseAdvisories and available metadata
- Native Microsoft CVRFWindows product and update evidence
Source families overlap. Advisory availability and local matching vary by ecosystem, identity, version semantics, and installed release. Imported ecosystems are not a count of verified matchers. Exploit Prediction Scoring System (EPSS) context is available where stored GitHub metadata supplies it.
3.3Readiness & scope
Version 0.2.0 / Isolated technical evaluation
Evaluate the fit.
Understand the boundary.
The reviewed release supports an isolated technical evaluation. Client production identity and tenancy are not enabled.
Testing mode allows shared anonymous access. Use a lab with non-confidential sample inventories and no public exposure. Production access and deployment requirements need to be resolved before production use.
Your authorizing official decides.
No certification, accreditation, or authorization is claimed, such as FedRAMP, Common Criteria, or an authority to operate. Air-gap security also depends on your network configuration, host controls, operator practice, and approved transfer process.
Supplied inventories. Reviewed identities.
Assess supported package inventories and reviewed Windows OS evidence. The product does not discover endpoints or directly scan container registries. Windows edition, architecture, servicing channel, and installed-update evidence still determine fit.
Known fixes, ready for review.
The product reports findings and available remediation evidence. It does not deploy patches. Native Microsoft application servicing remains outside the Windows OS scope.
Resources
Take the explanation
into your next review.
The brief follows the same three levels as this page: an overview for program leaders, the team’s air-gap and passive workflow, then the technical evaluation for architects and assessors.
PRODUCT BRIEF
Know your software risk.
Keep the gap closed.
Overview · In practice · Technical evaluation
Questions, answered
The details
that matter.
Each answer starts in plain language, followed by the technical detail.
01Does EnclaveLens need Internet access?
No. On the isolated network it uses only vulnerability information you have imported, and by default its application network has no outbound access.
Technical detailThe air-gapped Client starts from a verified full baseline and receives later updates as imported .vulndb files, with no public-service or Admin fallback. Freshness depends on the imported release and your transfer schedule.
02Does it scan our network or install agents?
No. It works only from records your team supplies. It never scans, probes, or logs in to the systems it assesses.
Technical detailInputs are uploaded or pasted inventories: lockfiles, JSON SBOMs, Linux package lists, explicit entries, and Windows OS inventory JSON. The optional Windows collector is a short PowerShell script your administrator runs locally; it reads OS and update information and writes a JSON file. Because assessment is passive, the product does not discover systems, and coverage depends on the lists supplied.
03What has to cross the air gap?
Inbound, a signed update file. Outbound, optionally, a small request file describing the update you already have. Your software lists and findings never need to leave.
Technical detailInbound .vulndb bundles contain manifest.json, a detached Ed25519 manifest.sig, source-native NDJSON chunks, and an offline matching dataset: data only, with no executable SQL or scripts. The optional client-cursor.json contains the bundle format version, installed release ID and cursor, and coverage metadata so Admin can export only what is missing.
04How do we know an update has not been tampered with?
Every update is checked before use. Anything altered, incomplete, untrusted, or out of order is rejected, and the existing information stays in place.
Technical detailClient verifies the manifest signature against public keys provisioned out of band, member checksums, schema/client compatibility, and the exact predecessor cursor before activation. Signatures establish origin and integrity within the configured trust model; they do not certify advisory accuracy.
05Is it certified, accredited, or authorized to operate?
No. No certification, accreditation, or authorization is claimed.
Technical detailThat includes, for example, FedRAMP authorization, Common Criteria evaluation, or an authority to operate. EnclaveLens is self-hosted software; whether it may run on a particular network is a decision for that network’s authorizing official. The architecture, trust model, and evidence can be reviewed against your own requirements during an isolated evaluation.
06Where does the vulnerability information come from?
From established public vulnerability sources, gathered on the connected side and carried across as signed updates.
Technical detailAdmin synchronizes configured OSV.dev, GitHub Advisory Database, and native Microsoft CVRF sources. Client assesses using its installed release. Source ingestion and supported local matching are separate: the number of imported ecosystems is not a matcher count.
07What is the Windows assessment scope?
Reviewed versions of the Windows client and Server operating systems. Microsoft applications such as Office are not included.
Technical detailAssessment uses native Microsoft product/build and installed-update evidence. Missing or contradictory evidence remains explicit. Office, Exchange, SQL Server, and native .NET Framework/runtime patch assessment are outside the current scope; NuGet dependency matching is separate.
08Can reports support a later review or assessment?
Yes. Saved reports keep the information they were based on, so they stay readable offline and inside the network.
Technical detailHTML/print, Markdown, CSV, and JSON reports use saved scan evidence, including the inventory revision, data release, source freshness, and native Microsoft context where applicable. They do not depend on live upstream pages. They are evidence for your review, not a compliance attestation.
09Does EnclaveLens deploy fixes?
No. It shows findings and available fix information so your team can decide what to do.
Technical detailIt reports findings, coverage states, and available remediation evidence. It does not deploy patches, rewrite supplied manifests, or automatically open remediation pull requests. No finding is not proof that software is free of risk.
10Is this release ready for production use?
Not yet. Version 0.2.0 is intended for isolated technical evaluation.
Technical detailClient production identity and tenancy are not enabled. Testing mode permits shared anonymous access, so use an isolated lab with non-confidential sample inventories and no public exposure. Production access and deployment requirements must be resolved first.
11Are KEV, direct EPSS, NVD, and VEX available?
Not as dedicated feeds today. They are proposed additions without committed dates.
Technical detailKEV, a direct daily EPSS feed, native complete CVE/NVD, general CSAF/VEX, and additional native distribution feeds are proposals. Existing reports can include EPSS where stored GitHub metadata supplies it. Native Microsoft CVRF support does not imply general CSAF/VEX support.
Air-gapped. Passive. On record.