How to Generate an SBOM in an Air-Gapped Environment

The 2026 EU Cyber Resilience Act obliges manufacturers to generate a software bill of materials "in a commonly used and machine-readable format" starting from December 11, 2027. And the CRA reporting duty already (since September 11, 2026) expects a manufacturer to report whether an exploited component ships in their product within the first 24 hours. We covered this in detail in CRA Reporting Requirements Are Live.

Both of these regulations require an SBOM on demand. But it’s way more complicated when you need an SBOM inside a closed network, where generation may fail right at the first lookup that will require access to a public registry.

 

What does SBOM generation need from the network?

An SBOM generator reads a project's manifests and lockfiles, then constructs a complete dependency tree. Lockfiles typically contain precise version data. However, files like Maven `pom.xml`, Gradle build scripts, or Python `requirements.txt` files (without specified versions) only list the direct dependencies, leaving transitive dependencies out of sight.

To be able to build a complete dependency tree, the generator will try to access a package registry by requesting information about the exact version that matches each range, and libraries that this exact version depends on. Generator repeats these questions for every library, until it completes the dependency tree.

For regulated and sensitive industries like defense, infrastructure, government, banks with strict egress rules, each of the options carries different levels of operational costs. 

• Opening an outbound connection would grant an exception and will require the security team to review a new data flow. 

• On the other hand, staying fully offline produces an SBOM that may miss components the local database has never committed. In a situation where a new vulnerability is discovered and an advisory is published, you won’t be able to tell if you’re affected if the component was missing from an SBOM file.

 

CycloneDX or SPDX: which SBOM format fits CRA requirements?

The CRA hasn’t specified a desired format for an SBOM. The are two commonly used machine-readable standards which are CycloneDX, maintained by OWASP, and SPDX, maintained by the Linux Foundation. Both of them satisfy the "commonly used and machine-readable" definition. CycloneDX was designed around security use cases (vulnerabilities, component relationships), while SPDX grew out of license compliance.

The final decision on the format depends on the OEM customer or the auditor. DerScanner generates CycloneDX SBOMs in JSON.

 

How to generate an SBOM inside a closed network

Instead of using public package registries, regulated teams use internal repository managers.

1. Create mirrors of public registries in Nexus or JFrog Artifactory. They store internal copies of all the open-source libraries in use. New packages are downloaded outside, checked, and only then transferred inside through an approved channel. This means that every library in production has already been checked and stored in this internal repository.

2. Use mirrors when working with build tools. Maven settings.xml mirrors, npm .npmrc registry settings and pip index-url all send dependency resolution to the internal repository. Then the SBOM will include the actual versions used in the build.

3. Generate the SBOM against the repository manager. In DerScanner 13 the SBOM Generator pulls component data from the team's own Nexus or JFrog instances, with no calls to public registries.

[INFO] Supported package managers: NuGet (C#, VB.NET), Conan (C++), Pub (Dart), ProxyGolang (Go), Gradle and Maven (Java, Kotlin, Scala), npm (JavaScript, TypeScript), Packagist (PHP), PyPI (Python), RubyGems (Ruby), Cargo (Rust) and CocoaPods (Swift).

4. Scan the SBOM for vulnerabilities and license risk. It’s important to check components for known vulnerabilities, supply chain risks and license policy violations. DerScanner SCA runs this analysis on the generated CycloneDX file inside the same perimeter and provides results on found vulnerabilities and license risks.

 

5. 1 release = 1 SBOM. Keep record of Scan History and Scan Comparison to be able to answer CSIRT questions at the early warning stage under the CRA: when a vulnerable component entered a product and when a fix was shipped.

6. Control all mirror entries. Artifactory Analysis inspects the whole repository across projects. Custom security policies block downloads of components that violate them across Cargo, CocoaPods, Conan, Gradle, Maven, npm, NuGet, Packagist, ProxyGolang, Pub, PyPI and RubyGems.

In Lessons from the Miasma npm Campaign we’ve learned what happens when a malicious package doesn’t stop at the repository and reaches a build.

 

How often should the SBOM be updated?

An SBOM is a basic-level security hygiene measure. As long as it lists what libraries and components were used in the product, it should be updated every time a new patch or an update ships to the customer. A completed scan doesn't automatically update, so when a new CVE appears, re-scan the saved SBOM of each affected release.

 

Which releases need an SBOM first?

The honest answer would be — all of them. But in practice, it’s going to be more efficient to start with every version still sold or supported in the EU. When an SBOM is generated for the current releases, you can start digging deeper into older versions, until you reach the ones that are no longer supported.

 

 

Explore how on-premise and air-gapped deployment is supported by DerScanner with zero outbound connectivity and how the SBOM generation happens in supported ecosystems and CI/CDs. To run SBOM generation against an internal Nexus or JFrog repository, give it a try at the demo or directly request a PoC license.