Cloud Infrastructure Fixes

Overview

Cloud Infrastructure Fixes are API-based automated remediations for cloud misconfigurations discovered by Fencer’s cloud scanning. When a fix is available, Fencer calls your cloud provider’s API directly to correct the misconfiguration — no code patch, no pull request, no manual console work required.

This is distinct from AI-based code fixes, which generate a patch and open a pull request in your source code repository. Cloud infrastructure fixes act immediately on your cloud environment through the provider’s own APIs.

How API-based fixes work

On the vulnerability’s detail page, the Mitigation card shows Show Instructions when a fix exists for the misconfiguration.
Click it to open Fix Instructions: a description of the change and the equivalent CLI command, which you can copy and run yourself.
If Fencer can apply the fix for you, the dialog also shows Apply Fix Automatically. Click it, and Fencer creates a fix attempt tied to the vulnerability and calls the cloud provider’s API through your integration.
On success, Fencer automatically moves the vulnerability to Ready for verification.

No branch, diff, or pull request is involved. The fix takes effect immediately in your cloud environment, and you verify the result on the next scan. Launching a fix requires the Automatic Fixers paid feature and a role that can edit vulnerabilities.

Supported providers and fix types

Fencer has fixes for the following checks. Those marked instructions only show the fix instructions and CLI command but are never applied automatically, because the change could disrupt running workloads.

AWS

CloudTrail — create a multi-region trail (with a new log bucket), block public access to the CloudTrail log bucket, and deny all access for an IAM user or role flagged by CloudTrail threat detection.
S3 — turn on account-level and bucket-level Block Public Access, and remove public read, list, or write ACLs and public-write bucket policies.
EC2 — enable EBS encryption by default, make public AMIs and EBS snapshots private, block public sharing of EBS snapshots, and require IMDSv2 by default.
Security groups exposing sensitive ports to the internet (SSH, RDP, databases, caches, message brokers, and other high-risk TCP ports) — instructions only.
RDS and DocumentDB — turn off public access on RDS instances and make DocumentDB cluster snapshots private.
Public resource policies — remove public access from Lambda functions, ECR repositories, and SQS queues.
KMS — enable key rotation and cancel scheduled deletion of customer-managed keys.
IAM — require a 14-character minimum and an uppercase letter in the account password policy, and add confused-deputy protection to role trust policies.
Security services — enable GuardDuty, Security Hub, and IAM Access Analyzer.
CodeArtifact — block publishing of external public packages.

GCP

Cloud SQL — require SSL connections, enable automated backups, and set the recommended database flags for PostgreSQL, MySQL, and SQL Server. Removing public access and public IPs is instructions only.
Cloud Storage — enable uniform bucket-level access, versioning, soft delete, and a sufficient retention period. Bucket logging, lifecycle management, and locking a log retention policy are instructions only.
Compute Engine — enable Shielded VM, OS Login, deletion protection, and automatic restart, block project-wide SSH keys, turn off serial ports, and enable subnet flow logs and load balancer logging. Firewall rules that allow SSH or RDP from the internet, default service accounts, customer-supplied encryption keys, and legacy networks are instructions only.
Other services — enable DNSSEC, KMS key rotation, Cloud Asset Inventory, and container scanning for Artifact Registry and Container Registry. API key clean-up, GKE default service accounts, organization Essential Contacts, and log sinks are instructions only.

Prerequisites

API-based cloud fixes require more than the standard read-only permissions needed for scanning. Both integrations’ setup instructions include this as an optional step; scanning works without it.

AWS

Create a second IAM policy named FencerFixerPermissions from the JSON shown in the Allow one-click fixes step of the AWS integration’s setup instructions, and attach it to the same FencerScannerRole Fencer uses for scanning. The policy grants only the write actions the fixes need — for example s3:PutBucketPublicAccessBlock, cloudtrail:CreateTrail, ec2:EnableEbsEncryptionByDefault, and rds:ModifyDBInstance.

GCP

Follow the Automated Remediation step of the GCP integration’s setup instructions: create a custom role named FencerFixerRole with the listed write permissions, and grant it to the fencer-scanner service account in the same way as the scanner role.

Fix attempt lifecycle

API fix attempts follow the same lifecycle as AI code fix attempts:

Status	Description
Pending	Fix attempt created, waiting to be processed
In Progress	Fencer is calling the cloud provider API
Success	API call completed successfully; vulnerability moved to verification
Failed	API call failed; error details are shown on the vulnerability

On Success, the vulnerability status automatically transitions to Ready for verification, signaling that a human should confirm the fix took effect.

Fix verification workflow

After a successful API fix, you should verify that the remediation worked as expected:

Open the vulnerability detail page. The status shows Ready for verification.
Check your cloud provider console directly to confirm the setting was changed.
Trigger a new cloud scan to re-evaluate the asset. If the fix was applied correctly, the misconfiguration will not reappear.
Mark the vulnerability as Resolved once you have confirmed the fix on the next scan.

When API fixes are not available

Not every cloud misconfiguration can be fixed automatically:

For an instructions only fix, Fix Instructions shows the description and CLI command, but no Apply Fix Automatically button. Run the command yourself, or make the change in your cloud console.
For a misconfiguration with no fix, use the remediation guidance in the vulnerability details.

Then trigger a new scan to verify the finding is resolved.

Examples

Fixing an AWS S3 public access misconfiguration

A cloud scan detects that an S3 bucket has public access enabled. On the vulnerability detail page, you click Show Instructions, review the change, and click Apply Fix Automatically. Fencer calls the AWS API to apply the Block Public Access configuration to the bucket. Within seconds the attempt reaches Success status, and the vulnerability moves to Ready for verification. You log into the AWS console, confirm the Block Public Access settings are enabled, then trigger a new cloud scan. The finding is no longer present, and you mark it as Resolved.

Enabling versioning on a GCP bucket

Fencer detects that object versioning is off for a Cloud Storage bucket in your GCP project. You open Show Instructions and click Apply Fix Automatically. After the attempt succeeds, you open the bucket in the GCP console, confirm that versioning is now enabled, and run a new scan to verify the finding is resolved.

Troubleshooting

No Mitigation card or Apply Fix Automatically button — no automatic fix is available for this misconfiguration type. Follow the fix instructions or the remediation guidance on the vulnerability detail page.
Fix attempt fails with permissions error — the cloud integration does not have the fixer permissions. Add FencerFixerPermissions (AWS) or FencerFixerRole (GCP) with the actions the error lists, then retry.
Fix attempt stays in Pending — the Fencer background worker may be overloaded. Wait a few minutes and refresh the page. If the attempt remains stuck, contact support.
Vulnerability still appears after a successful fix — The API fix may have taken effect, but the next scheduled scan has not run yet. Trigger a manual cloud scan to re-evaluate the asset.