Cloud Security Checks

Overview

When a cloud scan runs, Fencer evaluates your cloud infrastructure against a comprehensive set of security checks tailored to each provider. For major cloud platforms, this means hundreds of checks covering core service categories. For hosting platforms and developer tools, Fencer runs its own purpose-built checks targeting the security settings specific to each platform.

Every check result is normalized into a vulnerability record with a severity rating and flows into the standard vulnerability pipeline alongside findings from code scans, network scans, and other scan types.

Major cloud providers

For AWS, Azure, and GCP, Fencer evaluates your accounts against hundreds of industry-standard security checks. Checks are organized across the following areas:

IAM policies and roles — Overly permissive policies, unused roles, missing MFA enforcement, and excessive privilege assignments
Storage bucket and blob permissions — Public access settings, ACL configurations, and cross-account access on S3, GCS, and Azure Blob Storage
Encryption at rest and in transit — Missing encryption on databases, volumes, and object storage; TLS configuration on load balancers and endpoints
Logging and monitoring — CloudTrail enablement, audit log configuration, alerting thresholds, and log retention policies
Networking — Overly permissive security groups, firewall rule misconfigurations, VPC flow log settings, and unrestricted inbound access on sensitive ports
Compute instance configuration — Instance metadata service settings, public IP exposure, patch levels, and user data containing sensitive information
Database security settings — Publicly accessible RDS/Cloud SQL instances, deletion protection, and parameter group settings

For GCP, Fencer also checks that the organization has Context-Aware Access levels configured.

Hosting platform checks

For Cloudflare and the hosting platforms, Fencer runs its own purpose-built checks designed for each platform’s security model:

Provider	Checks	What they cover
Cloudflare	35	Account 2FA, API token scope and expiry, Turnstile; SSL/TLS mode, minimum TLS version, TLS 1.3, 0-RTT, HSTS, Always Use HTTPS and HTTPS rewrites; WAF, rate limiting, bot management, security level, Authenticated Origin Pulls, development mode, page rules, paused zones, phishing flags; SPF, DMARC, DKIM and CAA records, wildcard records, records pointing at internal IPs, and records not proxied
DigitalOcean	18	Team MFA, firewalls open to SSH/RDP or all ports, Droplets without a cloud firewall or backups, public and end-of-life managed databases, Spaces open to public list/read/write and without versioning, Kubernetes upgrades, control plane exposure and privileged workloads, load balancers accepting plain HTTP, expired certificates, CDN custom domains without a valid certificate
Heroku	4	Account 2FA, deprecated and beta stacks, add-ons reachable from the internet
Render	8	Account MFA, public PostgreSQL databases without an IP allowlist, internal services exposed publicly, missing health checks, unpinned runtime versions, secrets shared across environments, excessive admin roles, shell access without MFA
Railway	8	2FA enforcement, public database URLs, deployment protection, environment variable leakage, exposed TCP ports, missing resource limits, default template passwords, containers running as root
Vercel	8	SAML SSO enforcement, deployment protection, firewall, attack challenge mode, sensitive environment variables exposed to preview deployments, over-provisioned function timeouts and memory, wildcard CORS origins
Supabase	11	Organization MFA, tables without Row-Level Security, permissive RLS policies, unprotected `auth.users`, `SECURITY DEFINER` functions, public storage buckets, email confirmation, password policy, CAPTCHA, insecure redirect URLs, database webhooks without a secret

Severity mapping

Check results are mapped to four severity levels based on the potential impact of the misconfiguration and its exploitability:

Severity	Description
Critical	Immediate risk of data breach or full account compromise (e.g., a DigitalOcean Space that allows anonymous writes, a firewall that allows every inbound port)
High	Significant exposure that could lead to unauthorized access or data loss (e.g., a publicly reachable managed database, a Supabase table without Row-Level Security)
Medium	Security best practice violations that increase risk without direct exploit path (e.g., a Cloudflare zone without active WAF protection, a weak password policy)
Low	Minor deviations from hardening guidelines with limited direct impact (e.g., a DNS record that is not proxied, a service without a health check)

Environment type impact on prioritization

The environment type set on a cloud account does not change a finding’s severity, but it scales the priority of findings on that account’s resources, so production issues rank above the same issue in a development or test account:

Production — Full priority.
Mixed — Priority reduced to 70%.
Test — Priority reduced to 30%.
Development — Priority reduced to 10%.

Check categories

Category	What it covers
IAM	Identity and access management policies, roles, users, and service accounts
Storage	Object storage buckets, blob containers, and file shares
Encryption	Data at rest and in transit across compute, storage, and database services
Logging	Audit logs, activity monitoring, and alerting configuration
Networking	Security groups, firewall rules, VPC settings, and network ACLs
Compute	Virtual machines, container services, serverless functions
Database	Managed database services including RDS, Cloud SQL, and Azure SQL

How findings enter the vulnerability pipeline

Check results are normalized into standard vulnerability records as part of the scan completion process:

Each triggered check that produces a finding creates a vulnerability record linked to the cloud account asset.
Findings are grouped alongside results from other scan types — code, network, application — under the same vulnerability management workflow.
Deduplication runs across scans so that a recurring misconfiguration is tracked as a single open vulnerability rather than creating duplicate records on each scan.
When a misconfiguration is resolved and the next scan confirms it, the vulnerability is automatically marked as resolved.

Examples

Reviewing AWS findings after a scan

Click Run scan for your AWS account on the Posture > Infrastructure page.
Once complete, open the account and select its Vulnerabilities tab.
Sort by severity so Critical findings — such as an S3 bucket with public access enabled — appear at the top.
Click into a finding to see the affected resource ARN, the specific check that triggered it, and remediation guidance.

Understanding severity for a GCP finding

A GCP scan finds that your organization has no Context-Aware Access levels configured. This is rated Medium: a compromised credential then grants access regardless of device state, IP address, or geography. After you configure access levels and run a new scan, the vulnerability is marked resolved.

Troubleshooting

Checks not running for a specific service — Verify that the connected IAM role, service account, or API token has read access to the relevant service. A check cannot report on a service it cannot read.
Severity seems too high or low for a finding — Severity is assigned at the check level and reflects general risk. Use the vulnerability management workflow to adjust the priority for your environment.
Same finding appearing multiple times — If deduplication is not collapsing findings, confirm that the affected resources are genuinely different. Two separate S3 buckets with the same misconfiguration correctly produce two separate records.
No findings after scan — Ensure the cloud account has active resources. A newly created or empty account may not trigger any check findings.