The Core Problem: No Standardized Dependency Management

Modern ecosystems like Python, JavaScript, and Rust have centralized package registries (e.g., PyPI, npm, crates.io) and well-defined manifest files (e.g., requirements.txt, package.json, Cargo.toml). This allows SBOM tools to easily detect:

• Package name and version
• Download location and hash
• Licensing information
• Dependency relationships

C/C++ has none of this.

Instead, developers rely on informal, ad-hoc methods that leave no clear metadata trail, making it nearly impossible for SBOM tools to determine what’s in your codebase, let alone which components are vulnerable or out of date.

Here are several examples I regularly encounter:

• Copy-paste integration: Some C/C++ libraries officially recommend copying header files or source files directly into a project. Rather than traditional “packages,” the files become part of your project through direct integration.
• Vendor/3rdparty directories: In some instances, developers may copy entire codebases into project trees. In these cases, you miss out on provenance and version information and have no update trail.
• System-level dependencies:  Developers sometimes rely on OS-installed libraries, which are external to a repo and easy to miss.
• Git Submodules: Git Submodules allow you to embed one repository within another, creating a nested structure of dependencies. While this provides some level of dependency management, it’s notoriously difficult to work with and is often considered “the best bad solution” by developers. The reliance on commit hashes and inconsistent versioning makes it difficult to reliably map dependencies to CVEs. For example, a submodule version could be “1.2.3” or “v1.2.3” or “tag_name,” which means there is no guarantee you are pulling in the correct information.
• Build system integration: Build systems like Ninja, CMake, and Bazel all have independent ways of creating a notion of dependencies and what needs to be built within a build system. However, it is very open to interpretation of whoever is creating that build system.
• Dynamic dependency acquisition: Perhaps most challenging are dependencies that don’t exist in your source code at all. Some build systems fetch files directly from the web during compilation using tools like wget or curl. These dependencies are invisible until build time.

These challenges result in manual dependency tracking and versioning difficulties, creating security concerns when dependencies are overlooked or forgotten. If your SBOM generator can’t capture these dependencies, you lose visibility into their codebase composition, making it nearly impossible to accurately identify and address security vulnerabilities.

Examples from the Wild West

Git Submodules: Popular, but Poorly Versioned

Despite being widely disliked, Git Submodules are one of the most popular dependency management approaches in C/C++. They provide a way to embed external repositories while maintaining some level of version control.

The challenge with submodules is that they frequently reference Git commit hashes rather than semantic versions. Instead of depending on “library v1.2.0,” you’re depending on commit hash ‘a1b2c3d4’ versus the traditional semantic versioning approach. This makes it difficult to map dependencies to Common Platform Enumeration (CPE) identifiers or vulnerability databases that expect product versions, not version control hashes.

Despite this limitation, Git Submodules are probably one of the easiest dependency approaches to work with from an SBOM perspective, which says something about how challenging the alternatives can be.

SBOM Challenge: Git commit hashes don’t map to CVE databases.
Result: Even if a tool includes the submodule in your SBOM, it won’t be able to determine if it’s vulnerable.

OpenCV: The Third-Party Directory Approach

OpenCV, one of the most popular computer vision libraries, exemplifies the challenges of C/C++ dependency management. OpenCV’s build tree includes a “3rdparty/” directory full of other open source libraries. These are copied into the codebase at a specific moment in time, without any version tracking or external linkage. 

Here’s an actual SBOM entry for a file embedded via OpenCV: 

 {
      "name": "predictor_enc.c",
      "authors": [
        {
          "name": "Google Inc"
        }
      ],
      <... cut by me for space in message ...>
      "copyright": "Copyright 2016 Google Inc",
      "properties": [
        {
          "name": "filePath",
          "value": "/plugfest/opencv/3rdparty/libwebp/src/enc/predictor_enc.c"
        }
      ]
    },

Upon investigating the repository, you can confirm the “3rdparty/” dependencies are manually included instead of through git submodules or cmake’s built-in `FetchContent` behavior.. As a result, this open source software would be missed and not reported on as a dependency.

SBOM Challenge: No traceable source, version, or update mechanism.

Result: Traditional SBOM tools miss these entirely because they look for package manifests not files buried in a subdirectory.

Mongoose Web Server: Official Copy-Paste Integration

Mongoose, a popular embedded web server, takes an even more direct approach. Their official documentation instructs users to copy exactly two files—mongoose.c and mongoose.h—anywhere in their codebase.

This approach creates several challenges:

• Invisible dependencies: The files might be placed in any directory, making them nearly impossible to detect without examining the actual build process
• Security risk: Updates require manual file replacement, and there’s no automatic way to know when updates are available
• No provenance: Once copied, these files become indistinguishable from the rest of your codebase

SBOM Challenge: Completely invisible unless you trace every file.
Result: These dependencies blend in with the rest of your source tree. Unless your SBOM tool analyzes each compiled file and scans license headers, you’ll miss them completely.

SQLite: Build-Time Fetching from the Web

SQLite demonstrates the most invisible form of dependency management. Some build systems will fetch SQLite source code directly from the web during compilation using commands like wget or curl. This dependency exists nowhere in your source code as it only appears during the build process.

SBOM Challenge: Only exists at compile time.
Result: A static SBOM generator has no way to know the file was downloaded unless it observes the build process in real time.

Why Build-Time SBOMs Are Essential

These real-world examples illustrate why traditional package-based SBOM generation fails for C/C++. When dependencies can be copied directly into source trees, embedded as Git Submodules, fetched dynamically during builds, or integrated through copy-paste instructions, they are all too easy to miss.

To overcome these challenges, SBOM tools must watch the build process itself and not just analyze the source code or look for packages. A file-based, build-time SBOM generator tracks every file that is compiled, linked, or fetched, and extracts metadata like:

• Provenance information from license headers and copyright notices in source files. This is information that most open source projects include and that meets minimum SBOM requirements.
• All included dependencies regardless of how they were integrated into the project.
• Build-specific dependencies that vary based on compile-time configuration. It will show only what’s actually used rather than what’s available.
• Dynamically fetched components that don’t exist in source code but are pulled during the build process.

Every file used in a build gets recorded, providing visibility into the actual composition of software. That visibility leads to better vulnerability identification, less software supply chain risk, and compliance with SBOM regulations.

Working With C/C++, Not Against It

Having built a C/C++-specific SBOM generator at RunSafe, I’ve learned that you can’t force C/C++ dependency management into the expected package manager approach. And you shouldn’t try.

C/C++ development is complex and full of legacy habits that defy modern package management. What we need are tools that support the embedded C/C++ world. When we try to force this rich, complex, legacy ecosystem into modern packaging paradigms, we lose a lot of critical information. RunSafe’s build-time, file-based approach aims to capture that missing information.

The Wild West of C/C++ development isn’t going away. But with the right tools and approaches, we can bring order to the chaos without losing the flexibility that makes C/C++ so powerful in the first place.

What unconventional build systems have you encountered in your C/C++ projects? Share your stories. The more we understand the chaos, the better we can support accurate, secure, and compliant SBOM generation.

What Are SBOM Minimum Elements?

An SBOM is an ingredients list for software. To be useful, every SBOM must include certain key data fields, or the minimum elements.

In 2021, the NTIA’s list was a good starting point, but as software development has evolved, it is now far too basic: name, version, identifier, timestamp. 

To reflect the reality of software development today, the 2025 draft adds fields like:

• License: Critical for compliance and security obligations
• Component hash: Cryptographic accuracy, pushing toward automation
• Generation context: Identifying whether an SBOM was created at source, build, or binary stage
• Dependency relationships: Clarifying how components connect

The updates reflect how organizations are actually using SBOMs today to manage software supply chain risk.

Why the New SBOM Minimum Elements Guidance Matters

From “Check-the-Box” to Automation

The 2021 requirements made it possible to deliver a barebones SBOM with nothing more than an Excel spreadsheet. Those quickly went stale and carried little value. The new requirements—particularly hashes, license data, and generation context—make that shortcut nearly impossible, forcing a move toward automated SBOM generation.

As Kelli explained: “By requiring more fields—hashes, authorship, generation context—CISA is making it almost impossible to get by with an outdated Excel spreadsheet. These new elements push the industry toward automated, accurate SBOM generation, which is the only way to keep pace with today’s threat environment.”

Licensing Finally Gets Its Due

License information is now a minimum requirement. Licensing is a compliance issue, but license restrictions can directly impact how software can be used or redistributed. By including it, CISA and DHS are addressing a real-world gap that often goes unnoticed until it becomes a legal or operational problem.

“Licensing impacts how organizations use and share software,” Kelli said. “Ignoring it in SBOMs left a blind spot in the software supply chain, and closing that gap is long overdue.”

Generation Context Raises the Quality Bar

Including generation context—stating where in the lifecycle the SBOM was created—is a small addition with outsized impact. For example, “Build-time SBOMs give the clearest and most accurate view of software,” Kelli said. “This requirement could pressure suppliers to deliver them, raising the quality bar across the ecosystem.”

By making generation context mandatory, the draft puts pressure on suppliers to produce higher-quality SBOMs and discourages binary-only or “black box” approaches.

Compare SBOM generation approaches.

RunSafe’s Perspective

RunSafe sees the 2025 SBOM minimum elements as a much-needed course correction. They reflect four years of learning, discourage paper-thin compliance practices, and push the industry toward automated, accurate, and timely SBOMs.

But gaps remain, especially for embedded systems. Most federal guidance still implicitly equates “software component” with “package.” For modern applications built with package managers, that’s fine. For embedded devices, it’s a problem.

“Most federal guidance still assumes software components come neatly packaged, but embedded software in C and C++ rarely works that way,” Kelli said. “File-level SBOMs are harder to generate, but they’re also where you get the most precise vulnerability data.”

That precision matters most in embedded systems—the software inside medical devices, critical infrastructure, and defense technology—where false positives waste time and false negatives risk lives. 

“If we don’t account for embedded use cases, we risk leaving out some of the most critical systems,” Kelii said.

RunSafe believes the draft’s generalized fields are a step in the right direction, but federal guidance should go further. It should explicitly recognize that SBOMs can be generated at the file level, not just at the package level, and that embedded contexts demand this granularity.

Raising the Bar for Software Supply Chain Security

The 2025 SBOM minimum elements draft is a milestone. It raises expectations, improves accuracy, and pressures suppliers to move beyond token compliance. That’s progress.

But for SBOMs to fulfill their promise across the entire software ecosystem, we must ensure embedded systems are not left behind. File-level SBOMs are essential for securing the most critical software our society relies on.

At RunSafe, we applaud the direction of the new guidance and will continue to advocate for embedded-first thinking in SBOM guidance. The security of the software supply chain depends on it.

Learn more about RunSafe’s approach to SBOM generation and software supply chain security. Download our white paper or view our SBOM tool comparison.

Source Code SBOMs: A Static View with Broad Coverage

Source code-based SBOMs are generated by analyzing a software’s source tree for a specific target, offering a comprehensive view of the components involved in the development process. This method has several notable advantages. 

First, it provides complete visibility into the source code, ensuring a thorough inventory of all potential components that could be included in the software. It also offers direct access to valuable metadata, such as licensing and copyright information, which is critical for compliance and legal requirements. Additionally, analyzing source code is less computationally intensive than its more involved build-time SBOM counterpart, as it involves simpler, less resource-demanding operations.

However, the source code-based approach comes with its own set of challenges. A key issue lies in the complexity of build configurations. Since this method examines the source tree rather than the final software build, it may fail to accurately reflect the configurations used to generate the actual binaries. This misalignment can result in discrepancies between the SBOM and the final product. Conditional compilation further complicates matters, as accounting for different compilation paths in large, complex codebases with multiple configurations can be particularly challenging.

Another limitation is its inability to capture runtime dependencies—external components that are dynamically fetched during the software’s operation. Consequently, source code-based SBOMs often over-report, including components that may not make it into the final binary and creating unnecessary noise. This can lead to false positives, where components that are in the source code are flagged even though they will not be in the final build and so do not present any business risk.

Key takeaway: Source code-based SBOMs provide greater visibility into all components of a codebase, making them valuable for compliance, licensing, and early development analysis. However, they still miss out on providing the complete picture of the final product and have a strong chance of false positives by not accounting for build configurations and runtime dependencies.

Build-Time SBOMs: The Complete Picture

Build-time SBOMs are considered the most accurate and efficient method for tracking software components because they are generated during the compilation process, providing a detailed and reliable view of all the components included in the final software build.

Build-time SBOMs execute against the precise components that will be in the build and only contain the relevant libraries and the specific sub-components used in said libraries during the building of the compiled output. Build-time SBOMs are also able to capture all external or linked resources that are only included at build time.

The precision of build-time SBOMs reduces alert fatigue and saves engineering teams time by minimizing false positives and eliminating the need to investigate reported vulnerabilities on components that will not be in the final build and that do not present a risk to production.

When implementing build-time SBOMs, look for solutions that easily integrate into your CI/CD pipeline and existing development workflows. For them to be useful, they must fit smoothly into automated workflows without adding extra complexity or causing delays. Also consider performance. Build-time SBOMs increase accuracy, but should not come at the cost of slowing down build times significantly.

Key takeaway: Build-time SBOMs offer the most precise and comprehensive tracking of software components, making them essential for strengthening software supply chain security and minimizing false positives. They can also be created for legacy software where the source code is readily available. To maximize their impact, choose solutions that seamlessly integrate into your CI/CD pipeline.