Cloud security posture (CSPM) for AWS, Azure and GCP in Safeguard

Cloud security posture management (CSPM) means reading the configuration of your cloud accounts on a schedule, comparing it with a written baseline such as the CIS Foundations Benchmarks, and keeping the results as evidence you can show an auditor. You can do the core of it with a read-only role in each cloud, the provider's own tooling and a spreadsheet. Safeguard does it from one place: you connect AWS, Microsoft Azure and Google Cloud under Compliance › Connectors with read-only credentials, and automated tests mapped to the CIS benchmarks and to SOC 2, ISO/IEC 27001, HIPAA, PCI DSS and NIST CSF 2.0 controls run against every account you connect.

This post is written for the cloud or platform security engineer who has just been told that posture evidence for all three clouds is now their job, and for the GRC lead who will hand that evidence to an auditor. The first two thirds work with whatever tools you already have. Safeguard enters at "How Safeguard does this".

Key takeaways

• Posture is your half of the shared responsibility model. AWS, Microsoft and Google each publish that the customer configures identity, data access and network exposure. A misconfigured bucket is never the provider's finding to fix.
• Start with a read-only principal per cloud: the AWS managed policy SecurityAudit, an Azure app registration with a read role on the subscription, and a Google Cloud service account with viewer and security reviewer roles. Never hand a posture tool owner or admin rights.
• Map every check to a recommendation number in the CIS Foundations Benchmark for that cloud, then to the control it supports (SOC 2 CC6 and CC7, ISO/IEC 27001 Annex A, NIST CSF 2.0 PR.PS). That mapping is what turns a finding list into audit evidence.
• Safeguard's compliance connectors for AWS, Microsoft Azure and Google Cloud Platform (GA) read each account and run automated posture tests mapped to the CIS AWS, Azure and GCP Foundations Benchmarks and to framework controls. Results show under Compliance › Tests with their recommendation numbers.
• Several accounts of one provider can be connected side by side (GA), each with its own card and its own results, once multiple accounts are switched on for your workspace.
• The Cloud provider catalog on the Integrations Cloud tab (GA, switched on per workspace) shows which clouds have a full connector, which work through a generic Kubernetes, S3-compatible, OpenStack or OCI registry connector, and lets you request the rest.
• Policies and gates (GA) act on scans of your connected repositories with Block, Warn and Notify, and approvals run through exceptions. Cloud posture tests produce evidence; they do not block a cloud change.
• Safeguard only reads. It does not change cloud settings, and a passing test is evidence toward a control, not proof that the control is met.

The situation

The trigger is usually one of three things. An auditor's request list arrives with a line asking for evidence that cloud resources are configured to a baseline and that the baseline is monitored. A customer security questionnaire asks which CIS benchmark you follow in each cloud and how often you check. Or an acquisition lands a second cloud on your desk, and the posture routine you built for AWS now has to cover Azure subscriptions and Google Cloud projects too.

Whoever is asking, the shape of the request is the same. They want three things by a date:

1. A named baseline per cloud (which benchmark, which version).
2. Results against that baseline, per account, with dates.
3. Proof that the check is continuous, not a screenshot taken the week before the audit.

A bad week looks like this. You export a findings list from each provider's console. The three exports use different severity scales, different resource naming and different check titles. None of them say which SOC 2 criterion or ISO control the check supports. Two Azure subscriptions were never enrolled, one Google Cloud folder sits outside the project you scanned, and the AWS export covers one region. The auditor asks how you know nothing changed since the export, and the honest answer is that you do not.

Most of that pain is not about finding misconfigurations. It is about scope, mapping and continuity. Those are the parts this post focuses on. If you want the misconfigurations themselves first, start with common AWS IAM misconfigurations that lead to breaches and the broader security misconfiguration checklist.

The rule behind it

Shared responsibility: the providers say posture is yours

Every major cloud splits security duties between provider and customer, and every one puts configuration on the customer side.

• AWS describes its model as AWS being responsible for security "of" the cloud and the customer for security "in" the cloud. What falls on the customer side depends on the services chosen: for an infrastructure service such as Amazon EC2, AWS says the customer performs all of the necessary security configuration and management tasks. (AWS shared responsibility model)
• Microsoft states that for every cloud deployment type, the customer owns their data and identities and is responsible for protecting them, along with the cloud components the customer controls. (Shared responsibility in the cloud)
• Google Cloud frames it as shared responsibility plus "shared fate", where Google helps with things like a secured landing zone. Its own diagram still has customers always responsible for their access policies and data. (Shared responsibilities and shared fate on Google Cloud)

The practical reading is simple. A public storage bucket, an access key that never rotates, a security group open to the internet on an admin port or audit logs that nobody keeps are all your configuration. No provider will raise them as their incident.

The baselines: CIS Foundations Benchmarks per cloud

The Center for Internet Security publishes a Foundations Benchmark for each major cloud. Each one is a numbered list of recommendations covering identity, logging, monitoring, networking, storage and compute. Safeguard's docs map its automated tests to three of them:

• CIS Amazon Web Services Foundations Benchmark v3.0.0
• CIS Microsoft Azure Foundations Benchmark v2.1.0
• CIS Google Cloud Platform Foundations Benchmark v3.0.0

The recommendation numbers matter. An auditor or customer reviewer can check "CIS AWS 5.6" against the benchmark text without trusting your summary of it. When you report posture, report it by recommendation number.

The controls: what an auditor maps posture to

Posture checks are rarely the end goal. They are evidence for broader controls:

• NIST CSF 2.0 has a Platform Security category (PR.PS). PR.PS-01 asks that configuration management practices are established and applied, and the Detect function covers continuous monitoring (DE.CM). (NIST CSWP 29, The NIST Cybersecurity Framework 2.0)
• SOC 2 criteria for logical access (the CC6 series) and system operations (the CC7 series) are where cloud configuration evidence usually lands. Safeguard's AWS and Azure connector pages map their tests to criteria such as CC6.1, CC6.6, CC7.1 and CC7.2.
• ISO/IEC 27001:2022 Annex A controls appear in the same mappings, for example A.8.9, A.8.15 and A.8.16 on the AWS connector page.
• PCI DSS requirements appear too, for example 1.3.1 on the AWS page and 2.2.1 on the Azure page.

Read the clause text in the standard itself before you cite it to an auditor; the connector pages give the mapping, not the wording.

This post is not legal, regulatory or audit advice. Your auditor decides what evidence satisfies a control. What you can control is that every posture result carries the benchmark number and the control it supports, so the conversation starts from a mapping rather than a pile of screenshots.

Step by step: build a posture routine across three clouds

These steps work with any tooling, including only the providers' own consoles and command line tools. Do them in order; the early steps decide whether the later ones mean anything.

1. Write down your scope before you scan anything

List every AWS account, every Azure subscription and tenant, and every Google Cloud organization, folder and project. Note who owns each one, whether it is production, and which regions it uses. A posture report is only as good as its scope. The most common gap in a first audit is not a failing check but an account nobody connected.

Use this template and keep it with the evidence:

2. Create a read-only principal in each cloud

A posture tool needs to read configuration metadata, not change it. Give it exactly that.

AWS. Create a dedicated IAM principal and attach the AWS managed policy SecurityAudit, which AWS describes as granting access to read security configuration metadata. AWS's IAM guidance prefers temporary credentials from roles over long-term access keys and says never to create access keys for the root user. If your tool only accepts an access key, keep that key on a dedicated user with nothing but read policies, and rotate it. (SecurityAudit managed policy, IAM security best practices)

Azure. Register an application in Microsoft Entra ID, give it a client secret, and assign it a read role on each subscription through Access control (IAM). The built-in Reader role lets a principal view all resources without making changes. If the tool reads directory settings through Microsoft Graph, an administrator must grant admin consent for the application permissions. (Azure built-in roles)

Google Cloud. Create a service account and grant read-only roles at the organization or folder level so new projects are covered automatically. Google's guidance treats service account keys as a security risk when not managed and recommends avoiding them where an alternative exists. If you must use a key, scope the account to viewer roles and rotate it. (Best practices for managing service account keys)

The three clouds model identity differently, which is why the principal looks different in each; our comparison of IAM models across AWS, Azure and GCP walks through the differences. Whatever you choose, record which principal reads which scope. That record is evidence in its own right: it shows the monitoring has the access it claims to have.

3. Pick one baseline per cloud and fix its version

Choose the CIS Foundations Benchmark version for each cloud and write it down. Do not mix versions within a reporting period. Recommendation numbers shift between versions, and a report that cites "4.3" without a version is ambiguous.

4. Start with the checks that cause real incidents

Every benchmark is long. Start with the recommendations that map to the misconfigurations behind most cloud exposure: public data, standing credentials, missing logs and open admin ports. Here is a starting set, using recommendation titles as Safeguard's docs list them and the provider docs that explain each setting.

Run these first. Fix what fails. Then widen to the full benchmark.

5. Normalise results into one record shape

Each provider names and scores findings differently. Before you report, put every result into one shape:

• Cloud and account (subscription, project) it came from
• Benchmark and version
• Recommendation number and title
• Result: pass, fail or error
• Date and time read
• Control or controls it supports in each framework you report against
• Owner and ticket, if it failed

An error is not a fail. If the reader was denied permission, the check did not run. Report it as a coverage gap and fix the permission; do not count it as a failed control, and never count it as a pass.

6. Decide what "continuous" means and write it down

Auditors ask how often you check, not only what you found. Pick a schedule per cloud (daily is common for posture), record it, and keep every run, not only the latest. If your tooling keeps history, export a sample run per period. If it does not, schedule an export.

7. Route failures to owners with a deadline

A failing check without an owner is a finding that will still be failing at the next audit. Route each failure to the team that owns the account. Agree a due date by severity, and keep an exception record (who accepted the risk, why, until when) for anything you will not fix.

8. Prevent the same misconfiguration from shipping again

Posture checks find drift after deployment. The cheaper fix is upstream: scan Terraform, CloudFormation, Bicep or Kubernetes manifests before they deploy, and use the provider's own guardrails where you can. Google Cloud's organization policy service can enforce constraints across a resource hierarchy, Azure Policy evaluates and can deny non-compliant resources, and AWS Organizations service control policies can restrict what accounts may do. (Organization Policy overview, Azure Policy overview, Service control policies)

For worked examples, see using GCP organization policy constraints to enforce security guardrails and using IAM Access Analyzer to find unused and external access.

Preventive guardrails and detective posture checks are complements. Guardrails stop a class of change; posture checks prove the guardrails held and catch what they do not cover.

A one-page checklist you can use today

• Scope table filled in for all three clouds, with an owner and a date
• One read-only principal per cloud, recorded, with no write or admin rights
• Benchmark and version fixed per cloud
• Starter checks above run in every account, every region in use
• Errors separated from failures, and every error traced to a missing permission
• Each result mapped to the control it supports
• Schedule written down and history kept
• Failures routed with owner, due date and exception record
• Preventive guardrails on the misconfigurations that keep coming back

What CSPM is, and what it is not

CSPM reads the control plane: identity and access configuration, storage settings, network rules, logging and encryption settings, service enablement. It answers "is this account configured the way our baseline says". It does not look inside running workloads, read your source code or inspect container images. Those are separate disciplines: workload protection for running hosts and containers, software composition analysis for dependencies, and image scanning for registries. A cloud security program needs posture plus at least some of those, and it helps to be clear which tool answers which question.

Which misconfigurations matter first in each cloud

AWS

Identity carries the most weight. Long-lived access keys, IAM users with more than one active key, custom policies that grant full administrator rights, and root used for daily work are the patterns AWS's own best practices warn against. After identity, look at S3 (TLS-only bucket policies, MFA Delete, logging of object reads and writes), at CloudTrail and its alerting on sensitive changes, and at network exposure on admin ports. IMDSv2 matters because once it is required, AWS says IMDSv1 can no longer be used on that instance; AWS also advises confirming the instance makes no IMDSv1 calls before you switch.

Azure

Storage accounts and network rules come first: public network access, default deny, private endpoints, and soft delete. Then logging and alerting (activity log alerts on policy assignment, network security group and public IP changes), database settings (TLS enforcement, auditing on SQL, PostgreSQL and MySQL), and key expiry in Key Vault. Microsoft's guidance is that the customer always owns identities and access, so Entra ID configuration is part of Azure posture whether or not your benchmark lists it under Azure.

Google Cloud

Service accounts and keys first: user-managed keys, admin roles on service accounts and project-wide impersonation. Then the network (no default network, no legacy networks, firewall changes alerted), logging (a sink that exports every entry, retention locks on log buckets) and compute (OS Login, Shielded VM, no public IP where not needed). Checks for BigQuery datasets that are public and Cloud SQL instances without TLS round out the data side.

How do you give a posture tool access without giving it power?

Read-only is not one setting; it is a choice made per cloud.

A useful test: try to change something with the posture credential in a non-production account. It should fail. Record that it failed.

How do you cover many accounts, subscriptions and projects?

Grant at the highest level that makes sense: the Google Cloud organization or folder, the Azure management group or each subscription, and each AWS account (or a delegated administrator pattern if your tooling supports it). Then reconcile the scope table against what the tool actually read. A tool that silently skips an account it cannot read is worse than one that reports an error.

How do posture results become audit evidence?

Three properties turn a result into evidence: it names its baseline item, it names its source account and time, and it maps to a control. Keep the raw result, not only a summary. Keep the history. And keep a short note on what a pass does and does not mean: a passing check shows a setting was as expected when it was read. It does not prove the control is designed well or operating all year.

How Safeguard does this

Safeguard runs cloud posture through its compliance connectors. The steps below follow Safeguard's docs. Commands and screens are named only where the docs show them; none of the snippets in this post were run for it.

1. Check what is available to your workspace. Open Integrations and choose the Cloud tab. The Cloud provider catalog (GA) lists providers by region, category and connection type. Each card says whether Safeguard has a full connector for that provider's own API, a standard connector through a generic Kubernetes, S3-compatible, OpenStack or OCI registry connector, or needs a request. AWS, Microsoft Azure and Google Cloud have full connectors; the card's Connect button opens the Connectors tab on that connector. The catalog is switched on per workspace, so ask your Safeguard contact if you do not see it.

2. Connect AWS. In the IAM console, create a dedicated IAM user for Safeguard, create an access key for it, and attach the AWS managed policy SecurityAudit. Then on Compliance › Connectors, open Amazon Web Services, choose Connect and API token, and enter the access key ID and secret access key. Region and a session token are optional. Safeguard stores the credentials encrypted and does not show them again. The AWS card is the same provider connection as the AWS GovCloud, Amazon S3, Amazon CloudWatch, AWS CodeCommit, AWS Inspector and AWS Security Hub cards, so the AWS tests run for a connection made through any of them. If you connect through the AWS Security Hub card, the docs give the AWS managed policy AWSSecurityHubReadOnlyAccess, which allows only Get, List and Describe actions.

3. Connect Microsoft Azure. Choose OAuth, where a tenant administrator approves Safeguard on Microsoft's consent screen, or an API token. For the token route, register an app in the Microsoft Entra admin center, create a client secret, add the Microsoft Graph application permissions Safeguard needs and grant admin consent, then assign the app a role on each subscription under Access control (IAM). On Compliance › Connectors, open Microsoft Azure and enter the directory (tenant) ID, application (client) ID and client secret. The Azure Government and Microsoft Entra ID cards connect to the same provider.

4. Connect Google Cloud. Choose OAuth, which asks you to approve the cloud-platform.read-only scope, or a service account key. For a stable connection, create a service account and grant it the read roles the docs list, starting with roles/viewer and roles/iam.securityReviewer and adding service-specific viewer roles such as roles/logging.viewer, roles/cloudkms.viewer and roles/orgpolicy.policyViewer. Grant them once on the folder or organization to cover every project beneath it, plus roles/resourcemanager.organizationViewer, roles/iam.securityReviewer and roles/browser on the organization for organization-level checks. Then open Compliance › Connectors › Google Cloud Platform › Connect, choose API token and paste the whole JSON key. One connection reads every project the credential can see, and the Google Cloud Storage card shares the same connection.

5. Add more accounts of the same provider. AWS (including GovCloud), Google Cloud and Microsoft Azure (including Azure Government) can each be connected more than once. When multiple accounts are switched on for your workspace, a connected card offers Add another account. Give each one a label, enter its credentials, and it gets its own card. Every test runs against each account, and each result names the account it came from. This is what keeps a three-cloud, many-account estate in one view without losing which account failed.

6. Read the results by benchmark. Open Compliance › Tests and filter by the CIS benchmark to see its results with their recommendation numbers. Tests run on their schedule, or straight away with Run now. A CIS benchmark is a catalogue mapping in Safeguard, not a framework in your library: results show on the tests, filters and evidence with their recommendation numbers. Automated tests are switched on per workspace by the Safeguard team.

7. Use the same results as framework evidence. Each connector page lists the frameworks its tests map to. For AWS, Azure and Google Cloud these include SOC 2, ISO/IEC 27001, HIPAA Security Rule, PCI DSS and NIST CSF 2.0 controls, as well as the CIS benchmark. A passing test counts as evidence toward every control it maps to, in every framework listed, after an initial settling period the docs describe. This is the Compliance and GRC suite (GA) doing the mapping step from the routine above.

8. Treat errors as coverage, not failures. If a cloud refuses a read, Safeguard reports an error that names the missing permission or role, not a failed control. For Google Cloud, a project the credential cannot read shows one error naming that project while the others still run. Grant the role named, then use Re-check on the card. If an OAuth token expires, the card shows Not working and offers Re-authorize.

9. Gate what flows through your pipelines. Policies and gates (GA) evaluate the scans Safeguard runs for your connected repositories. Each policy's action decides what a failure does: Block fails the gate, Warn passes it with a warning naming the policy, and Notify passes it and sends a notification. When a team needs to ship anyway, they request an exception with a business justification and an expiry date, and an approver decides; the audit trail records it. In CI, the docs show this form:

safeguard ci scan --wait --fail-on-gate <gate>

Replace the gate placeholder with your gate's name. Cloud posture tests themselves are evidence; they are not wired into gates.

Mapping the routine to Safeguard

What Safeguard does not do

• It does not change your cloud. Every check only reads. Safeguard does not remediate a cloud misconfiguration, open a change in your cloud account or roll back a setting. Fixing a failing recommendation is your team's change, made with your own tooling.
• It does not prove a control is met. Safeguard's docs say plainly that a passing result is evidence toward a control, not proof that the control is met on its own. Design, scope and operating effectiveness are still for you and your auditor.
• It does not cover every benchmark recommendation. The automated tests map to a subset of each CIS Foundations Benchmark. Recommendations that need a human decision or a document, and any the docs do not list, stay manual.
• It does not see what the credential cannot see. A project outside the granted folder, a subscription without a role assignment or an account you never connected is not checked. Scope reconciliation is your job.
• It does not replace workload, runtime or image security. Posture reads the control plane. It does not inspect running containers, hosts or the packages inside your images; those are separate capabilities with their own setup.
• The direct cloud deployment cards do not deploy anything yet. The Cloud tab's AWS, Google Cloud, Azure, IBM Cloud and Oracle Cloud deployment dialogs show example commands only. Marketplace deployment, or a deployment set up with Safeguard, is how Safeguard runs in your own cloud. This is about where Safeguard runs, not about posture.
• Some parts are switched on per workspace. The Cloud provider catalog, automated tests and multiple accounts per provider are each switched on per workspace. If you do not see them, ask your Safeguard admin or contact.

Common mistakes

• Scanning one region. IAM Access Analyzer's external access analyzer works per Region. A clean result in one Region says nothing about the others.
• Granting at the project, not the folder. In Google Cloud, new projects created under a folder are covered only if the read roles were granted at the folder or organization.
• Counting errors as passes. A check that could not read the resource did not pass. Track errors as coverage gaps.
• Using an admin credential "to save time". It makes the posture tool a target and fails the least privilege story you are trying to evidence.
• Reporting without versions. "CIS 4.3" without the benchmark and version is ambiguous to a reviewer.
• Letting secrets expire silently. Azure client secrets and rotated AWS keys break connections. Put the expiry in a calendar and replace the credential in the connector before it lapses.
• Treating posture as a once-a-year export. Continuity is what an auditor tests. Keep every run.
• Fixing in the console only. If the resource is defined in infrastructure code, a console fix will be undone by the next deploy. Fix the template too.

FAQ

What is CSPM in simple terms?

Cloud security posture management is the practice of reading your cloud configuration on a schedule, comparing it with a baseline such as the CIS Foundations Benchmarks, and tracking what fails until it is fixed or formally accepted.

Does Safeguard do CSPM for AWS, Azure and Google Cloud?

Yes. Safeguard's compliance connectors for Amazon Web Services, Microsoft Azure and Google Cloud Platform (GA) read each account with read-only access and run automated posture tests mapped to the CIS benchmark for that cloud and to SOC 2, ISO/IEC 27001, HIPAA, PCI DSS and NIST CSF 2.0 controls.

What permissions does Safeguard need in AWS?

The docs describe a dedicated IAM user with the AWS managed policy SecurityAudit, connected with an access key ID and secret access key, plus an optional Region and session token. For the AWS Security Hub card, the docs give AWSSecurityHubReadOnlyAccess.

What permissions does Safeguard need in Azure?

Either OAuth with tenant administrator consent, or an Entra ID app registration with a client secret, the Microsoft Graph application permissions Safeguard needs with admin consent, and a role assignment on each subscription you want read.

What permissions does Safeguard need in Google Cloud?

Either OAuth with the cloud-platform.read-only scope, or a service account with roles/viewer, roles/iam.securityReviewer and the service-specific viewer roles the docs list, granted on projects, a folder or the organization.

Which CIS benchmark versions does Safeguard map to?

The docs name CIS Amazon Web Services Foundations Benchmark v3.0.0, CIS Microsoft Azure Foundations Benchmark v2.1.0 and CIS Google Cloud Platform Foundations Benchmark v3.0.0.

Can I connect several AWS accounts or Azure subscriptions?

Yes, when multiple accounts are switched on for your workspace. A connected card offers Add another account, each account gets its own card, and every result names the account it came from. For Google Cloud, one connection already reads every project its credential can see.

Does Safeguard fix cloud misconfigurations automatically?

No. Cloud posture checks only read. Your team makes the fix in the cloud or in the infrastructure code that defines the resource.

Does a passing test mean we are compliant?

No. A passing test is evidence toward a control. Whether the control is designed and operating well over the audit period is for you and your auditor to decide.

Can Safeguard block a deployment that would create a misconfiguration?

Policies and gates act on scans of your connected repositories, with Block, Warn and Notify actions and approval through exceptions. Cloud posture tests read deployed state and do not block changes; preventing a misconfiguration before deployment stays with your provider guardrails and infrastructure code reviews.

Posture checks tell you where your cloud configuration drifted; the same accounts also run open source code whose flaws you cannot always wait on a maintainer to fix. The block below explains how Safeguard handles that side of the problem, for the packages running inside the workloads your posture checks cover.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session: install, open the interactive terminal with safeguard, ask it to fix the lodash CVE in a repository, and watch it read the finding and advisory, edit package.json, run the install and tests with approval, and push nothing. It asks before any command that changes something, not before every command. That is the same rule this post sets for cloud posture: the tool reads freely, and every change waits for a person.

Click through it at your own pace, or open it full screen.

The second demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. Choosing tools per client is least privilege for an assistant, the same principle as the read-only cloud credentials in the steps above.

Click through it at your own pace, or open it full screen.

The third demo is a real desktop app session: the CLI session shows in the conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit, and it ends with the upgrade done and tests passing. Those per-step approvals mirror the exception approvals that sit behind a Block gate.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Safeguard docs: Integrations
• Safeguard docs: Cloud provider catalog
• Safeguard docs: Cloud deployment
• Safeguard docs: Compliance connectors
• Safeguard docs: Connect Amazon Web Services
• Safeguard docs: Connect Microsoft Azure
• Safeguard docs: Connect Google Cloud
• Safeguard docs: Connect AWS Security Hub
• Safeguard docs: CIS AWS Foundations Benchmark and connectors
• Safeguard docs: CIS Microsoft Azure Foundations Benchmark and connectors
• Safeguard docs: CIS Google Cloud Platform Foundations Benchmark and connectors
• Safeguard docs: Policies and Gates
• AWS shared responsibility model
• AWS managed policy: SecurityAudit
• AWS IAM security best practices
• AWS IAM Access Analyzer
• Amazon S3 security best practices
• Amazon EC2: configure instance metadata options
• AWS Organizations service control policies
• Microsoft: Shared responsibility in the cloud
• Microsoft: Azure built-in roles
• Microsoft: Azure Storage firewall rules and network access control
• Microsoft: Trusted launch for Azure virtual machines
• Microsoft: Azure Policy overview
• Google Cloud: Shared responsibilities and shared fate
• Google Cloud: Best practices for managing service account keys
• Google Cloud: About OS Login
• Google Cloud: VPC networks
• Google Cloud: Organization Policy overview
• NIST CSWP 29: The NIST Cybersecurity Framework 2.0

Download Safeguard at safeguard.sh/download, and read the product documentation at docs.safeguard.sh.

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.