Build a software bill of materials before buying source code

For software bill of materials, the first decision is whether one small example can be reviewed by a person. A source-code listing can describe the finished app without showing which outside components it depends on. Before buying, use the public sample to map component names, versions, and recorded sources. That gives you a concrete starting point for review—and a clear list of what the sample leaves unanswered.

Find the declarations: identify files that describe outside dependencies.
Record the evidence: separate requested versions from resolved versions and copy source details where available.
Keep the boundary: a component inventory supports further review; it does not establish safety.

This is a playbook for preparing a software bill of materials, or SBOM, from an available sample. Think of the result as a preliminary component map, not a certification.

Prepared: 2026-09-10. Tested date: unavailable. No sample files, dependency output, or completed inspection results were supplied for this article. The worksheet below is reusable; it is not evidence that a particular package passed review.

Start with the sample’s boundaries

Before collecting component names, write down what you actually have.

A public sample might contain a complete application, a demonstration, or selected files. Those are different inspection conditions. Without a statement connecting the sample to the paid release, its dependency list describes the sample alone.

Record the sample location, its release label if available, and any accompanying description of its scope. Keep the paid package’s advertised release separate until the seller establishes the relationship.

For a fictional convenience-store deals app, a preview might show the browsing interface while omitting an administrative area. The interface’s component list would not tell you what the omitted area needs. This is an illustrative boundary, not an observed finding.

Use explicit language in your notes:

Scope: public sample only. Correspondence with the paid package has not been established.

That sentence prevents a partial inspection from becoming a claim about the whole product.

Read declarations before running anything

Begin with the files as text. Installation is a separate action, and it is not necessary merely to transcribe declared components.

Look for a dependency manifest: a file describing packages the project requests. Then look for a lockfile, which may record resolved versions and additional dependency details. Also check whether separate application folders have their own declarations.

A requested version and a resolved version answer different questions. The declaration describes what the project allows or requests. A resolved entry describes a selected component version recorded in that dependency state.

Preserve both when available. Do not turn a version range into an exact version because an inventory looks tidier that way.

Treat missing information consistently:

• Absent from inspected files: you looked in the stated scope and did not find it.
• Not inspected: the relevant material has not been reviewed.
• Not supplied: the material was unavailable.

These labels describe your evidence. None means “safe,” “unnecessary,” or “does not exist.”

A useful component map preserves uncertainty instead of filling empty cells with confidence.

Give every row a traceable source

Build the map around component identity, version, and origin. Add enough context that another reader can trace each entry back to the sample.

Field	What to record
Component name	Exact identifier as written
Requested version	Original declaration, including any range
Resolved version	Exact recorded resolution, when available
Recorded source	Registry location, repository reference, archive, or local path
Relationship	Direct declaration or dependency of another component
Declared role	Runtime, development, optional, or unspecified
Evidence location	File and entry supporting the row
Open question	Missing detail or unresolved discrepancy

Copy identifiers exactly. Similar names are not interchangeable.

For the source field, preserve what the file actually contains. A homepage is not necessarily the location from which the component is obtained. A repository reference without an immutable revision also leaves a different question from a reference tied to a specific revision.

If the source is not recorded, write that down. Do not reconstruct it from the package name and present the reconstruction as observed evidence.

If an integrity value appears, preserve it separately. It can support a later artifact comparison; it does not establish that the artifact’s behavior is acceptable.

Follow the relationships beyond the first list

A manifest can show components the project declares directly. Those components may depend on others.

Where the available files describe those relationships, carry them into the map. Record which parent introduced a component rather than flattening everything into an unexplained list.

Do not silently merge entries that share a name but have different resolved versions or sources. Keep the distinctions visible until their relationship is understood.

Also separate declared role from observed use. A development label is a declaration, not a completed assessment of what executes during installation, building, or deployment.

This is where the map becomes useful for code review. It gives the reviewer specific questions: where is this component imported, what invokes it, and does the delivered application need it?

Those questions remain questions until the relevant code and behavior are examined.

Keep the receipts beside the conclusion

The receipt for an inventory entry is the file entry supporting it. Save the inspected material with the worksheet so a later change does not erase the basis of your notes.

A practical evidence chain looks like this:

Inspection scope → file entry → component-map row → unresolved question → review decision

An exported dependency report can be helpful, but preserve its scope and generation conditions. A polished report without its source context is harder to check.

Artifact caption: Component inventory worksheet showing requested versions, resolved versions, recorded origins, and evidence locations. Blank fields remain explicitly unresolved.

For this article, no populated inventory is available. There is therefore no verified component count, discrepancy, or successful inspection to report.

The list cannot answer the safety question

A component map tells you what the inspected material declares or records. It does not establish that the software is secure, correctly configured, or suitable for your use.

It also cannot establish everything the application might retrieve or contact while running. Downloaded assets, external services, bundled code, and deployment-specific additions may require separate inspection.

License information deserves its own evidence trail. A label in metadata is a starting point for review, not proof that every included file has matching terms.

No failed inspection was supplied here. The following are procedural failure modes, not reported incidents:

• Calling a sample inventory the paid product’s complete inventory.
• Recording a requested range as an installed version.
• Treating an unrecorded source as a verified origin.
• Calling a populated worksheet a security assessment.

The inventory makes the next review more precise; it does not replace that review.

Make the purchase decision around what remains unknown

Use the map to decide whether you have enough information to continue evaluating the source package.

A traceable sample inventory can support further review when its relationship to the paid release is clear. An unexplained gap calls for a specific request: the missing declaration, the matching lockfile, or clarification of the delivered release.

The final decision should describe the evidence boundary, not assign a safety badge.

Use this reusable handoff checklist:

• Inspection scope and sample identity recorded.
• Relationship to the paid release documented or unresolved.
• Available manifests and lockfiles identified.
• Requested and resolved versions kept separate.
• Recorded sources copied without inference.
• Dependency relationships and evidence locations preserved.
• Missing information labelled explicitly.
• Code, behavior, and licensing questions carried forward.

Before committing to a source package, fill this worksheet from its free sample and use the unresolved entries to frame your questions to the seller.

Related build logs

• Build on Free Data, and the Bill Comes in ‘Time’ Instead of Money
• Check AI summary coverage before trusting the appendix