A first customer questionnaire usually asks five supply chain things: what third-party code you ship, how you find known vulnerabilities in it, how fast you fix them, who can change your build, and who else touches customer data. Prepare one honest paragraph and one piece of evidence for each.
Why these questions show up first
Buyers cannot inspect your code, so they ask how you manage what you did not write. For a SaaS or ecommerce startup that is mostly open source packages, build tooling, container images and a few outside services. Reviewers know small teams will not have a large program. They are checking that you know what you run and that someone owns it.
The five questions and what they test
| Question you will see | What the reviewer is testing | Evidence that helps |
|---|---|---|
| Do you keep an inventory of third-party components? | Do you know what is in the product? | A dependency list or SBOM export |
| How do you detect known vulnerabilities? | Is checking routine or ad hoc? | Scan configuration and a recent report |
| What is your remediation timeline? | Is there a rule, and do you follow it? | A short written policy and a few closed tickets |
| Who can change production code and builds? | Can one account push anything? | Branch protection and review settings |
| Which vendors and subprocessors handle our data? | Do you track outside dependencies? | A dated vendor list |
Step by step: prepare your first answers
- Export a current dependency list for each production repository. Note the date.
- Run a vulnerability scan against that list and keep the report. Do not hide findings; reviewers trust a report that shows open items with owners.
- Write a three line patching rule. Choose targets you already meet, such as how long you take to act on a severity you rate critical.
- Screenshot or export your branch protection and review settings for the main branch.
- List your vendors in one table: name, what data they see, why you use them.
- Store all five in one folder so the next questionnaire takes minutes.
How to word the answers
Describe what you do now, in the present tense, with a date. "We generate a dependency inventory for each production repository on every release" is better than "we follow industry standards". If something is planned, say it is planned and give a quarter, not a promise of completion.
Avoid absolutes. "We have no vulnerable dependencies" will be false next week. "We scan on every pull request and review results weekly" can stay true.
For background on why teams record dependencies in a standard form, the CISA SBOM page describes an SBOM as a nested inventory of the ingredients that make up software components.
Try it yourself
Open the dependency inventory demo and look at how a single project expands into direct and transitive packages. Notice how many packages you never chose by name, since those are the ones a reviewer will ask about.
Click through it at your own pace, or open it full screen.
Safeguard can generate the dependency inventory and run dependency scanning, and you can try a free scan at https://gold.safeguard.sh/scan before you answer anything.
Quick check
Do we need an SBOM before the first questionnaire?
Not always, but a dependency list with a date is the easiest evidence to produce, and many questionnaires ask for one directly.
Should we show open vulnerabilities in the report?
Yes, with owners and target dates. A report with every item hidden looks less credible than one with a managed backlog.
Can we answer "not yet" to a question?
Yes. A plain "not yet, planned for next quarter" is safer than a stretched answer you cannot back up.
Sources
Last reviewed: 19 October 2026.
