Using SBOMs to Verify FIPS-Validated Cryptographic Modules in Federal Build Pipelines

Federal software teams operating under FIPS requirements face a verification problem that general vulnerability scanning does not solve. A build pipeline can produce a clean scan result while still shipping a binary that relies on an unvalidated cryptographic module. The issue is not always visible at the surface level. Libraries get statically linked, vendored copies get embedded in containers, and build toolchains can silently substitute one cryptographic implementation for another without generating an obvious artifact trail.

SBOM FIPS validation is the practice of using software bill of materials data to trace cryptographic dependencies back to their source, confirm their identity and version, and cross-check that identity against the NIST Cryptographic Module Validation Program records. Done correctly, it gives a program office documented evidence that the cryptographic components in a release artifact are the same components that received a FIPS 140 certificate. Done poorly, it creates a false sense of assurance that can survive an RMF review while leaving real gaps in the cryptographic trust boundary.

The challenge is that SBOMs were not designed specifically for cryptographic assurance. They capture component identity, version, and provenance. What they do not do automatically is distinguish between a FIPS-validated module operating within its validated boundary and a library that shares the same name but was compiled outside that boundary, linked in a way that breaks the validation, or replaced at build time by a vendored fork. Closing that gap requires deliberate workflow design, not just SBOM generation.

This article addresses how federal and defense software teams can build that workflow into their pipelines, what SBOM data actually reveals about cryptographic dependencies, where it falls short, and how to generate the kind of evidence that auditors and RMF stakeholders can act on.

What SBOM Data Reveals About Cryptographic Dependencies

A well-generated SBOM in CycloneDX or SPDX format captures component name, version, package URL, license, supplier, and in some cases hash values and dependency relationships. For cryptographic assurance purposes, the most useful fields are the package identifier, version string, and any available hash or checksum that can be tied back to a known-good artifact.

When a build produces an SBOM that lists OpenSSL 3.0.8 as a dependency, that entry tells you the library was detected. It does not tell you whether the binary was compiled with FIPS provider support enabled, whether the FIPS provider object was included in the build, or whether the application is configured to call the FIPS provider at runtime. All of those conditions matter for FIPS 140-3 compliance, and none of them are captured automatically in standard SBOM output.

What SBOM data does well is establish a baseline inventory. It surfaces the presence of cryptographic libraries that might otherwise be invisible to a program office, particularly in large codebases with transitive dependencies. A dependency three or four levels deep in a package graph can pull in a cryptographic library that no one on the development team consciously chose. SBOM generation at build time makes that dependency visible and creates a record that can be reviewed, compared against an approved list, and preserved as part of the release artifact trail.

For federal programs using a Software Bill of Materials (SBOM) as part of their supply chain risk management posture, the cryptographic dependency inventory is one of the most operationally significant outputs. It is also one of the most frequently underused. Teams generate the SBOM, store it, and move on without building any process to evaluate what the cryptographic entries actually mean in the context of FIPS requirements.

The FIPS Validation Boundary Problem

FIPS 140 validation is not a property of a library version. It is a property of a specific module, compiled in a specific way, operating within a defined boundary, on a defined set of platforms. The CMVP certificate specifies the exact conditions under which the validation applies. A library that shares a version number with a validated module is not automatically validated. The distinction matters enormously in practice.

Consider a scenario where a build pipeline pulls OpenSSL from a package repository. The version matches a CMVP certificate. But the package was compiled by the repository maintainer with different build flags than the validated build. The FIPS provider may not be present, or it may be present but not the validated binary. The SBOM entry looks correct. The version matches. The certificate exists. But the module in the binary is not the validated module.

This is the core problem with treating SBOM version matching as equivalent to FIPS validation confirmation. Version matching is a necessary starting point, not a sufficient conclusion. The validation boundary requires that the module be the specific compiled artifact that was tested, that it operate in the environment described in the security policy, and that the application invoke it in a way that stays within the boundary. None of those conditions can be confirmed from an SBOM entry alone.

Closing this gap requires treating the SBOM as the starting point of a verification workflow, not the end of it. The SBOM identifies candidate components. The verification workflow confirms that those components are the validated artifacts, operating within the validated boundary, in the target environment.

Static Linking, Vendored Crypto, and Container Layers

Three scenarios consistently create the most significant gaps in cryptographic dependency visibility: static linking, vendored cryptographic code, and container base image layers. Each one can introduce cryptographic components that are either invisible to SBOM generation tools or appear in the SBOM in a way that does not accurately reflect the actual binary content.

Static Linking

When a cryptographic library is statically linked into a binary, the library code becomes part of the binary itself. Depending on the SBOM generation tool and the build system, the statically linked library may or may not appear as a discrete component in the SBOM. Tools that analyze source manifests or build system metadata may capture it. Tools that analyze the compiled binary may detect it through symbol analysis or string matching, but this is less reliable and highly dependent on build optimization settings. If the static library is not captured in the SBOM, the cryptographic dependency is invisible to any downstream review process that relies on SBOM data.

Static linking also breaks the dynamic library update model. If a dynamically linked library receives a patch that maintains its FIPS validation, deployed binaries pick up the update automatically. Statically linked binaries do not. The cryptographic code is frozen at the version that was linked at build time, which means the binary must be rebuilt and redeployed to incorporate any update, including security patches that affect the validated module.

Vendored Cryptographic Code

Vendoring is the practice of copying a dependency’s source code directly into a project’s repository. It is common in Go projects and in environments where teams want to control their dependency graph. When cryptographic code is vendored, it may appear in the SBOM under the project’s own package identifier rather than as a discrete external dependency. The version information may reflect the project version rather than the cryptographic library version. This makes it difficult to correlate the SBOM entry with a CMVP certificate.

Vendored cryptographic code also creates a maintenance problem. Updates to the upstream library require a deliberate decision to update the vendored copy. In practice, vendored cryptographic libraries often lag behind the upstream by months or years, accumulating vulnerabilities and drifting further from any validated configuration.

Container Base Image Layers

Container images are built in layers. The base image typically includes an operating system and a set of system libraries, which often includes cryptographic libraries. Application-level SBOM generation tools that analyze the application layer may not scan the base image layers. The result is an SBOM that accurately reflects the application’s dependencies but is silent on the cryptographic libraries present in the base image, which are often the libraries that system calls and lower-level components actually use.

Full-image SBOM generation, which scans all layers of a container image, addresses this gap but introduces its own complexity. The resulting SBOM is larger and includes components that the application team did not choose and may not be responsible for maintaining. Ownership of those components, and the responsibility for verifying their FIPS status, needs to be clearly assigned before the SBOM can be used as a compliance artifact.

Cross-Checking SBOM Output Against CMVP Records

The NIST CMVP maintains a searchable database of validated cryptographic modules. Each certificate record includes the module name, version, validation date, status, tested platforms, and a link to the security policy document. The security policy is the authoritative source for understanding the validated boundary, including which algorithms are approved, which operational modes are covered, and which platforms and configurations were tested.

A practical cross-check workflow starts with the cryptographic component entries in the SBOM. For each entry, the team identifies the corresponding CMVP certificate by searching the database for the module name and version. If a certificate exists, the team retrieves the security policy and compares the tested platforms and configurations against the target deployment environment. If the deployment environment is not listed in the security policy, the validation does not apply to that deployment, regardless of what the SBOM says about the version.

The following table summarizes the key data points to collect and verify during this cross-check process.

Data Point	Source	What to Verify	Sufficient Alone
Component name and version	SBOM	Matches a CMVP certificate entry	No
CMVP certificate number and status	NIST CMVP database	Certificate is active, not historical or revoked	No
Security policy document	CMVP certificate record	Target platform and OS are listed as tested configurations	No
Build configuration record	CI/CD system or build manifest	Build flags and options match validated build configuration	No
Binary or artifact hash	Build output or artifact registry	Hash matches the validated module artifact where available	No
Runtime invocation evidence	Application configuration or test results	Application calls the FIPS provider or module, not a fallback path	No

No single data point in this table is sufficient on its own. The evidence package for an RMF assessor should include all of them, along with documentation of any exceptions and the approval authority for those exceptions. Teams that produce only an SBOM and a certificate number are providing a starting point, not a complete compliance artifact.

Enforcing Cryptographic Policy in CI/CD Pipelines

Policy enforcement at build time is more effective than post-deployment review because it stops unapproved cryptographic components before they reach a release artifact. The practical mechanism is a policy gate in the CI/CD pipeline that evaluates SBOM output against a maintained allowlist of approved cryptographic components and blocks the build if an unapproved component is detected.

Building this gate requires three things: a reliable SBOM generation step that runs as part of every build, a maintained allowlist that specifies approved cryptographic components by name, version, and where possible, hash, and a comparison step that evaluates the SBOM against the allowlist and produces a pass, fail, or exception-required result. The comparison step should be treated as a required gate, not an advisory check. A build that fails the cryptographic policy check should not proceed to artifact signing or deployment staging without an explicit exception approval.

The allowlist itself requires ongoing maintenance. CMVP certificates have expiration dates and can be moved to historical status. New versions of cryptographic libraries may receive new certificates while old versions lose active status. The allowlist needs to track these changes and be updated before builds that rely on updated components are approved. Assigning ownership of the allowlist to a specific role, whether a security engineer, an ISSO, or a designated cryptographic officer, is essential. Allowlists that are owned by everyone are maintained by no one.

Exception handling is the part of this workflow that most teams underdesign. Exceptions will occur. A dependency may pull in a cryptographic library that is not on the allowlist. A build environment may not support the validated version. A third-party component may include a vendored cryptographic implementation that cannot be easily replaced. Each exception needs a documented approval, a time limit, a remediation plan, and a record that can be produced for an assessor. An exception process that exists only in email threads or informal approvals will not survive an audit.

Common Mistakes

The most common mistake is treating SBOM generation as the end of the cryptographic verification process rather than the beginning. Teams generate an SBOM, confirm that a cryptographic library appears in the output, find a CMVP certificate number that matches the version, and consider the requirement satisfied. This conflates component identification with validation confirmation. The SBOM tells you what is present. It does not tell you whether what is present is operating within the validated boundary.

A related mistake is failing to account for the operational environment in the validation check. FIPS 140 certificates are issued for specific tested configurations. A certificate that covers Red Hat Enterprise Linux 8 on x86-64 does not automatically cover the same library running in an Alpine Linux container on ARM64. Teams that do not read the security policy document and compare it against their actual deployment environment may be relying on a certificate that does not apply to their configuration.

Ignoring transitive dependencies is another consistent gap. Teams review their direct cryptographic dependencies but do not trace the full dependency graph. A third-party library that handles authentication or data protection may pull in its own cryptographic implementation as a transitive dependency. That implementation may not be on the approved list and may not be visible without a full dependency graph analysis or a full-image SBOM scan.

Ownership gaps create sustained risk. When no one is specifically responsible for maintaining the cryptographic allowlist, reviewing SBOM output for cryptographic entries, or tracking CMVP certificate status, the process degrades quickly. Certificate status changes, new library versions are introduced, and exceptions accumulate without review. By the time an assessor asks for evidence, the gap between what the SBOM shows and what is actually validated can be significant.

Finally, teams frequently underestimate the documentation burden. An RMF assessor reviewing cryptographic module assurance needs more than a scan result. They need a traceable chain from the SBOM entry to the CMVP certificate to the security policy to the build configuration to the deployed artifact. Building that chain after the fact, from memory and scattered records, is far more difficult than preserving it as part of the build process from the start.

Recommended Federal Approach

Start with a current-state assessment of how cryptographic dependencies are currently managed across the build pipeline. Identify where cryptographic libraries enter the build, whether through direct dependencies, transitive dependencies, vendored code, or base image layers. Determine whether existing SBOM generation covers all of these entry points or only a subset. Document the gaps before designing controls.

Assign explicit ownership for cryptographic dependency management. This does not need to be a full-time role, but it needs to be a named responsibility. The owner is accountable for maintaining the approved cryptographic component allowlist, tracking CMVP certificate status, reviewing SBOM output for cryptographic entries, and managing the exception process. Without a named owner, these tasks fall through the cracks between development, security, and operations teams.

Build the SBOM generation step into the CI/CD pipeline as a required artifact, not an optional output. Configure the tool to scan the full build output, including container image layers where applicable. Store the SBOM alongside the build artifact in the artifact registry so that the SBOM and the artifact it describes are always paired and retrievable together.

Develop the approved cryptographic component allowlist by starting with the cryptographic libraries currently in use, tracing each to a CMVP certificate, reviewing the security policy for each certificate, and confirming that the tested configurations match the deployment environments in use. Where they do not match, treat the gap as an open finding and initiate either a remediation plan or a formal exception with documented approval authority.

Implement the policy gate in the CI/CD pipeline to compare SBOM output against the allowlist on every build. Configure the gate to block builds that include unapproved cryptographic components unless an active exception record exists. Route exception requests through a defined approval process that includes a security review, a time limit, and a remediation commitment.

For binary and container validation, supplement SBOM analysis with binary inspection tools that can detect statically linked libraries through symbol analysis. This is particularly important for compiled languages where static linking is common and SBOM generation tools may not capture all linked components. The binary inspection results should be reconciled against the SBOM before the release artifact is signed.

Preserve the complete evidence package for each release. This includes the SBOM, the CMVP certificate references and security policy documents for each cryptographic component, the build configuration records, the binary inspection results, and any exception approvals. Store these artifacts in a location accessible to the program’s ISSO and assessors. When an RMF review or audit occurs, the evidence should be retrievable without requiring the development team to reconstruct it from memory.

Review the allowlist and exception records on a defined schedule, at minimum quarterly, and before any major release. CMVP certificate status changes. New library versions are released. Exceptions accumulate. A quarterly review keeps the allowlist current and prevents exceptions from becoming permanent fixtures without anyone noticing.