Cloud marketplaces are the easiest way to ship third-party software into a production cloud account. A buyer clicks a button, the marketplace deploys a CloudFormation stack or a Bicep module or a Deployment Manager template into the buyer's account, and the third-party vendor's code is running with whatever permissions the template requested. This convenience is also the supply chain risk profile.
I have done due diligence on cloud marketplace listings for procurement teams in three industries — financial services, healthcare, and manufacturing — over the last two years. The due diligence patterns that work are not the ones that the marketplaces themselves prompt buyers to follow. The marketplaces' default checklists are about pricing, billing, and entitlements. The supply chain due diligence has to come from the buyer.
What is the actual risk profile of a marketplace deploy?
A marketplace listing typically deploys an IaC template that creates resources in the buyer's account, with permissions the buyer grants at deploy time. The vendor's code then runs in the buyer's account, often with persistent credentials and permanent network access to the buyer's resources. A compromise of the vendor compromises every buyer's account that has deployed the listing.
The 2026 wrinkle is that marketplace listings increasingly include automatic update paths. The listing is configured with a "managed" mode in which the vendor pushes updates directly to the buyer's deployment, without explicit buyer approval per update. The convenience is real; the supply chain risk is also real, because the buyer's posture now depends on the vendor's release discipline.
The vendor's release discipline is the part most due diligence misses. A vendor with a single signing key, a single release pipeline, and a small engineering team has a very different risk profile from a vendor with separated signing keys, multi-stage release pipelines, and a hardened build infrastructure. The buyer cannot assess this from the marketplace listing page; the assessment requires a direct conversation with the vendor.
What should the buyer ask before clicking deploy?
Five questions, in order of priority. First, what permissions does the deployed stack request, and which of those permissions are wide enough to constitute a privilege escalation if the vendor is compromised? Second, what is the vendor's signing and release process, and is there evidence of it (signed artifacts, public attestations, audited release logs)? Third, does the listing support an air-gapped or no-managed-update mode, and what is the operational cost of using it? Fourth, what is the vendor's incident response process, and what are the contractual commitments around notification and remediation? Fifth, what is the vendor's posture on the four most relevant compliance frameworks — SOC 2, ISO 27001, FedRAMP, and the supply chain framework that applies to the buyer's industry?
The first question is the most actionable. The deployed stack template is a public document, and the buyer can read every IAM action, role binding, and resource permission it requests. A stack that requests iam:* or *:* or assumes a role with administrative permissions is a hard pass; there is no operational reason for a marketplace listing to need that level of access. A stack that requests narrowly scoped permissions, with conditions on the source of the calls, is the right baseline.
The second question is harder but the answers are revealing. A vendor that can produce a SLSA Level 3 provenance for every release, with the signing key in an HSM and the release pipeline in audited IaC, has a different posture from a vendor that ships unsigned tarballs from a personal GitHub repository. The marketplace does not differentiate between the two; the buyer has to.
How do I assess the deployed stack's posture continuously?
The deployed stack is not static. It receives updates, it accumulates state, and it can drift from its initial configuration. The continuous assessment has to track three signals: the IaC the vendor publishes, the resource configuration in the buyer's account, and the network and audit telemetry the resources produce.
The IaC tracking is straightforward — the buyer subscribes to the vendor's IaC repo or the marketplace listing's revision history, and any change is flagged for review. The configuration tracking is harder, because the deployed resources can be modified by the vendor's automation, by the buyer's automation, or by a human with appropriate IAM permission. The drift detection has to distinguish between authorized changes and unauthorized ones.
The telemetry tracking is the most useful in practice. The deployed stack's network egress, IAM call patterns, and resource access patterns are visible to the buyer in CloudTrail, Azure Activity Log, or Google Cloud Audit Logs. An anomaly in those signals — a new outbound destination, a new API call, a new resource access — is a leading indicator of either a vendor compromise or a vendor's misuse of the trust the buyer has granted.
What about marketplace listings that include containers?
A marketplace listing that ships a container image inherits the entire container supply chain risk profile, plus the marketplace risk profile. The buyer should require a Cosign or notation signature on every image the listing deploys, with the signing key bound to the vendor's identity. If the vendor cannot produce signatures, the listing does not get deployed in production.
The signature verification has to happen at the buyer's admission controller, not at the marketplace. The marketplace's own verification, if any, is a vendor-attested signal, not a buyer-verified one. A Kyverno or Gatekeeper policy on the buyer's clusters that requires a signature from any registry the marketplace deploys to is the right enforcement point.
The base image hygiene is the other dimension. A vendor that ships an image based on a recent, patched base image and rebuilds it weekly has a different posture from one that ships an image based on a year-old base. The vendor's rebuild discipline is part of the due diligence question, and the answer is verifiable from the image's attestation history.
How do I handle the auto-update permission grant?
Two patterns work. Either disable auto-update entirely and require explicit per-update buyer approval, or enable auto-update but pin the update path to a specific signing key and require an attestation on every update. The first pattern is operationally expensive and the right choice for high-criticality workloads. The second is operationally cheaper and the right choice for everything else.
The pin-to-signing-key pattern requires the marketplace listing's update path to verify the new artifact's signature against a key the buyer has approved at deploy time. If the vendor changes the signing key, the buyer is notified, the update is paused, and the buyer has the chance to evaluate the new key before allowing further updates. This is a small piece of operational discipline that closes the most common auto-update compromise path.
How Safeguard Helps
Safeguard's TPRM module ingests cloud marketplace listings, the vendor's published IaC, the deployed stack's resource configuration, and the runtime telemetry, and produces a continuous posture signal per vendor. The signal flags vendors with weak signing posture, vendors who have changed their signing key without notification, and deployed stacks whose configuration has drifted from the vendor's published IaC.
Griffin AI generates the deploy-time policy artefacts the buyer needs — IAM permission boundaries, Kyverno verification policies, drift detection rules, and CloudTrail or Activity Log analytics — from an existing marketplace deployment, then opens pull requests against the buyer's IaC repo to roll the controls out. The PR-driven workflow lets the procurement team and the security team review the controls before they go live.
Safeguard's SBOM module attaches an in-toto attestation to every container image the marketplace listing deploys, the policy gate module integrates with the buyer's deploy pipelines so an update can be blocked from a Safeguard policy decision, and the container self-healing module tracks which marketplace-deployed workloads are running outdated images and the buyer's options for updating them.
For procurement teams, Safeguard's vendor-risk dashboard rolls up the posture signal across every marketplace deployment in the buyer's estate, with a single view of which vendors are out of policy, which deployments are past an update deadline, and which contractual obligations the vendors have failed to meet. The continuous tracking is the difference between point-in-time due diligence at procurement and ongoing assurance through the life of the contract.