Source SBOMs vs. build and artifact SBOMs

You can generate an SBOM from your source code or from your built artifact, but they capture different information.

A source SBOM shows what's in your repository. An artifact SBOM shows what's in your compiled binary, container image, or package — what your customer actually receives. Your build process might exclude code paths, strip dependencies, or generate new components. The final artifact might also include operating-system packages, build-system components, or transitive dependencies that don't appear in source alone.

Most of the time, customers want to know what's in the delivered product, not what you wrote. But the most complete approach combines both. Build-time analysis captures declared dependencies and manifest information. Final-artifact analysis shows what actually got compiled in, including hidden or generated components. Scanning just the final product can miss build context and dependency metadata, and scanning just source can miss what the build process did.

VEX (Vulnerability Exploitability eXchange) 

When a CVE is published, it's easy to assume every component match is a critical vulnerability. VEX lets you understand and communicate the nuance.

You can tell your customers: "This vulnerable component is present in our software, but the vulnerable code path is not reachable in our product based on how we use it," or "Our product is affected, and here is our mitigation or remediation status." 

For example, say your library contains a vulnerability in a PDF parsing function. You include the library, but you never call that function because your software doesn't process PDFs. With VEX, you can document that the vulnerability doesn't affect your product, even though it's technically present. 

VEX is especially useful in mature supply chain security programs because it reduces false alarm fatigue and helps primes and government customers understand actual risk vs. component matches. Without VEX, every CVE match looks like a potential problem. With VEX, you and your customers get clarity around actual risk exposure.

What should a defense contractor SBOM include?

The exact requirements come from your contract or customer. At a minimum, however, a useful SBOM generally contains the following types of information:

• SBOM metadata: The file should identify the organization or individual that created the SBOM, when it was created, the tool used to generate it, and the context in which it was generated. For example, from source code, during a build, or by scanning a final artifact.
• The primary component: The SBOM should clearly identify the product, application, firmware image, container, or other software artifact that the document describes. Include its name, version, supplier or producer, and applicable identifiers.
• Component records: Each identified component should have a separate record containing its name, version, and supplier or producer when known. This inventory may include open-source packages, commercial libraries, operating-system packages, container base images, statically linked libraries, firmware components, and other software included in the delivered product.
• Unique software identifiers: Where available, include identifiers that allow tools to distinguish one package from another. Common examples include Package URLs (PURLs), Common Platform Enumerations (CPEs), Software Heritage identifiers, repository locations, container digests, and identifiers defined by the applicable SBOM format.
• Cryptographic hashes: A hash can help identify and verify the exact component or artifact represented in the SBOM. The record should identify both the hash value and the algorithm used to produce it, such as SHA-256.
• License information: Include the declared or concluded license for each component when known. Standard SPDX license identifiers improve consistency and make automated license analysis easier.
• Dependency relationships: The SBOM should explain how components relate to one another. For example, it may indicate that the primary product contains a library, that one package depends on another, or that a container uses a particular base image.
• Scope, coverage, and known unknowns: If the generator could not identify a component, supplier, version, relationship, or other required field, record that limitation rather than simply omitting it. A customer should be able to tell what the SBOM covers and where any gaps may remain.

Additional fields may be required for a particular program, including copyright information, file-level details, build information, pedigree, provenance, security advisories, or VEX data. When in doubt, follow the applicable contract, data-item description, technical specification, or customer instructions.

How to integrate SBOM generation into your release process

Not every defense contractor has the same infrastructure or tooling maturity. The approach that works for you depends on how your software development and release process is structured. 

Here are three common scenarios and how to implement SBOM generation in each.

You don't have a formal build pipeline

If you're not running automated builds:

1. Get a lightweight generator like Syft or cdxgen and scan the built artifact, not just the manifest.
2. Generate before release. Point it at your build output in the format your customer wants.
3. Keep it with the release. Store it in a controlled location. Only include it in delivery if your contract requires it or your customer has authorized it.
4. Regenerate for each release. Version 2.1 gets a new SBOM for 2.1. Keep history.

You have release builds but limited infrastructure

If you're running releases but don't have mature scanning:

1. Add generation to the release build. Integrate Syft, cdxgen, or similar into your release process. Generate in your required format.
2. Generate on release builds, not every commit. You don't need an SBOM for every development check-in. Generate them when you cut a release.
3. Scan for vulnerabilities and document your decisions. Use something like OWASP Dependency-Check or your vendor's scanning tool. Flag what you find and document what you accept and what you're fixing.
4. Store and deliver as required. Keep it with the release and deliver it when the contract requires it.

You have mature CI/CD

If you've got established pipelines and security practices:

1. Generate SBOMs with policy gates. Fail or warn the build if high-severity vulnerabilities show up, based on your tolerance.
2. Provide VEX data. Explain which vulnerabilities affect you and which don't.
3. Monitor continuously. Watch for new CVEs against your dependencies.
4. Keep an audit trail. Track who generated it, when, what tool, what gates were applied, what exceptions were approved.

SBOM best practices for delivery and maintenance

Generating the file is only one part of the process. These practices help ensure that the SBOM is useful, defensible, and handled correctly.

• Trace the requirement to its source: Determine whether the request comes from a solicitation, contract, statement of work, contract data requirements list (CDRL), subcontract, incorporated technical document, contract modification, or voluntary customer request.
• Confirm the required scope and depth: Agree on the products, versions, platforms, component depth, required fields, file format, specification version, serialization, validation rules, and update frequency before generating the deliverable.
• Separate the SBOM from related analyses: Confirm whether the customer also expects a vulnerability report, license analysis, VEX document, security advisory, or other deliverable. These may accompany an SBOM, but they are not automatically part of one.
• Control delivery and distribution: Confirm the approved delivery method, recipients, access controls, handling instructions, and any required markings. An SBOM is not automatically classified, CUI, or contractor-sensitive because it supports a defense contract, but its content and contractual context may require protection.
• Assign an owner: Give a specific person or role responsibility for generation, quality review, delivery, retention, vulnerability reassessment, and customer coordination.
• Maintain release-specific records: Retain the SBOM with the exact release it describes. Also preserve relevant scan results, validation results, exceptions, approvals, vulnerability assessments, and VEX or advisory records.
• Reassess supported releases: Compare retained SBOMs with newly disclosed vulnerability information. Generate a new SBOM when the software composition changes; update the vulnerability assessment or VEX information when the composition remains the same but security information changes.
• Review the process periodically: Tools and build environments change. Periodically confirm that the generator still detects the expected components, produces the required fields, and remains integrated with the authoritative release process.

Common SBOM mistakes to avoid

SBOM generation and delivery sound straightforward, but contractors often run into a few common problems. Most of these stem from either technical misunderstandings about what SBOMs capture, or from unclear communication about what's required. Here's what to watch out for.

Delivering an outdated SBOM for a current release: An SBOM generated for an earlier release does not describe your current release if the software composition has changed. Retain it as the historical record for that earlier version, and generate a new SBOM for the new release. For software you support long-term, continuously or periodically reassess retained SBOMs against new vulnerability information.

Scanning only manifest files: Manifest files alone may omit exact resolved versions, transitive dependencies, build-generated components, and operating-system packages. Scan the built artifact or resolved dependency tree.

Hiding vulnerable components: Don't remove or misrepresent components to hide risk. If your software has a vulnerable dependency, document it honestly. Follow the contract requirements and coordinate sensitive information with the right people.

Trusting your vendor to verify: You remain responsible for the accuracy of an SBOM you deliver. If an MSP or vendor generated it, verify it. Be ready to defend it.

Sending an unsolicited SBOM: Don't include it without authorization. Confirm what's required, how it should be marked, and where it goes.

Assuming all formats and tools are interchangeable: If your contract specifies a format, use a tool that produces it. Different customers have different requirements. Ask instead of guessing.

Get the defense contractor SBOM checklist

When someone asks you for an SBOM, the first step is clarifying what they need. We've created a downloadable checklist that walks you through exactly what to ask, when to generate, and how to maintain accuracy over time.

The checklist covers three phases: what to do before you generate to clarify requirements, how to execute generation correctly, and how to maintain the SBOM after delivery. It's designed to be a practical resource you can hand to your team or reference when a customer submits a new request.