12 questions to ask a supply chain security vendor about itself

Ask a supply chain security vendor how it protects its own supply chain: whether it can hand you an SBOM and a signed attestation, how it handles a vulnerability in its own product, what data it takes from you, and which features are generally available versus early access. These twelve questions expose gaps fast.

This is a different list from a product feature checklist. A tool that scans your dependencies is also a dependency of yours, with deep access to your code and pipelines. Treat it like any other vendor with that access.

What should the vendor show about its own software?

1. Can you give me an SBOM for your product? CISA describes an SBOM as a nested inventory of the components that make up software. A vendor selling SBOM tooling should be able to produce one for its CLI, agent or plugin.
2. Do you complete the secure software development attestation? CISA's form is based on NIST SP 800-218, the Secure Software Development Framework. Ask whether they have filled it in, who signed it, and for which products.
3. What build provenance do you publish? SLSA describes build levels, from provenance that exists to hardened build platforms. Ask which level they claim for the artifacts you will install, and ask to see the evidence rather than the slide.
4. How do I verify what I installed? Look for checksums, signatures and pinned versions. A vendor that says "pipe this script to bash" should at least offer a way to check it.

What should the vendor say about vulnerabilities in its own product?

5. Where do you publish advisories, and how fast do you fix? Look for a real security page and past entries. An empty page is a data point too.
6. Do you issue VEX statements? CISA frames VEX as a statement that a product is or is not affected by a vulnerability. Ask if they can tell you when a library CVE does not affect their product.
7. What happens when one of your dependencies is compromised? Ask for a concrete runbook, not a principle.

What should the vendor say about your data?

8. What leaves my environment? The honest answers are specific: source, manifests, metadata, results. Ask whether a mode exists where source stays local.
9. Can I turn off AI features, or bring my own model? If the product uses language models, ask which data goes to which provider and whether you can switch it off.
10. Who are the sub-processors, and where is data stored? Put the list in the contract.

What should the vendor say about its maturity?

11. Which certifications and attestations do you hold today, and which are in progress? Ask for the report or letter. "In progress" is an acceptable answer if it is stated plainly. "Compliant" with no document is not.
12. Which listed features are generally available, which are early access, and which are roadmap? Ask for the label per feature, in writing, and hold the vendor to it at renewal.

How should you score the answers?

Treat specific, checkable answers as good and vague ones as a warning. A vendor that says "we do not do that yet" has told you something useful. A vendor that cannot answer question 8 in one sentence has told you something else. Weight data handling and maturity labels highest if you are regulated.

What are the limits of this list?

Answers are claims until you verify them. A signed attestation is a statement by the vendor, and CISA's own materials describe agencies choosing whether to use the form. Verification means asking for artifacts and, for critical vendors, a technical review. These questions also say nothing about price or fit.

What to do

1. Send the twelve questions in writing before the demo.
2. Ask for artifacts for questions 1, 2, 3 and 11.
3. Put data handling and feature maturity labels into the order form.
4. Run the vendor's installer in a sandbox before you give it production access.
5. Calendar a re-check at renewal, since answers change.

Quick check

Sources

• CISA, Software Bill of Materials (SBOM) and VEX
• CISA, Secure Software Development Attestation Form
• NIST SP 800-218, Secure Software Development Framework
• SLSA, security levels

Last reviewed: 18 October 2026.