Vulnerability management for air-gapped networks

Auditors expect a dated record for every import showing what moved, who approved it, and whether its integrity was verified. Keep the transfer log outside the isolated network, with the media serial number, the source system, the operator, the import date and the SHA-256 checksum recorded on the connected side before transfer and re-verified on the isolated side. Greenbone feed loads and Trivy database copies should each have their own entry. Trivy's self-hosting guidance describes downloading the trivy-db or trivy-java-db archive on a connected machine and copying it into the cache directory on the offline system, so the archive itself is the object to hash. Confirm with your assessor which hash algorithm and retention period they require, since neither is set by the tools.

Record the feed or database version at the moment of each scan, because findings are only meaningful against the data that was current then. In Greenbone Community Containers, feed data such as vulnerability tests, Notus data, CVE and CPE data and CERT-Bund advisories is loaded by dedicated data containers into volumes at startup, so the feed state is tied to container and volume versions. gvmd stores results in PostgreSQL, so each report can be linked to the scan task that produced it. For Trivy, the report should be generated with a version or database metadata captured alongside it. Confirm with your scanner vendor which fields in each report show the feed date, since the exact output varies by component and release.

Examiners want to see which assets were in scope, whether each scan was authenticated, and whether coverage gaps were recorded. Export the target list and asset group definitions from gvmd with each scan run, and keep the credential type used per target without storing the secrets themselves. Authenticated and unauthenticated results should be labeled, because unauthenticated scans miss many local package findings. Notus compares installed software on a host against known vulnerable versions during each scan, which is only possible when credentials allow access. Trivy reports can show which OS packages and dependencies were found in each image or filesystem, which serves as scope evidence for container targets. Ask your assessor how they define a complete scope for the isolated zone.

DefectDojo keeps the finding history, owner, status and due date for each vulnerability, which is the record auditors use to test remediation timeliness. Its OpenVAS parser imports Greenbone reports in CSV or XML format, so results from the isolated scanner can be ingested into the same tracker as other tools. Each import creates a test with a timestamp, and status changes such as accepted risk, false positive or fixed should carry an approver and a reason. Deduplication reduces repeated entries across scans, but confirm how your configured product and engagement structure handles findings that persist across feed updates. Keep exports of closed findings with their closure evidence, since a fix verified by rescan is stronger than a ticket marked done.

Maintain records of who can log in to the scanner, who can change scan configuration, and who can push or pull images from the internal registry that hosts Trivy databases. gvmd handles users and permissions and runs scheduled tasks, so its user list, role assignments and task change history are the primary scanner records. Registry access logs should show pulls of the vulnerability database images, and any push to the mirror should be traceable to a named operator and an approved transfer. Review these accounts on a schedule and retain the review record. Privileged access to the host itself is often covered by a separate PAM or logging control, so confirm where those logs are kept.

Show evidence from the offline configuration and from network controls, not only from the configuration file. Trivy's --offline-scan option stops it from contacting external services, and its checks bundle is embedded in the binary for offline misconfiguration scans, so a scan log showing no outbound lookups supports the claim. Record the flag used in each scheduled job, and capture firewall or egress logs for the isolated segment showing denied outbound connections during scan windows. Wazuh's offline installation guide and its offline vulnerability repository option follow the same pattern: the configuration is documented and the network proof is retained. Test this periodically by attempting a controlled outbound connection and recording the blocked result.

A software bill of materials for each imported tool and image is the strongest record of what entered the isolated network. Trivy can generate an SBOM for a target and can also scan an existing SBOM, so SBOMs produced on the connected side can accompany the transferred media and be checked on arrival. NERC CIP-013-2 addresses verifying software integrity and authenticity of vendor software and patches, which is the requirement behind checking packages carried across isolated boundaries. For other frameworks, confirm with the assessor whether signed SBOMs or hash lists are acceptable. Store the SBOM with the transfer log entry so each import links to its components.

Assessors sample individual records, so each control should produce a self-contained, dated export that can be read without the tool. Use Trivy report formats such as JSON or SARIF for machine-readable findings, and keep table output for review sessions. Export gvmd reports in the formats the scanner offers and store them with the scan configuration, feed version and task history. DefectDojo can serve as the index that links each finding to its scan, owner and closure evidence. Agree the sampling expectations with your auditor or examiner in advance, because the required period, format and completeness differ by framework and by the scope they accept.

The software is often free, but the total cost comes from the people, hardware and transfer work around it. The main components are scanner infrastructure, a staging host on the connected side, registry storage for mirrored databases, feed or edition licensing, and the recurring effort to triage findings and move updates across the boundary. Open-source scanners such as Greenbone Community and Trivy carry no license fee for the core tools, but the Greenbone Community Feed excludes some enterprise product tests and some air-gapped features sit in paid editions at other vendors. Ask for a written quote that lists each component, who pays for it and which items recur each year.

The Greenbone Community Containers need at least 2 CPU cores, 4 GB of RAM and 20 GB of storage, with 4 cores, 8 GB of RAM and 60 GB of storage recommended. These are the documented minimums for the scanner stack alone. Storage needs grow with the feed data, the scan results history and any Trivy database mirror kept in your internal registry, so plan for the registry and the results database separately. Scanner sizing also depends on how many targets run in parallel and how often scans run. Confirm the sizing for your asset count with the implementation partner before buying hardware.

A team with Linux, container and network administration skills can deploy the stack alone, provided it has time for the transfer routine and triage work. The harder part is the ongoing discipline: pulling feeds and database updates on a connected machine, verifying them, moving them across the boundary under change control and keeping the mirror current. Trivy's documentation warns that internal mirrors must be kept updated, and the Greenbone feeds load from data containers at startup, so a stale transfer shows up as stale results. Decide early who owns each step, and whether an outside partner will handle the build, the runbook or only part of the operation.

The work depends on information only your organization holds. Expect to provide a list of network zones and their owners, the rules for what may cross the isolation boundary, and the change approval path for transfers and scanner access. You will also need an asset inventory with hostnames, addresses, operating systems and owners, plus credentials for authenticated scans where they are permitted. Ask whether your security policy allows transferred media, which approvals apply to each transfer and who signs off on scanning operational technology or sensitive hosts. Missing answers to these questions are the most common cause of schedule slippage in regulated networks.

Duration depends mainly on the number of assets, the number of network zones and how many boundary crossings the design needs. A single flat network with a few hundred hosts is a different project from several segmented enclaves with separate registries and transfer points, and timelines should follow from a written scope rather than a general estimate. The phases to plan for are discovery of the asset and zone model, build of the connected staging host and isolated scanners, the transfer and mirror routine, test scans, and handover of runbooks. Ask the partner for a phased plan with dependencies on your approvals and for the assumptions behind each phase.

No. A partner can build, configure, document and support the platform, but accountability for risk decisions, remediation priorities and exceptions stays with your organization. Under an agreed scope, a partner may run the transfer routine, maintain the scanners and produce reports, while your teams keep sign-off on which findings are accepted, deferred or fixed. DeployOpen implements, hardens, documents and supports self-hosted open-source platforms inside the client's own networks, and it prepares evidence for compliance assessments without issuing audit reports or certifications. Written responsibilities should name which party performs each recurring task.

The recurring costs are mostly people and process, not software. Each feed or database update requires a connected machine, a verification step, a transfer and an import, so the effort repeats for as long as the environment is isolated. Other recurring items include triage of new findings, patch coordination with system owners, retention of scan records for auditors, and any support retainer. Paid editions or feeds, where they apply, add their own recurring license terms. Ask for the quote to split one-time build work from annual or monthly operating effort so that budget owners can see both.