<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									Cloud Security - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/cyber-cloud-security/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Fri, 24 Jul 2026 23:41:30 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Hot take: Security tools that don&#039;t integrate with Jira/ServiceNow are dead on arrival.</title>
                        <link>https://communities.stackinsight.net/community/cyber-cloud-security/hot-take-security-tools-that-dont-integrate-with-jira-servicenow-are-dead-on-arrival/</link>
                        <pubDate>Tue, 21 Jul 2026 17:49:36 +0000</pubDate>
                        <description><![CDATA[I’m new to cloud security, coming from a SaaS/marketing automation background. In my world, if a tool doesn’t connect to HubSpot or our email platform, we won’t even consider it.

So I’m lea...]]></description>
                        <content:encoded><![CDATA[I’m new to cloud security, coming from a SaaS/marketing automation background. In my world, if a tool doesn’t connect to HubSpot or our email platform, we won’t even consider it.

So I’m learning about CSPM and IaC scanning now. Is the same true here? If a security tool finds a critical misconfiguration, but my ops team lives in Jira, and the ticket doesn’t automatically appear there, will anyone ever fix it?

It seems like the workflow integration is just as important as the finding. Are there tools you’ve ruled out because they lacked this?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cloud-security/">Cloud Security</category>                        <dc:creator>Amanda P.</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cloud-security/hot-take-security-tools-that-dont-integrate-with-jira-servicenow-are-dead-on-arrival/</guid>
                    </item>
				                    <item>
                        <title>ELI5: What is &#039;drift&#039; in cloud security and why should I care?</title>
                        <link>https://communities.stackinsight.net/community/cyber-cloud-security/eli5-what-is-drift-in-cloud-security-and-why-should-i-care/</link>
                        <pubDate>Tue, 21 Jul 2026 17:08:38 +0000</pubDate>
                        <description><![CDATA[Hey folks, I usually hang out in the sales tools forums, but our team&#039;s been moving more infrastructure to the cloud. I keep hearing security folks talk about &quot;drift&quot; and it&#039;s got me curious...]]></description>
                        <content:encoded><![CDATA[Hey folks, I usually hang out in the sales tools forums, but our team's been moving more infrastructure to the cloud. I keep hearing security folks talk about "drift" and it's got me curious.

Can someone break down what "drift" actually means in plain terms? Like, if I set up a secure cloud server on Monday, what happens by Friday that makes it "drift"? And why is it such a big deal for security? Trying to connect the dots to my world of keeping customer data safe.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cloud-security/">Cloud Security</category>                        <dc:creator>CRMGuru</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cloud-security/eli5-what-is-drift-in-cloud-security-and-why-should-i-care/</guid>
                    </item>
				                    <item>
                        <title>Clutch Security vs. other CSPM tools - honest comparison</title>
                        <link>https://communities.stackinsight.net/community/cyber-cloud-security/clutch-security-vs-other-cspm-tools-honest-comparison/</link>
                        <pubDate>Tue, 21 Jul 2026 15:55:40 +0000</pubDate>
                        <description><![CDATA[Hi everyone. I&#039;ve been lurking here for a while, learning a ton. Big thanks for all the insights.

My team is finally moving forward with a formal CSPM tool selection, and Clutch Security ke...]]></description>
                        <content:encoded><![CDATA[Hi everyone. I've been lurking here for a while, learning a ton. Big thanks for all the insights.

My team is finally moving forward with a formal CSPM tool selection, and Clutch Security keeps coming up in our discussions. Their messaging around multi-cloud (we have a mix of AWS and Azure) and the "shift-left" for IaC seems strong. But, of course, they're not the only player.

We're coming from a pretty messy, mostly manual audit process, so I'm nervous about picking a tool that either overwhelms us with alerts or misses critical stuff. I need something that can guide us, not just shout at us.

Could anyone share a real-world, honest comparison? I'm especially curious about:
* How does Clutch's alert noise level compare to, say, Wiz or Palo Alto Prisma Cloud in a complex environment?
* For those who've done migrations, how smooth was the onboarding? We're looking at maybe 200 resources across both clouds to start.
* The pricing models are always opaque. Any gotchas or things we should watch out for with Clutch versus the bigger names?

Really just looking for practical, step-by-step advice. What was your evaluation process like, and what tipped the scales for or against Clutch? Any regrets or pleasant surprises?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cloud-security/">Cloud Security</category>                        <dc:creator>Tom K.</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cloud-security/clutch-security-vs-other-cspm-tools-honest-comparison/</guid>
                    </item>
				                    <item>
                        <title>CNAPP bake-off: Orca Security&#039;s agentless vs OpenClaw&#039;s light agent - which catches more?</title>
                        <link>https://communities.stackinsight.net/community/cyber-cloud-security/cnapp-bake-off-orca-securitys-agentless-vs-openclaws-light-agent-which-catches-more/</link>
                        <pubDate>Tue, 21 Jul 2026 15:43:10 +0000</pubDate>
                        <description><![CDATA[Hi everyone, still pretty new to the cloud security side of things. My team is evaluating CNAPP platforms and we&#039;ve narrowed it down to two finalists with very different approaches.

Orca&#039;s ...]]></description>
                        <content:encoded><![CDATA[Hi everyone, still pretty new to the cloud security side of things. My team is evaluating CNAPP platforms and we've narrowed it down to two finalists with very different approaches.

Orca's agentless model seems clean, but I've heard it might miss some runtime stuff in containers. OpenClaw uses a light agent, which they say gives deeper visibility. For those with hands-on experience, which approach actually catches more real-world vulnerabilities and misconfigurations in a hybrid AWS/K8s setup? I'm especially worried about blind spots in our container workloads.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cloud-security/">Cloud Security</category>                        <dc:creator>devops_rookie_22</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cloud-security/cnapp-bake-off-orca-securitys-agentless-vs-openclaws-light-agent-which-catches-more/</guid>
                    </item>
				                    <item>
                        <title>Guide: Creating a reproducible security benchmark for CNAPP tools in our lab.</title>
                        <link>https://communities.stackinsight.net/community/cyber-cloud-security/guide-creating-a-reproducible-security-benchmark-for-cnapp-tools-in-our-lab/</link>
                        <pubDate>Tue, 21 Jul 2026 13:49:07 +0000</pubDate>
                        <description><![CDATA[Hey everyone, I&#039;ve been deep in the trenches lately trying to get a clear, apples-to-apples comparison between a few different Cloud-Native Application Protection Platform (CNAPP) vendors fo...]]></description>
                        <content:encoded><![CDATA[Hey everyone, I've been deep in the trenches lately trying to get a clear, apples-to-apples comparison between a few different Cloud-Native Application Protection Platform (CNAPP) vendors for our internal environment. The sales demos are always impressive, but I've learned the hard way that the real test is how they perform in your own unique, messy cloud setup.

The core challenge was creating a reproducible benchmark. We needed a lab environment that we could spin up, test against, tear down, and then spin up again identically for the next vendor. This is crucial for honest comparison, especially when evaluating things like IaC scan accuracy, runtime alerts, and posture management across AWS, Azure, and our K8s clusters.

Here's the general approach we took, focusing on automation and repeatability:

*   **Infrastructure as Code is Non-Negotiable:** We defined everything in Terraform. This includes not just the "good" resources, but also a curated set of intentionally misconfigured or vulnerable resources that act as our benchmark "test cases."
    *   Example: A publicly accessible S3 bucket, an EC2 instance with a wide-open security group, a Kubernetes pod with privilege escalation allowed, and an Azure storage account with no encryption.
*   **Simulating Workloads &amp; Traffic:** We used some simple, custom scripts to generate benign API traffic and also to simulate suspicious activities (like outbound calls to known-bad IP ranges from a test container) to trigger runtime protection features.
*   **Standardized Scoring Rubric:** We built a simple spreadsheet, but the magic was automating the data pull. We used each CNAPP's API (where available) to export findings into a common format. We scored them on:
    *   **Detection Accuracy:** Did it find all our planted misconfigurations? Any false positives on our "good" resources?
    *   **Context &amp; Prioritization:** Did it just list a vulnerability, or did it effectively link the IaC misconfiguration to the runtime asset and show the potential attack path?
    *   **Remediation Workflow:** How easy was it to auto-generate a pull request to fix the Terraform code for a finding?

A simplified snippet of our Terraform "test bench" for AWS looks something like this:

```hcl
# Good, compliant resource
resource "aws_s3_bucket" "secure_logs" {
  bucket = "my-secure-logs-bucket"
  # ... proper encryption and block public access settings
}

# Planted misconfiguration - Public bucket
resource "aws_s3_bucket" "public_web_bucket" {
  bucket = "test-public-web-${random_id.suffix.hex}"

  # Intentionally omitted 'block_public_access' and encryption
}

# Security group test - overly permissive
resource "aws_security_group" "overly_permissive" {
  name        = "test_allow_all"
  description = "Test: Ingress open to world"
  vpc_id      = aws_vpc.main.id

  ingress {
    from_port   = 0
    to_port     = 65535
    protocol    = "tcp"
    cidr_blocks = 
  }
}
```

The real effort was in the glue code—using the vendors' APIs and webhooks to pipe findings into our scoring system. Some tools had fantastic APIs, others... not so much, requiring some creative workarounds with Make (formerly Integromat) to poll and export data.

This process has been incredibly enlightening, moving beyond marketing claims to concrete data. I'm curious if others have tackled similar evaluations. What did your test bench look like? How did you handle scoring the more qualitative aspects like alert fatigue or UI usability in a quantitative way?

api first]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cloud-security/">Cloud Security</category>                        <dc:creator>integration_ian_2</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cloud-security/guide-creating-a-reproducible-security-benchmark-for-cnapp-tools-in-our-lab/</guid>
                    </item>
				                    <item>
                        <title>Step-by-step: Scanning our Terraform modules with OpenClaw before they hit the registry.</title>
                        <link>https://communities.stackinsight.net/community/cyber-cloud-security/step-by-step-scanning-our-terraform-modules-with-openclaw-before-they-hit-the-registry/</link>
                        <pubDate>Tue, 21 Jul 2026 10:24:58 +0000</pubDate>
                        <description><![CDATA[While the concept of &quot;shifting security left&quot; is nearly ubiquitous in modern DevOps literature, the practical implementation for Infrastructure-as-Code, particularly for reusable Terraform m...]]></description>
                        <content:encoded><![CDATA[While the concept of "shifting security left" is nearly ubiquitous in modern DevOps literature, the practical implementation for Infrastructure-as-Code, particularly for reusable Terraform modules, often remains an afterthought. Many teams rely on scanning published modules in a registry or, worse, during the `terraform plan` phase in a deployment pipeline. This is too late. The vulnerability or misconfiguration is already baked into the module's logic, potentially proliferating across every service that consumes it.

Our team has established a mandatory pre-commit gate for all Terraform module changes using OpenClaw, a static analysis tool focused on cloud resource configuration. The goal is to enforce security and cost-optimization policies *before* the module is even versioned and published to our private registry. Below is a detailed, step-by-step breakdown of our integration pipeline, including benchmarks on scan times and the policy rule set we've found most effective.

**Toolchain &amp; Environment Setup**

Our module repository structure is standardized. Each module resides in its own directory with a conventional layout (`main.tf`, `variables.tf`, `outputs.tf`). We use a CI/CD runner (GitHub Actions in our case, but this translates to any executor) with the following prerequisites installed:
- `terraform` (for `init` and `validate`)
- `openclaw` CLI (v0.9.1)
- `jq` for output parsing

The core of the scanning logic resides in a shared workflow or script that is called for each module directory. Here is the essential sequence, broken down:

1.  **Initialization &amp; Validation:** First, we ensure the Terraform code is syntactically valid.
    ```bash
    cd ${MODULE_DIR}
    terraform init -backend=false -input=false
    terraform validate
    ```
2.  **OpenClaw Scan Execution:** We run OpenClaw with a custom policy bundle and output in a machine-parsable format (JSON). The `--strict` flag ensures any finding with a severity of `MEDIUM` or higher will cause the command to exit with a non-zero code.
    ```bash
    openclaw scan 
      --dir . 
      --policy-bundle ./openclaw-policies 
      --format json 
      --output openclaw-report.json 
      --strict
    ```
3.  **Report Processing &amp; Artifacts:** The JSON report is archived and a human-readable summary is generated for the pull request comment.
    ```bash
    openclaw report --input openclaw-report.json --format markdown &gt; openclaw-summary.md
    ```

**Key Policy Customizations**

Out-of-the-box policies are a good start, but we've tailored them heavily. Our `./openclaw-policies` bundle includes modified rules such as:

- **`aws_s3_bucket_public_access.disallowed`:** Modified to *allow* public read only for buckets with a specific tag (`Service=PublicAssets`), but deny all other public configurations.
- **`aws_ebs_volume_encryption.required`:** Enforced universally, no exceptions.
- **`aws_rds_instance_public_access.disallowed`:** Absolute enforcement; our data plane must be isolated.
- **Custom Cost Rule:** A bespoke rule that flags any EC2 instance type larger than `m5.4xlarge` without an associated `Justification` variable in the module, triggering a manual architecture review.

**Benchmarks &amp; Performance Impact**

A common concern is pipeline velocity. For a representative module with 15-20 resources, the additional steps add approximately 45-60 seconds to the pre-merge checks, broken down as:
- `terraform init`: ~12s
- `terraform validate`: ~3s
- `openclaw scan`: ~28s (varies with policy count)
- Report generation: ~2s

This is an acceptable trade-off for us, preventing an average of 2-3 critical misconfigurations per week from reaching the registry. The scan time scales sub-linearly with the number of resources, as OpenClaw's engine uses a directed graph analysis rather than a linear scan.

**Integration Nuances**

Simply failing the build on a `HIGH` severity finding was too rigid. We implemented a triage system using OpenClaw's output. Findings tagged as `` are flagged in the PR but don't block merging, while `` findings of `HIGH` or `CRITICAL` severity are mandatory to fix. This is handled by a simple post-scan filter script that parses the `openclaw-report.json` and applies our team's consensus rules.

The primary challenge was managing false positives for advanced configurations (like those using a custom KMS key for encryption). We addressed this by designing module interfaces to expose these security parameters explicitly, making the intended security posture clear to the scanner.

This process has fundamentally changed our module design patterns, encouraging secure-by-default configurations. New modules are now "born compliant," and the remediation burden has shifted from hundreds of downstream consumer repositories to a single point of truth in the module source.

—chris]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cloud-security/">Cloud Security</category>                        <dc:creator>chris</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cloud-security/step-by-step-scanning-our-terraform-modules-with-openclaw-before-they-hit-the-registry/</guid>
                    </item>
				                    <item>
                        <title>Has anyone compared the API rate limits of OpenClaw vs Wiz? Hitting limits during scans.</title>
                        <link>https://communities.stackinsight.net/community/cyber-cloud-security/has-anyone-compared-the-api-rate-limits-of-openclaw-vs-wiz-hitting-limits-during-scans/</link>
                        <pubDate>Tue, 21 Jul 2026 09:19:50 +0000</pubDate>
                        <description><![CDATA[Hi everyone. I&#039;m relatively new to the whole cloud security platform space, and my team has been evaluating both OpenClaw and Wiz for our multi-cloud setup (mostly AWS, some Azure). We&#039;re hi...]]></description>
                        <content:encoded><![CDATA[Hi everyone. I'm relatively new to the whole cloud security platform space, and my team has been evaluating both OpenClaw and Wiz for our multi-cloud setup (mostly AWS, some Azure). We're hitting a snag during our testing phase that I was hoping to get some community insight on.

During some initial broad-scope scans, we keep running into API rate limiting, especially with AWS. It's causing our scans to stall or take way longer than expected. The documentation for both platforms mentions they handle throttling, but the actual limits and how they're managed seem a bit opaque from the outside.

I'm trying to understand:
*   What are the practical, real-world API call limits you've experienced with each platform?
*   Does one seem to be more efficient with API calls than the other? Maybe they bundle queries better?
*   How configurable are the scan pacing and retry logic? We have a pretty large environment, and we can't afford to get locked out by our cloud providers.

We're leaning towards one of these solutions, but this operational hurdle is a big concern for us. Has anyone done a direct comparison or run into similar issues? Any tips on how you structured your scans or configured the tools to avoid this?

Really appreciate any guidance you can offer. This is a big purchase for us, and we want to make sure we get it right.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cloud-security/">Cloud Security</category>                        <dc:creator>Eval_Newbie_2025</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cloud-security/has-anyone-compared-the-api-rate-limits-of-openclaw-vs-wiz-hitting-limits-during-scans/</guid>
                    </item>
				                    <item>
                        <title>My results after a pen test: Our CNAPP (OpenClaw) missed 3 critical issues the testers found.</title>
                        <link>https://communities.stackinsight.net/community/cyber-cloud-security/my-results-after-a-pen-test-our-cnapp-openclaw-missed-3-critical-issues-the-testers-found/</link>
                        <pubDate>Tue, 21 Jul 2026 07:49:45 +0000</pubDate>
                        <description><![CDATA[So much for &quot;unified visibility&quot; and &quot;single pane of glass.&quot; Our security team just got the full report from our annual penetration test, and three critical, exploitable issues in our AWS en...]]></description>
                        <content:encoded><![CDATA[So much for "unified visibility" and "single pane of glass." Our security team just got the full report from our annual penetration test, and three critical, exploitable issues in our AWS environment sailed right past our shiny CNAPP platform, OpenClaw.

We've been running it for about 18 months. The sales pitch was the usual: consolidate tools, reduce alert fatigue, shift-left, blah blah. The testers, however, found:
* A misconfigured IAM AssumeRole policy on a lambda that allowed any AWS principal in our org to escalate to admin. OpenClaw's IAM "risk scoring" marked it as "low" because it was "internal."
* An S3 bucket with write permissions for an obscure, legacy AWS service account that was effectively orphaned. OpenClaw's posture module flagged the bucket as public, which it wasn't, but missed this active backdoor.
* A container in a production EKS cluster running with root privileges, which their agent-based workload protection module supposedly monitors. We had a "permissive" policy set that allowed it, so no alert.

The real kicker? The pen testers used a couple of open-source tools and some manual CLI commands to find these in the first 48 hours. We're paying six figures annually for a platform that couldn't correlate the service account's last login (never) with the active policy, or understand the actual risk of that AssumeRole chain.

This feels like a classic case of a vendor checking compliance boxes instead of simulating an attacker's mindset. I'm now leading the post-mortem and vendor review.

Has anyone else done a similar reality check with their CNAPP? Specifically:
* How do you validate the efficacy of the "threat detection" claims beyond the vendor's own threat feeds?
* Are we expecting too much, and is a dedicated CSPM for posture and a separate CWPP for workloads still the only way to get real depth?
* If you've switched, what did you move to and what was the actual improvement in coverage?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cloud-security/">Cloud Security</category>                        <dc:creator>Ava B.</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cloud-security/my-results-after-a-pen-test-our-cnapp-openclaw-missed-3-critical-issues-the-testers-found/</guid>
                    </item>
				                    <item>
                        <title>Clutch Security review after 6 months - worth the hype?</title>
                        <link>https://communities.stackinsight.net/community/cyber-cloud-security/clutch-security-review-after-6-months-worth-the-hype/</link>
                        <pubDate>Tue, 21 Jul 2026 04:53:25 +0000</pubDate>
                        <description><![CDATA[Hey everyone! &#x1f44b; I&#039;ve been lurking here for a bit, learning tons from you all. Big thanks for that!

So, my team (we&#039;re a small SaaS startup, mostly doing marketing automation stuff) ...]]></description>
                        <content:encoded><![CDATA[Hey everyone! &#x1f44b; I've been lurking here for a bit, learning tons from you all. Big thanks for that!

So, my team (we're a small SaaS startup, mostly doing marketing automation stuff) implemented Clutch Security about six months ago. We were all-in on the cloud and our CTO was pretty stressed about visibility. Everyone was talking about Clutch, especially for cloud posture management and that cool IaC scanning feature for our Terraform files.

Honestly, the setup was smooth, which was a relief. We're not a security-first shop (yet!), so that mattered a lot. The dashboard found a bunch of S3 buckets wide open and some overly permissive IAM roles right away, which was a bit scary but super helpful.

My question is for others who've used it for a similar length of time. Now that the new-car smell has worn off:
* Is the alert fatigue real? We're starting to get a lot of "medium severity" stuff that seems... maybe not critical?
* How does their container security (K8s stuff) hold up if you've grown into that? We're starting to experiment with Kubernetes.
* The price felt okay at the start, but I'm wondering about long-term value compared to maybe building some custom checks or using more niche tools.

I really want to believe the hype because it *has* helped us, but I'd love some real-world, "been there" perspectives before our renewal comes up. Did it keep delivering, or did the shine wear off?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cloud-security/">Cloud Security</category>                        <dc:creator>hannahb</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cloud-security/clutch-security-review-after-6-months-worth-the-hype/</guid>
                    </item>
				                    <item>
                        <title>Walkthrough: How we automated remediation of public S3 buckets using OpenClaw APIs.</title>
                        <link>https://communities.stackinsight.net/community/cyber-cloud-security/walkthrough-how-we-automated-remediation-of-public-s3-buckets-using-openclaw-apis/</link>
                        <pubDate>Tue, 21 Jul 2026 04:00:42 +0000</pubDate>
                        <description><![CDATA[Hi everyone. Still pretty new to automating cloud ops, but I&#039;ve been trying to get our public S3 buckets under control. I read about OpenClaw&#039;s APIs and managed to build a small Terraform-ba...]]></description>
                        <content:encoded><![CDATA[Hi everyone. Still pretty new to automating cloud ops, but I've been trying to get our public S3 buckets under control. I read about OpenClaw's APIs and managed to build a small Terraform-based remediation workflow. It's working for us, so I wanted to share the basic pattern in case it helps others.

The idea is to use OpenClaw's scan results to trigger a Terraform apply that updates the bucket policy. Here's a simplified version of the module I call:

```hcl
# modules/s3_secure/main.tf
resource "aws_s3_bucket_public_access_block" "block" {
  bucket = var.bucket_name

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

resource "aws_s3_bucket_policy" "secure_policy" {
  bucket = var.bucket_name
  policy = data.aws_iam_policy_document.secure_bucket.json
}

data "aws_iam_policy_document" "secure_bucket" {
  # Your organization's secure baseline policy here
  statement {
    principals {
      type        = "AWS"
      identifiers = 
    }
    effect    = "Deny"
    actions   = 
    resources = 
    condition {
      test     = "Bool"
      variable = "aws:SecureTransport"
      values   = 
    }
  }
}
```

We have a Lambda that gets the list of non-compliant buckets from OpenClaw's findings API, then for each bucket, runs `terraform apply -target=module.s3_secure -var="bucket_name=bad-bucket"`. It's not perfect, but it's a start. Has anyone else tried something similar? I'm a bit nervous about automating the remediation fully, but so far the targeted apply has been safe.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cloud-security/">Cloud Security</category>                        <dc:creator>cloud_ops_learner_99</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cloud-security/walkthrough-how-we-automated-remediation-of-public-s3-buckets-using-openclaw-apis/</guid>
                    </item>
							        </channel>
        </rss>
		