Scanning vendor software you did not write (and cannot read)
You run large amounts of software you never reviewed, admitted on the strength of a vendor questionnaire. Delivered artifacts can be analyzed directly without source: component inventories from binaries and images, vulnerability matching, embedded secrets, and misconfigurations. Generate the SBOM yourself, monitor it over time, and turn vendor security conversations into evidence.
Somewhere in your environment right now runs an application your team has never analyzed, delivered by a vendor whose security assurance consists of a completed questionnaire and a certificate logo page. Regulators have stopped finding this acceptable, operational-resilience frameworks now make third-party software explicitly your responsibility, and, more to the point, attackers never found it acceptable in the first place: vendor software is a first-class initial-access vector.
The good news is that “we cannot audit what we did not write” is false. Delivered artifacts carry more analyzable truth than the questionnaire does.
What a binary will tell you that a vendor will not
Its real component inventory. Packages, images, and binaries can be decomposed into their constituent components: the OS packages in the image layers, the libraries statically or dynamically linked, the bundled runtimes. This produces an SBOM you generated yourself, which has a property no vendor attestation has: it describes what was actually shipped, not what someone remembered shipping. When the two disagree, and they do, you have learned something important about the vendor.
Its known vulnerabilities. That self-generated inventory matches against vulnerability data like any other, with exploitation-aware prioritization. The recurring discovery here is old, vulnerable components deep inside current vendor releases, because vendors inherit dependency debt exactly the way you do, and disclose it rather less.
Its embedded credentials. Secrets scanning applies to artifacts, not just repositories: hard-coded tokens, default keys, and connection strings baked into vendor packages are a depressingly reliable find, and they are as usable by attackers in vendor code as in yours.
Its configuration posture. Vendor container images run as root, expose debug ports, and carry permissive defaults at least as often as homegrown ones. Image and configuration scanning does not care who wrote the Dockerfile.
None of this requires source code, and none of it requires the vendor’s cooperation, only the artifacts you already possess and the right to analyze them, which your procurement terms should establish.
The lifecycle: where vendor risk actually lives
The scan at onboarding is the smaller half. Vendor software ages in place: an appliance deployed two years ago contains two-year-old components, and every disclosure since lands on you, silently, unless something is watching.
The pattern that works is inventory-plus-monitoring: keep the SBOM you generated (or a supplier-provided one, once verified) under continuous re-evaluation against new vulnerability data. When the next headline disclosure hits a component, the question “which vendor products in our estate carry this” gets answered from stored inventories in minutes, and the resulting conversation with the vendor starts from evidence: this component, this version, this CVE, what is your timeline. Vendors respond differently to that conversation than to “are we affected?”
Handling the objections
Two objections recur. “Our license prohibits reverse engineering.” Component identification and vulnerability matching on artifacts you legally operate is security due diligence, not reverse engineering in the sense licenses target, and regulated entities increasingly write analysis rights into procurement explicitly. Have counsel settle your standard terms once.
“The vendor provides an SBOM already.” Excellent, and verify it: generate your own from the artifact and diff the two. Agreement builds trust in the vendor’s process. Disagreement is the finding.
The strategic point is symmetry: your customers are learning to treat your software this way, artifacts analyzed, claims verified, components monitored. Applying the same standard upstream is not hostility toward vendors; it is the direction the whole supply chain is moving, and the entities that move early get to set the terms of the conversation.