Skip to content

Cloud Infrastructure Scanning

Cloud Infrastructure Scanning continuously assesses your cloud accounts for security misconfigurations, compliance violations, and best-practice deviations. By connecting your cloud provider accounts to Fencer, you get hundreds of industry-standard checks for the major clouds along with Fencer’s own provider-specific checks — all surfaced as actionable vulnerabilities in a single view.

  • An active Fencer organization with a valid subscription that includes cloud scanning.
  • At least one cloud provider account connected as an integration (e.g., AWS, Azure, GCP, Cloudflare, or a hosting platform). Connecting an integration requires the Administrator role.
  • Appropriate credentials for each provider (an IAM role, a service principal or service account, an API token, or an OAuth connection, depending on the provider).

Each cloud provider connection creates a Cloud Account asset in Fencer. A Cloud Account represents a single provider account (e.g., one AWS account, one Cloudflare account) and stores its provider type, environment label, and scan configuration.

When a scan runs — either on a schedule or triggered manually — Fencer runs the checks for that provider. For the major cloud providers (AWS, Azure, GCP), Fencer evaluates hundreds of checks across services. For hosting platforms and other providers, Fencer runs its own purpose-built checks (e.g., Heroku stack and add-on checks, Cloudflare WAF, TLS and DNS checks, Render service exposure checks). Scan results are normalized into vulnerabilities with severity ratings and grouped alongside findings from all other scan types.

Scheduled scans run automatically for every connected account that is not suspended: daily or weekly (Mondays), depending on your plan.

ProviderCredentials
AWSIAM role ARN and the external ID Fencer generates (read-only access)
AzureApp registration (service principal): tenant ID, client ID, and client secret
GCPService account key (JSON) for the project
CloudflareAPI token and account ID
DigitalOceanOAuth connection (optional Spaces keys to scan object storage)
HerokuOAuth connection
RenderAPI key
RailwayOAuth connection
VercelOAuth connection
SupabaseAccess token
  1. Go to Admin > Integrations, or click Integrations at the top of the Posture > Infrastructure page.
  2. Find the cloud provider you want to connect and follow the provider-specific setup instructions (e.g., for AWS, you configure an IAM role ARN and external ID).
  3. Once connected, the integration automatically creates a Cloud Account asset, listed on the Posture > Infrastructure page (titled Cloud Infrastructure).
  1. Go to Posture > Infrastructure.
  2. Switch between a table view and a tile view using the view toggle — both list every connected cloud account with its provider and environment. The table also shows open vulnerabilities, scope, and when the account was last scanned.
  3. Use the In Scope column to mark an account in or out of scope inline, or select multiple accounts and use the bulk action bar to change scope for all of them at once. See Asset Scope Management for how scope works and how it cascades to an account’s resources.
  4. Right-click an account for quick actions: Open, Open in new tab, Run scan, Set owner…, Scope, and Add to favorites.
  5. Click on a cloud account to open its detail page.

Each cloud account has an environment classification that helps you prioritize findings:

  • Production — live customer-facing infrastructure
  • Development — development and staging environments
  • Test — test and QA environments
  • Mixed — accounts that serve multiple purposes

The environment lowers the priority of findings on non-production resources; see Cloud Security Checks.

For AWS, Azure, GCP, and DigitalOcean accounts, the provider’s integration settings include a Region Scope card. Choose Scan every region, Scan only the regions I select, or Scan every region except the ones I select, then click Save region scope.

  1. Go to Posture > Infrastructure.
  2. Click Run scan on the cloud account’s tile or row, or on the account’s detail page.
  3. Fencer queues the scan and runs it in the background. You will see a Scan scheduled confirmation.

Running a scan requires the scans:execute permission (Administrator, Team Member, and Penetration Tester roles).

A cloud account’s detail page opens with a summary header — the account’s provider, environment, scope and owner, then KPI cards for open vulnerabilities, connection health (or environment), SLA status, and the last scan — followed by these tabs:

  • Vulnerabilities — every vulnerability found on this account, with the same triage controls (status, assignee, ignore/defer) as the main vulnerability list.
  • Resources — the cloud resources Fencer discovered in this account.
  • Scans — the account’s scan history. Each entry shows the total vulnerability count, how many are new since the last scan, how many were resolved, and a breakdown by severity.
  • Settings — the account’s integration settings (shown to users who can edit assets, for providers that have editable settings).

Use the breadcrumb at the top of the page to jump directly to another cloud account without returning to the list first — it keeps you on the same tab (for example, staying on Vulnerabilities as you move between accounts).

For a detailed reference of what security checks run for each provider, see Cloud Security Checks.

  1. Open the cloud account’s detail page.
  2. Open the actions menu (⋯) in the header and select Delete cloud account.
  3. Click Delete to confirm.

Deleting a cloud account requires the assets:delete permission (Administrator role).

Example: Connecting an AWS account and running a first scan

  1. Go to Admin > Integrations, choose AWS - Amazon Web Services (Scan), and add a new scan connection.
  2. Provide the IAM Role ARN (e.g., arn:aws:iam::123456789012:role/FencerReadOnly) and the external ID generated by Fencer.
  3. Save the connection. Fencer creates a Cloud Account with the AWS provider type.
  4. Go to Posture > Infrastructure, find your new AWS account, and click Run scan.
  5. After the scan completes, review the findings — checks cover IAM policies, S3 bucket configurations, security group rules, encryption settings, logging, and more.
  6. Triage critical findings first from the account’s Vulnerabilities tab.
  • Scan stuck in “queued” or “running” state: Check that your provider credentials are still valid — the Connection card on the account’s detail page shows when a connection is degraded or broken. For AWS, verify the IAM role trust policy includes the correct external ID and that the role has sufficient read permissions.
  • No vulnerabilities found: Ensure the connected account has active resources. An empty or newly created account may not trigger any findings.
  • “Please wait … more minutes before triggering another manual scan”: Manual scans are throttled per cloud account. Wait for the indicated time before retrying.
  • Scheduled scans not running: Scheduled scans skip accounts whose scanning is suspended and organizations without an active subscription.