Yes, for any tool that runs in your CI or on developer machines. A scanner is software with its own dependencies, and it often holds repository access. Ask for a machine readable SBOM for the components you install, plus the vendor's vulnerability disclosure policy and patch approach.
Why a security tool deserves the same scrutiny
Teams tend to trust security products by default. But an agent, CLI or CI action from a vendor runs with your tokens and reads your code. If one of its dependencies is compromised, that access is the prize. CISA's Secure by Demand guide tells buyers to ask whether a manufacturer can provide a machine readable SBOM listing all third party components, including open source.
What to request
| Item | Why |
|---|---|
| SBOM for each installable artifact | CLI, CI action, container image, IDE extension each differ |
| Format | A standard format such as CycloneDX or SPDX, so your tooling can read it |
| Version match | The SBOM should correspond to the exact release you install |
| Vulnerability disclosure policy | Shows how issues in the tool itself are handled |
| Patch communication | How you hear about security fixes and how quickly they ship |
For a hosted service you may not install anything. Then ask for a component summary or a statement of how the vendor tracks its own dependencies, and keep your expectations realistic: an SBOM for a service is less common than one for a binary.
How to read what comes back
- Check that it is complete enough to be useful: names, versions, and supplier information for components.
- Ask whether it was generated from the build or written by hand. Build generated is stronger.
- Run your own scan against it and note any known vulnerabilities. A finding is not automatically a problem, since the vulnerable code may not be reachable. Ask the vendor for its assessment, ideally as a VEX statement.
- Look at the update history. A tool that publishes a new SBOM per release is tracking itself.
You can read more on the vendor side in who owns SBOM and VEX requests.
Link it to secure development evidence
NIST's Secure Software Development Framework presents a shared vocabulary for purchasers and suppliers about secure development practices. Asking your AppSec vendor which SSDF practices it follows, and what evidence it holds, fits naturally beside the SBOM request. See SSDF or secure by design.
Try it yourself
The dependency inventory demo shows what a component list looks like and how each entry is checked. Imagine the same view for the scanner you are about to install.
Click through it at your own pace, or open it full screen.
Safeguard offers SBOM and dependency scanning, and a free scan is available at gold.safeguard.sh/scan.
Quick check
What if the vendor refuses to share an SBOM?
Ask for the reason and an alternative, such as a component summary under NDA. Note the refusal in your risk record and compare with other requirements.
Does an SBOM prove the tool is safe?
No. It is an inventory. It helps you check components and respond to new vulnerabilities, but it says nothing about how the tool behaves.
Sources
Last reviewed: 19 October 2026.
