Ask the vendor for an SBOM with component versions, check its date, and ask how often components are scanned and how quickly critical flaws are fixed. Vendors who keep parts current can answer these in plain terms. Vague answers are information too.
Why this is worth asking
Most software is assembled from many components, a lot of them open source. If a vendor does not keep those parts current, a flaw found in one can sit in the product you use for months. CISA's product security bad practices guidance flags releasing products that include open source components with critical vulnerabilities, defined as CVSS 9.0 or higher. It also covers managing open source dependencies, for example maintaining an SBOM and scanning components.
The seven questions
- Can you share an SBOM for the version we use, in a standard format?
- What date was it generated, and how often is it refreshed?
- How often do you scan components for known flaws?
- What do you do when a component has a critical vulnerability, and how long does it usually take?
- Do you ship components that are known to be exploited, and how do you check?
- How do you tell customers about security fixes?
- What is your support period for the version we run?
How to score the answers
| Answer type | What it suggests |
|---|---|
| Specific, with dates and a standard SBOM | A working routine |
| Specific process, no SBOM | A process exists, but you have less to check |
| A promise to look into it | Probably no routine yet |
| Refusal citing secrecy | A flag, since many buyers receive SBOMs under agreement |
| No reply | A flag |
What to look at in the SBOM itself
- Each component has a name and version.
- The SBOM matches the product version you actually run.
- The generation date is recent relative to the product release.
- Components with serious known flaws are either updated or explained.
CISA's 2026 minimum elements guidance, issued jointly with the NSA, the FBI and international partners, gives a baseline for what an SBOM should include, and replaces the 2021 NTIA minimum elements. CISA describes it as a baseline, not a complete standard.
What good habits look like from outside
- Regular releases with notes that mention security fixes.
- A public security page with dated entries.
- A named place to report problems.
- Clear end of support dates.
Where Safeguard fits
For teams that build software, this is the practice Safeguard supports. Dependency scanning and SBOMs keep the inventory, continuous monitoring flags new advisories, reachability analysis shows which flaws your code can reach, and policies and gates keep critical components out of releases. Fix PRs can be opened for review, with autonomous remediation off by default and every category on Manual. Start with the free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
See how a pull request is blocked when it adds a component that breaks the policy.
Quick check
Is an old component always a problem?
No. It matters if the old version has a known flaw that your use of it can trigger. Ask the vendor for that context.
What if the vendor will not share an SBOM?
Ask why and whether it can be shared under an agreement. Treat a flat refusal as a risk to weigh, not an automatic no.
Sources
Last reviewed: 19 October 2026.
