Offline SBOM Generation in Air-Gapped Environments
The engineering architecture and challenges of generating accurate SBOMs in air-gapped or isolated environments where public package registries are unreachable, and how corporate repositories can replace public registries during SBOM generation.
Primary question: How can organizations generate an SBOM when build and security systems cannot access public package registries?
Direct answer
Configure local or corporate package repositories to replace public registries during SBOM generation, enabling accurate dependency discovery in fully isolated environments
Organizations can generate SBOMs in air-gapped environments by configuring their SBOM tool to use corporate or local package repositories instead of public registries. The configured repository temporarily replaces the public/default registry during SBOM generation, enabling accurate component discovery and metadata resolution. [offline-sbom-architecture]
Corporate repositories must contain the components actually used by the project, including transitive dependencies, to produce accurate SBOMs in offline mode. Incomplete repository mirroring leads to incomplete SBOMs. [offline-sbom-architecture]
Offline SBOM generation is one component of a broader air-gapped supply-chain strategy that also includes offline vulnerability database updates and controlled component intake processes. [nist-sbom-framework]
Definitions
Air-gapped environment
A build or security environment that is intentionally isolated from public networks and cannot access external package registries, cloud services, or internet-facing vulnerability databases.
Corporate repository
An internal package registry or repository manager (such as Nexus or JFrog) that hosts approved components for use within an organization, serving as a controlled alternative to public registries.
SBOM generation in offline mode
The process of discovering and cataloging all components in a software project when the SBOM tool cannot reach public package registries, requiring it to rely on locally available components and repository metadata.
Registry substitution
The architectural pattern of configuring an SBOM or SCA tool to use a corporate repository in place of the default public registry, so that component resolution and metadata lookup occur against locally available data.
The engineering problem
Some dependency-resolution-based SBOM workflows rely on public registries to resolve component metadata, versions, and dependencies. In air-gapped environments, this requirement cannot be met. [offline-sbom-architecture]
Even when source code and compiled binaries are available in an air-gapped environment, the absence of package registry access may prevent accurate identification of component versions and transitive dependencies. [offline-sbom-architecture]
Organizations may assume that offline SBOM generation is impossible or unreliable, leading them to skip SBOM production entirely in regulated or high-security environments. [nist-sbom-framework]
Corporate repositories that serve as registry substitutes must be kept up to date with approved components; stale or incomplete repositories produce outdated or incomplete SBOMs. [offline-sbom-architecture]
Security controls
Each control inspects a different artifact and produces evidence for an engineering decision.
Registry substitution
Offline SBOM generation- Artifact
- Corporate or local package repository containing approved components, configured as the registry source during SBOM generation.
- Risk
- Incomplete or inaccurate SBOM entries when the corporate repository does not contain all components used by the project.
- Output
- An SBOM generated without internet access, using locally available component metadata and registry data.
Evidence: DerScanner 13 offline SBOM generation — registry substitution architecture
Repository maintenance
Corporate repository update process- Artifact
- The corporate repository, kept synchronized with approved component versions through controlled update procedures.
- Risk
- Outdated SBOM entries when the corporate repository lags behind approved component updates.
- Output
- Current component metadata available for SBOM generation, ensuring SBOM accuracy reflects the latest approved versions.
Evidence: DerScanner 13 offline SBOM generation — registry substitution architecture
Verification workflow
- Identify all package ecosystems used in the project (npm, Maven, NuGet, PyPI, etc.).
- Configure a corporate repository manager (such as Nexus or JFrog) for each ecosystem with approved component versions.
- Configure the SBOM generation tool to use the corporate repository as the registry source for each ecosystem.
- Run SBOM generation against the project. The tool resolves dependencies and metadata from the corporate repository instead of public registries.
- Validate the generated SBOM for completeness by cross-referencing with the project's dependency manifests and build artifacts.
- Establish a process for updating the corporate repository with new approved components, and regenerate the SBOM when components change.
- Integrate offline SBOM generation into the build pipeline for continuous supply-chain visibility.
DerScanner · Enterprise
Relationship to DerScanner
DerScanner 13 supports offline SBOM generation through the SCA API, replacing public registries with corporate or local repositories during SBOM generation.
DerScanner 13 generates SBOMs without access to public package registries by using configured corporate or local repositories that temporarily replace the public/default registry during SBOM generation. [derscanner-offline-sbom]
DerScanner 13 supports repository authentication (login/password or token) and multiple ecosystems including NuGet, Maven, npm, PyPI, Cargo, CocoaPods, Conan, and others for offline SBOM generation. [derscanner-offline-sbom]
Limits of verification
- Offline SBOM accuracy depends on the completeness of the corporate repository; missing components result in incomplete SBOMs.
- Vulnerability assessment in offline mode depends on offline vulnerability database availability; real-time vulnerability feeds are not accessible.
- Repository authentication and access control add operational complexity to the offline SBOM workflow.
- Some components may not be available in corporate repositories if they were not previously approved and cached.
Related knowledge
SBOM for Delphi Applications
SBOM generation patterns apply in offline environments using corporate repositories
Relationship: related-toBlocking Risky Dependencies at the Repository Manager
Corporate repository management serves both as a registry substitute for offline SBOM and as a gate for blocking risky components
Relationship: related-toDerScanner
Product line providing offline SBOM generation capabilities
Relationship: related-toCanonical terms used: Air-gapped environment; Offline SBOM generation; Corporate repository; Registry substitution; Package repository manager.
Evidence and references
- DerScanner 13 offline SBOM generation — registry substitution architectureDerScanner 13 supports offline SBOM generation through the SCA API by using configured corporate or local repositories to replace public registries during SBOM generation, with repository authentication and multi-ecosystem support. This is a vendor-specific capability that enables accurate SBOM generation without internet access.
offline-sbom-architecture - NIST SP 800-161 Rev. 1 — Supply Chain Risk ManagementSBOMs should be maintained as part of supply chain risk management, including in environments with restricted network access.
nist-sbom-framework - DerScanner offline SBOM generationDerScanner 13 supports offline SBOM generation through the SCA API, using configured corporate or local repositories to replace public registries during SBOM generation, with repository authentication and multi-ecosystem support.
derscanner-offline-sbom
Generate SBOMs in air-gapped environments