Treat a vendor update as an incoming release. Verify where it came from and its integrity hash, review its contents or SBOM, scan what you can, test it in staging and record the result before it reaches production. Your own release gate should apply to what you install, not only what you build.
Why intake needs a gate
Regulated teams often run strict gates on their own code and then install vendor updates on trust. But a vendor package becomes part of your production system the moment you deploy it. NIST SSDF practice PW.4.4 says to verify that acquired commercial, open-source and other third-party components comply with the organization's requirements throughout their life cycles. Its examples include regularly checking for publicly known vulnerabilities in modules that vendors have not yet fixed.
An intake checklist
- Source. Download from the vendor's official channel, over a secure connection.
- Integrity. Compare the published hash or signature with the file you received. SSDF PS.2.1 is about suppliers providing integrity verification information, so ask for it if absent.
- Contents. Ask for an SBOM. If none exists, scan the package with a dependency or binary scanner.
- Advisories. Check the vendor's release notes for security fixes and for known issues.
- Test. Install in staging, run your smoke tests and watch for unexpected network calls or new services.
- Decide. Apply your usual gate and waiver rules.
- Record. File the version, hash, scan result and approver in your change record.
What to do when the vendor gives you little
| Vendor provides | Your response |
|---|---|
| Hash and SBOM | Verify and scan |
| Hash only | Verify, scan the binary, test carefully |
| Nothing | Escalate, narrow the exposure, and document the risk |
Ask the vendor for more in the next contract cycle. Buyers have leverage at renewal.
Contain what you cannot verify
If you must deploy something opaque, limit what it can reach. Run it with least privilege, restrict outbound traffic and monitor it more closely than your own code.
Do not forget the speed of security updates
A vendor security update can be urgent. Keep a fast intake lane with the same steps in shorter form, so urgency does not mean skipping checks.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how an inventory of components makes an incoming package reviewable.
Safeguard provides SBOM and dependency scanning, and a free scan is at gold.safeguard.sh/scan.
Quick check
What if the vendor has no SBOM?
Scan the package yourself, test it in staging, restrict its access and ask the vendor to provide one.
Does a valid signature mean the update is safe?
It shows who published it and that it was not altered. It does not show the contents are free of vulnerabilities.
Sources
Last reviewed: 19 October 2026.
