Last updated: 2026-11-02
“Please provide a current software bill of materials for the product we are purchasing.”
The request reaches sales, then lands with engineering. Someone exports a dependency list. Before it goes back to the customer, there is a more useful question to answer: what does that file actually describe?
For a small SaaS team, a practical response is a machine-readable SBOM tied to an identifiable release, accompanied by a short explanation of its scope, known gaps and update process. Include a route for vulnerability questions. Agree any differences from the customer's requirements before presenting the package as complete.
An SBOM helps a customer understand your software's components. It does not prove that the product is vulnerability-free.
Start with the customer's acceptance criteria. Ask which product or deployment they mean, which format and specification version their system accepts, and whether they expect the current inventory, updates throughout the contract, or both.
For hosted SaaS, “current” needs a reference point. A production deployment can change between the date you generate the file and the date procurement reviews it. Identify the release and deployment snapshot rather than promising a permanently current attachment.
Also separate an SBOM request from requests for a vulnerability report, penetration-test report or security questionnaire. They answer different questions. If the customer asks for “an SBOM showing no vulnerabilities,” explain that you can provide component information and a separately dated vulnerability assessment.
Do not commit to a delivery date until engineering has checked coverage. A short confirmation of the proposed scope is more useful than an unexplained export sent to meet an arbitrary deadline.
A software bill of materials is a structured inventory of software components and their relationships. It can record identities, versions and supporting metadata so that people and tools can interpret what a product contains.
That inventory becomes useful security evidence when it feeds vulnerability investigation, patching and other operational processes. Generating the file alone does not establish that those processes work.
For example, Syft generates component inventories, while Grype can analyse an SBOM against known vulnerability information. A scan with no matches cannot establish the absence of unknown vulnerabilities, missing components or flaws outside that analysis.
The workflow below is a practical procurement approach. It is not a claim that every SaaS supplier has the same legal SBOM obligation. The technical advisory supporting this article provides non-mandatory guidance; contractual and regulatory requirements need their own assessment.
Start with one deployable product or service. In a larger SaaS platform, that might be an API container, a background worker or a browser application. If procurement requested the whole platform, explain that the first inventory covers only one part and agree how the remaining parts will be delivered.
Record the release or build identifier and the immutable artifact digest, where available. Keep the deployment mapping internally so you can determine which inventory describes the software a customer was actually using.
For a containerised API, decide whether your scope includes application packages, indirect dependencies pulled in by those packages, the language runtime and base-image operating-system packages. Check separately for browser bundles, sidecars and components added after the image is built. Do not assume one image scan covers them all.
A remote payment or email service also needs a clear boundary. You may be able to describe the integration without knowing that provider's internal software composition. Document such external service dependencies separately, or in supported service fields, and explain what remains outside your inventory.
The generation method matters. Syft uses different default catalogers for images and directories: image scans focus on installed packages, while directory scans can also collect declared dependencies. A repository scan and a final-image scan therefore need not produce identical results.
Build-only dependencies can still matter to supply-chain security. If they are outside the customer-facing runtime inventory, say so and retain an appropriate internal record.
Agree CycloneDX or SPDX, the specification version and the file encoding with the customer. “JSON” alone is insufficient: their importer needs to understand the schema inside it. Do not assume the newest specification is the version both sides support.
For a team delivering containers, Syft is one possible starting point. It supports container images, directories and archives, and can export CycloneDX and SPDX. Its default squashed-image scope represents the final filesystem; an all-layers scan also includes content from earlier layers, including files later deleted. Choose the scope deliberately and record it.
Use build-system or ecosystem-specific evidence to supplement the artifact scan where needed. Pin and record the generator version and configuration so a colleague can reproduce the process.
As a working cadence, generate an inventory for each release you deploy, including dependency and base-image rebuilds. Agree separately how customers receive updates: through a controlled portal, a release notification or another defined route. Keep historical release records instead of overwriting one file named “latest.”
A new vulnerability advisory can trigger reassessment of an unchanged release. That does not necessarily require changing its component inventory. Distinguish updates to the software from updates to what you know about its risk.
Assign one accountable owner, such as the engineering lead. Release engineering can run generation; security can review findings; the account owner can coordinate delivery. One named person should still be responsible for confirming that the package describes the agreed product.
Check syntax and content separately. A file that passes schema validation may still describe the wrong build. Compare selected components against build records and the deployed artifact. Investigate missing versions, unexpected components and absent relationships.
Do not turn an unknown into an empty field that looks like “none.” Record the limitation, its effect on coverage and who will investigate it.
The following is a human-readable illustration, not a complete or schema-valid SBOM. All product, organisation and component names are fictional; none represents Kooch or a client.
pkg:generic/example-request-parser@3.2.1.In an actual delivery, record the generator and its version, configuration, validation result and available component hashes too. Do not fabricate missing metadata to make an export look complete.
Decide both who can access the information and how much detail they receive. These are separate decisions.
Full detail: Provide the agreed machine-readable inventory, with access restricted if appropriate. A full SBOM does not have to be a public download.
Restricted detail: Provide a reduced inventory where disclosure constraints justify it and the customer accepts it. Identify the omissions and their consequences. Do not remove versions or dependencies silently, or present a filtered document as complete.
Summary only: Offer a description of scope, coverage and your response process during an initial review. A summary may support the conversation, but it does not replace a requested machine-readable SBOM unless procurement agrees.
Retain the original internally. Give any edited export its own identity and revalidate it; removing entries can leave broken references.
There are three separate licensing questions: the generator's licence, the licences of the components it identifies, and the terms applying to the SBOM data. Syft itself is Apache-2.0 licensed. That tells you neither whether every dependency is used correctly nor what confidentiality terms should govern the inventory.
A concrete format caveat matters here. The SPDX 2.3-series specification requires CC0-1.0 for SPDX metadata, and Syft's documented SPDX output includes that data-licence value. The specification also explicitly recognises contractual restrictions on releasing particular collections of SPDX documents and identifying their suppliers. Metadata licensing therefore should not be confused with an obligation to publish the inventory publicly.
Where confidentiality is material, have qualified counsel check the proposed sharing terms against the actual format, output and supplier restrictions. For hosted scanning or SBOM platforms, also check what is uploaded, who can access it, retention and customer-sharing rights. These depend on the chosen service and contract.
Give the customer a monitored contact or portal for reporting an SBOM discrepancy or vulnerability concern. Explain who triages it, how urgent issues escalate and how you communicate the next update. Promise only response times your team can support.
If you provide vulnerability results, date them and identify the scanner, database snapshot and any exclusions or suppressions. Grype can scan an existing SBOM; its results depend on the inventory and vulnerability information used.
When a customer flags a component, assess the affected product version and deployment before drawing a conclusion. Where supported, Vulnerability Exploitability eXchange, or VEX, can communicate product-specific status and justification. A “not affected” conclusion needs evidence; it is not a label to apply merely to reduce the finding count.
Keep responsibility visible while an issue is under investigation. The customer should know when to expect a further update even if a remediation date is not yet available.
The same operational question applies to incident signals: who receives them and who acts? Our article on five breach detection routes explores why those reporting paths matter.
For an initial procurement response, use this practical checklist alongside the customer's requirements. It is not a substitute for a specified contractual or regulatory SBOM profile.
Keep generation logs, configuration, validation evidence and detailed investigation records internally; share additional evidence when agreed and appropriate.
Your next step is to assign one owner and inventory one deployable product before responding to procurement. Then describe exactly what you can provide, what remains outside it and how you will keep it useful.
If this request exposes wider gaps in security ownership and evidence, explore Kooch's ISO 27001 readiness and ISMS support. Contact Kooch to discuss the processes and evidence your team needs to organise.
Reviewed on 2026-11-02.
