I've been building CleanCloud (open-source cloud cost scanner) and discovered the biggest adoption blocker wasn't our feature set

It was InfoSec approval.

  The Problem: The Code Audit Wall

  Every enterprise we talked to had the same process:
  1. SRE team loves the tool, wants to use it
  2. InfoSec requires security review before production use
  3. Security team must audit the entire codebase to verify read-only claims
  4. Process takes 2-4 weeks (or gets stuck in backlog indefinitely)

  One CISO told us: "I don't care if your README says 'read-only'. I need to verify you're not calling DeleteBucket() anywhere in 10,000 lines of Python."

  Fair point. But this kills adoption velocity.

  The Insight: Don't Ask Them to Trust Your Code

  The breakthrough came from asking: "Who do InfoSec teams already trust?"

  Answer: AWS and Azure. They already trust the cloud provider's IAM enforcement.

  So instead of asking them to audit our code, we provide:

  1. A 30-line JSON IAM policy (read-only by design)
  2. A verification script they can run to prove it's safe
  3. OIDC setup (GitHub Actions) with no stored credentials
  4. Runtime safety tests that fail if we call forbidden APIs

  The IAM Proof Pack: https://github.com/cleancloud-io/cleancloud/tree/main/docs

  The Result

  InfoSec teams now audit a 30-line JSON file instead of our entire codebase. Trust is enforced by AWS/Azure IAM, not by promises in our README.

  A colleague who reviewed it said:
  > "I specifically love the IAM Proof Pack approach. By requiring a separate, verifiable Read-Only IAM role, you shift trust from your code to the Cloud Provider's enforcement. They don't have to audit your Python code line-by-line—they just verify the JSON policy is safe."

  This reduced our InfoSec approval time from 2-4 weeks to same-day in several cases.

  Technical Details

  The approach works because:

  1. **Verifiable IAM Policy**: The read-only policy is declarative, easy to audit
     ```json
     {
       "Version": "2012-10-17",
       "Statement": [{
         "Effect": "Allow",
         "Action": ["ec2:Describe*", "s3:List*", "s3:GetBucketTagging"],
         "Resource": "*"
       }]
     }

  2. OIDC-First: No long-lived credentials, temporary tokens only
    - GitHub Actions → AWS STS AssumeRoleWithWebIdentity
    - Azure Workload Identity Federation
    - Zero secrets stored in CI/CD
  3. Runtime Guards: Our test suite mocks AWS/Azure SDKs and fails if forbidden methods are called
  def test_aws_runtime_readonly():
      with patch('boto3.client') as mock:
          mock.return_value.delete_bucket.side_effect = AssertionError("Forbidden!")
          scan_aws()  # Must not call delete_bucket
  4. Static Analysis: AST parsing blocks dangerous imports/calls at CI time

  Why This Matters

  If you're building DevOps/security tools that need cloud access, the "trust me, it's read-only" approach doesn't scale. InfoSec teams need verifiable guarantees, not promises.

  Shifting trust from your code to the cloud provider's enforcement makes security review tractable.

  Open Questions

  - Is there a better way to prove read-only behavior programmatically?
  - How do other cloud tools handle InfoSec approval?
  - Should this be a standard pattern for cloud security tools?

  GitHub: https://github.com/cleancloud-io/cleancloud
  Docs: https://github.com/cleancloud-io/cleancloud/blob/main/docs/infosec-readiness.md

  Happy to discuss the approach or share more details about what worked (and what didn't).