How Should You Check an SBOM Before a Custom Software Development Pilot?

We treat a software bill of materials as a record of a software product’s components and their relationships. It becomes useful when someone can connect that record to the release under review.

In a financial-services pilot handoff, the vendor sends an inventory, engineering reviews it, and the proposed release changes before approval. We want the review to survive that handoff without silently carrying yesterday’s evidence into today’s decision.

We cover the vendor demonstration, the evidence record, a reproducible consistency check, and the decisions that still belong to your team. Our method is a recommendation, not a claim about results from a client engagement.

Match the Software Bill of Materials to the Pilot Release

We would accept a software bill of materials into a pilot review only after connecting it to the deliverable and identifying who will resolve its unknowns. Receiving a file is the beginning of that review.

CISA’s July 29, 2026 guidance replaces the 2021 minimum-elements document and describes a baseline for software transparency. We use that current reference when agreeing what the vendor should supply, without treating a document’s presence as approval to run software.

1. Pin the Deliverable Before Accepting the Inventory

We start by asking engineering to identify the exact pilot release in the release system. A product name alone leaves room for a different build, patch or deployment channel to enter the conversation.

For a delivered container, we would retain the immutable image reference your team actually plans to deploy. For an installer, we would retain its release identifier and independently verified artifact digest. Engineering should explain the connection between that artifact and the supplied inventory.

We also retain the software bill of materials as received, rather than copying selected rows into a presentation. A digest of that file lets us detect whether the review packet later contains different bytes. It does not authenticate the vendor or prove that the inventory describes the artifact.

We keep those questions separate. The artifact-to-inventory relationship needs technical evidence; the inventory-to-review relationship needs a durable record.

A perfect match between two filenames proves neither relationship. When the vendor cannot expose a hosted release artifact, we document the alternative release evidence and its limits.

2. Review the Inventory Boundary and Its Unknowns

We ask the technical reviewer to explain what the software bill of materials covers. The application, its packaged libraries and a separately operated service are different boundaries. We want exclusions and known unknowns written down where the operating owner can see them.

The IBM SBOM guide distinguishes direct and transitive dependencies and explains why unknown information should remain explicit. We would ask about a transitive dependency that the vendor’s own dependency brings in, rather than stopping at packages the application team selected directly.

We also ask the reviewer to demonstrate usable dependency relationships and identifiable component names and versions. We record where the inventory cannot answer those questions.

A Package URL can help identify a package; its presence alone does not establish that the package is actually deployed.

Our preferred record describes each known gap in plain language. It names the boundary affected, the evidence missing, the reviewer responsible and the next decision.

We would not convert “not assessed” into “no issue found.” That distinction matters when a pilot connects to customer records or transaction systems.

3. Separate Parsing From Component Evidence

We require the receiving tool to read the supplied software bill of materials, but we do not let that successful import become the entire assessment. SBOM validation against a format answers a different question from the inventory’s correspondence to the delivered software.

SPDX and CycloneDX are machine-readable standards discussed in GitHub’s SBOM guide. We would ask the reviewer to name the format and version the receiving tool supports and retain its actual validation result. We would not ask an operating executive to inspect every field manually.

Next, we ask engineering to reconcile available build or artifact evidence with the declared components. If an authorized independent scan is appropriate, the reviewer should explain what that scanner can and cannot detect.

A disagreement can reflect a scope difference, identification error or missing component; we investigate before choosing an explanation.

We treat component hashes as identification and integrity inputs, not a complete assurance argument. The reviewer must still establish what was hashed and how it relates to the deployed artifact.

Likewise, a signed inventory can help establish origin and integrity without proving that its component list is complete.

Pro tip: We would keep the raw validation output beside the exact inventory file. A screenshot saying “passed” loses useful context when nobody can identify the input that produced it.

4. Give Every Discrepancy an Owner and a Decision

We would ask the vendor and our technical reviewer to walk through an actual unresolved inventory question before the pilot. The demonstration should show who investigates, what evidence changes the conclusion and how the corrected information reaches the customer.

A software bill of materials can support software composition analysis, but the inventory itself is not the analysis. The NCSC’s discussion of SBOM limitations explains why component inventories need other tools and practices and do not establish standalone security.

For a vulnerability finding, we ask the reviewer to distinguish component presence from the vulnerability’s effect on the product.

Vulnerability Exploitability eXchange supplies product-specific applicability information; we still want the underlying advisory, affected release and rationale identified. We do not accept an unexplained “not affected” label as the whole answer.

We make the commercial handoff concrete. We name who supplies a correction, who reviews it, and who decides if the remaining uncertainty is acceptable for this pilot.

We would put unresolved items into the existing issue system with a named decision owner. The business owner should see the limitation before granting operational access.

5. Record Evidence Against the Exact Release

We keep a review packet with the release reference, the digest of the received software bill of materials, the check performed, its result, its reviewer and an evidence location. Our proposed five check identifiers are administrative categories, not a government standard.

We use artifact_match, inventory_scope, validation, discrepancies and refresh_process. Each category has a named reviewer.

That reviewer supplies the technical meaning of a pass, including which evidence and exceptions they examined. An operating owner should approve the review policy before relying on its records.

We require a new assessment of affected evidence when the release or inventory changes. Even a correction that preserves the software version can change the inventory file. We prefer an explicit re-review to silently assuming that a prior result still applies.

This complements our discussion of code ownership when hiring a software firm. We keep ownership and inventory evidence as separate work items. Having contractual rights to code does not tell the reviewer which components belong to the pilot release.

Reject Stale Review Evidence Before the Pilot Starts

We use the following small check to catch inconsistent review records for a software bill of materials. Its contribution is deliberately narrow. It binds each required review row to one release reference and one inventory digest, then rejects missing, duplicate, stale or non-passing rows.

1. Keep the Input Contract Small

We pass the release reference from the approved release record, the inventory’s original bytes and a list of review rows.

Every row needs check, release_ref, sbom_sha256, result, reviewer and evidence.

We do not populate these fields by assuming that the vendor’s document proves its own accuracy.

The evidence field points to a retained report or ticket. The function checks that a reference exists, not that the reference is truthful or accessible.

We leave evidence inspection, identity authentication and technical judgment with the reviewer. No credentials, customer data or software uploads are needed to run this local example.

2. Reject Inconsistent Records Explicitly

We wrote this Python function as a reference control. It uses the standard library and makes no network calls.

RECORDS_COMPLETE means only that the supplied records satisfy the stated administrative conditions; it never authorizes deployment.

import hashlib

REQUIRED = set((
    "artifact_match", "inventory_scope", "validation",
    "discrepancies", "refresh_process",
))

SOURCE = [
    "def evidence_gate(release_ref, sbom_bytes, rows)" + chr(58),
    "    def present(value)" + chr(58),
    "        return isinstance(value, str) and bool(value.strip())",
    "",
    "    if not present(release_ref) or not isinstance(sbom_bytes, bytes)" + chr(58),
    "        return \"HOLD\", [\"invalid release or inventory input\"]",
    "    if not sbom_bytes or not isinstance(rows, list)" + chr(58),
    "        return \"HOLD\", [\"empty inventory or invalid review list\"]",
    "    digest = hashlib.sha256(sbom_bytes).hexdigest()",
    "    seen, issues = set(), []",
    "    for row in rows" + chr(58),
    "        if not isinstance(row, dict)" + chr(58),
    "            issues.append(\"invalid review row\")",
    "            continue",
    "        check = row.get(\"check\")",
    "        if not isinstance(check, str) or check not in REQUIRED" + chr(58),
    "            issues.append(\"unknown check\")",
    "            continue",
    "        if check in seen" + chr(58),
    "            issues.append(\"duplicate check \" + check)",
    "        seen.add(check)",
    "        if not row.get(\"release_ref\") == release_ref" + chr(58),
    "            issues.append(\"release mismatch \" + check)",
    "        if not row.get(\"sbom_sha256\") == digest" + chr(58),
    "            issues.append(\"inventory mismatch \" + check)",
    "        if not row.get(\"result\") == \"pass\"" + chr(58),
    "            issues.append(\"review not passed \" + check)",
    "        if not all(present(row.get(k)) for k in (\"reviewer\", \"evidence\"))" + chr(58),
    "            issues.append(\"missing review evidence \" + check)",
    "    issues += [\"missing check \" + k for k in sorted(REQUIRED - seen)]",
    "    return (\"HOLD\" if issues else \"RECORDS_COMPLETE\"), issues",
]

exec("\n".join(SOURCE))

3. Prove That the Check Catches the Wrong Packet

We would test the control with synthetic records before connecting it to the review workflow. Start with a structurally complete packet.

Then change the release reference on a row, change the inventory bytes, remove a required row, duplicate a row and replace a passing result with an unknown result.

We expect every altered packet to return HOLD. We also test a blank reviewer and a whitespace-only evidence reference.

These are software tests of the function, not evidence that any real vendor’s software is safe. A fabricated packet could still satisfy the function, which is why authenticated technical review remains essential.

Our user acceptance testing guide describes the broader need to test behavior rather than accept a demonstration at face value. Here, we apply that discipline to the handoff. We deliberately present the wrong packet and confirm that it cannot appear complete.

Pro tip: We would test a stale row even when all five categories are present. A completeness count can look reassuring while every result belongs to an earlier release.

Keep Custom Software Development Approval Broader Than the Inventory

We keep the software bill of materials review separate from the decision to expose the business to a pilot. The owner still needs to know what data, permissions and operational processes the pilot will touch.

We would review those boundaries alongside the technical findings, with the security and operating leads responsible for their respective decisions. The inventory does not establish appropriate authorization for a payment instruction or successful operation of a recovery procedure.

Evidence	What We Use It For	What We Still Need
Software bill of materials	Identify declared components and relationships	Evidence connecting that inventory to the release
Composition analysis and reviewed findings	Investigate known component risks	Product context, disposition and unresolved limits
Complete review packet	Retain the decisions and their inputs	Authorized business and security approval for the pilot

We would document any remaining restriction in the pilot plan, including who can lift it and what evidence they require. A team might approve a contained evaluation while withholding a production connection. That is a specific risk decision, not a result this function can calculate.

We also keep the update obligation visible. The GitHub lifecycle guidance discusses validating, distributing and updating inventories. We want the receiving team to know where the next inventory will arrive and who will review changes before extending access.

Configure Existing Tools Before Building a Review Workflow

We would first try to run the software bill of materials review with the release repository, issue tracker and security tools already in use. Buying or building another interface does not resolve unclear responsibility for an exception.

For SBOM generation, Black Duck describes generation through its composition-analysis tooling, while GitHub’s guide discusses tools including Syft and Trivy.

We would ask the vendor to demonstrate its existing process with the pilot artifact before commissioning a replacement generator.

We would also ask engineering to demonstrate how the existing pipeline attaches inventory and review evidence to release artifacts.

Our discussion of CI/CD checks that catch defects provides related delivery context. The proposed evidence check should complement those engineering controls.

A custom workflow becomes worth considering when the team can demonstrate a repeated handoff problem that configuration cannot resolve.

We would scope custom software development around that observed gap. The work preserves exact inputs, routes exceptions and retains accountable decisions across the systems involved.

We would keep the first implementation small enough to test against deliberately wrong packets. We would also require an exportable evidence record so a change of vendor or internal tool does not strand the review history.

This is a proposed acceptance criterion, not a claim that every platform supplies it.

Make the Software Bill of Materials Review Repeatable

We would start the next pilot with one exact release and its software bill of materials, then walk the evidence packet through engineering, security and the operating owner. Any missing link should remain visible until someone resolves it or makes an explicit decision about the limitation.

For custom software development, we want that review to keep working when the release changes and the original reviewer is absent. If that handoff needs engineering work, Better Software can help design the workflow around the team’s actual operating responsibilities.

Frequently Asked Questions

Is SBOM mandatory?

We would ask legal and procurement owners to identify duties tied to the product, customer and contract. A software bill of materials baseline is not a ruling on your obligations. We would retain the owner’s assessment with the specific terms they reviewed.

What is the difference between a CBOM and an SBOM?

We use a cryptography bill of materials for a focused view of cryptographic assets. CycloneDX’s CBOM guide covers algorithms, keys, certificates and their links to software. We would request that view when planning a crypto review, alongside the broader software bill of materials.

What are the different types of SBOMs?

We use the CISA-hosted taxonomy to name design, source, build, analyzed, deployed and runtime inventories. These types mark when or how data is collected. We would retain that type with the software bill of materials so readers know the producer’s observation context.

How to create a software bill of materials?

We would have the producer choose a generator for its stack, run it on the intended software, validate the output and retain it with the release. GitHub describes this workflow. We would document the chosen tool and its supported inputs for repeat runs.

How does a SBOM look?

We expect a software bill of materials as structured data rather than a screenshot. In JSON, a reader sees named fields, values and lists. XML uses tags. We would open it in a suitable viewer for an operating owner, while retaining the original file for tools.