Do you maintain a software bill of materials (SBOM) for your product?

Supply chain questions have grown faster than any other section of the vendor questionnaire, and they are still asked inconsistently. In the same file you will find a row about your software dependencies, a row about your vendors' vendors, and occasionally a row about modern slavery. They are three different questions and answering all three with one paragraph about dependency scanning satisfies nobody. Read the neighbouring rows first and work out which one you are in.

For the software question, you are probably closer than you think. If your builds run from locked manifests and something scans your dependencies, you already hold the inventory. What you are missing is the artefact: a file, in CycloneDX or SPDX, generated as part of the build and kept with the release it describes. Most build systems produce one with a plugin and a line of pipeline config. Going from "we scan our dependencies" to "we generate an SBOM per release" is usually an afternoon, and it converts an UNSURE into a yes on every questionnaire you will ever fill in again.

Say when it is regenerated, not just that it exists. An SBOM is a statement about one build. The value to your customer is that when the next widely exploited library lands, they can ask whether you ship it and get an answer that day. So the answer that carries weight is per release, retained, and scanned continuously against new advisories. One generated by hand last spring does not do the thing the question is about.

For the vendor question, point at your third-party risk process. How you assess a supplier before onboarding, what you require of the ones who touch customer data, and how often you review them. If you already answered a vendor risk management row, keep this one consistent with it rather than writing a fresh version.

Transitive risk is the part reviewers actually worry about. They are asking because their own risk inherits through you: your subprocessors' subprocessors are, eventually, theirs. You are not expected to have audited four levels down. You are expected to know who your critical suppliers are, to have contractual terms that flow security requirements onward, and to be able to say what happens when one of them has an incident.

If you have no SBOM, do not overstate it. "We do not currently publish an SBOM. Dependencies are pinned and scanned on every build, and we are adding SBOM generation to the release pipeline this quarter" is an honest answer that shows the capability behind the missing document, and it reads far better than a yes you cannot produce when asked.