Treat a new commercial product like a delivery that needs inspecting. Verify the download against the vendor's published hash or signature, record the exact version, scan what ships inside, review default settings, and keep the evidence. Only then let it near production.
Why bother after a security review
A questionnaire tells you what the vendor says. Intake tells you what the vendor shipped. The two can differ, and the difference is where trouble hides. Intake is a short, repeatable step that costs an afternoon and often finds the one thing nobody asked about.
The checklist
1. Get it from the right place. Download only from the vendor's published channel, over HTTPS. Do not accept an installer from an email attachment or a shared drive unless the vendor confirms it out of band.
2. Verify integrity. Compare the file's hash with the one the vendor publishes, and check any signature. A hash on the same page as the download only proves the file was not corrupted in transit. A signature checked against a key you obtained separately says more. Our post on checksum versus signature explains the difference. Remember that a valid signature is not a guarantee of safety, as the 3CX signed installer case showed.
3. Record the exact version and build. Write down the version string, build number, source URL and date. You will need this when the next advisory arrives.
4. Collect the SBOM. Ask for a machine readable SBOM for this exact version. The NTIA minimum elements list the data fields to expect: supplier, component name, version, other unique identifiers, dependency relationship, author of the SBOM data and a timestamp. See what to check when an SBOM arrives.
5. Scan it. Scan the SBOM and, where possible, the installed files or container image for known vulnerabilities. Compare results with the vendor's own statements.
6. Review default settings. Look for default passwords, open management ports, debug modes and sample accounts. CISA's Secure by Demand guide asks whether default passwords are eliminated and recommends random, instance unique passwords in their place.
7. Check authentication options. Does the product support single sign on and multi factor authentication in the edition you bought? The same guide asks about both.
8. Check logging. Which events are logged, where, and for how long? The guide asks that security logs be part of the baseline product.
9. Read the outbound connections. List every address the product contacts. See our egress inventory guide.
Evidence to keep
A one page record per product: version, hash result, SBOM file, scan summary, default settings reviewed, owner and reviewer, date. This serves audits and future incident work.
When intake fails
If the hash does not match, stop and call the vendor. If a default account exists, close it or get a written fix date. If the scan shows serious known flaws in a brand new version, ask the vendor for a statement on each one. Do not accept "we will get to it" without a date.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how components are listed with versions, the same view you want for a vendor's product.
Safeguard offers SBOM and dependency scanning, container scanning and a free scan at gold.safeguard.sh/scan for this step.
Quick check
Is a vendor hash enough proof?
It shows the file matches what the vendor published. A signature checked with a separately obtained key adds more.
Do I need an SBOM for intake?
It makes the scan and later advisories far easier. Ask for one for your exact version.
Sources
Last reviewed: 19 October 2026.
